JPH0362155A - Information management system in entity management system - Google Patents

Abstract

PURPOSE: To control a composite system, and to improve monitoring performance by processing demands generated in response to a command from an operator through more than one presentation and functional modules and a kernel means, and displaying the results. CONSTITUTION: When an information manager 15 receives a demand to which a response can be attained by using information in a storage element 17 from a presentation module 10, the manager 15 generates a response to the demand, transmits the response to the module 10, and displays the response to an operator. When the manager 15 can not respond to the demand, the demand is transferred to a dispatcher 16, transferred to a functional module 11, processed by the module 11, and a dependent demand is transmitted to a functional access kernel 14. The kernel 14 transmits both the contents of a data storage element 22 and the dependent demand to an access module 12. The module 12 generates a response to the demand, transmits the response through the module 11 to the module 10, and displays the response to the operator.

Description

DETAILED DESCRIPTION OF THE INVENTION Field of the Invention This invention relates generally to the field of complex system management, and more particularly to apparatus for managing complex systems, such as distributed digital data processing systems.

BACKGROUND OF THE INVENTION As digital data processing systems, or computers, have become smaller and less expensive, individual computers have been used by individuals and small groups. In order to increase the economy associated with resources that are not used for Including servers that store large amounts of data and thereby facilitate the distribution of data, have become integrated into networks that communicate by means of messages carried over communication links.Servers include printers, telecommunications links, etc. It can also be controlled.

In addition, the server may perform specialized computational services such as database searching, classification, etc. Various computers, referred to as requesters, and servers are interconnected by communication links to allow messages to be transferred between the various computers and servers that make up the distribution system.

SUMMARY OF THE INVENTION The present invention provides a new and improved control apparatus for controlling and monitoring complex systems, such as distributed digital data processing systems, in which multiple computers communicate through a local area network. It is something to do.

Briefly summarized, the controller processes requests generated in response to instructions from an operator through one or more presentation modules, functional modules, and kernel means, and provides access and display information in response to the operator. It is equipped with a module. The presentation module handles operator interface functions including receiving instructions from an operator and presenting responses thereto. In response to instructions from an operator, the presentation module generates requests. The kernel means receives the request and communicates it to the functional modules for further processing. Upon request, the module handles general functional operations in connection with the processing of module requests.
A functional module generates one or more requests (sometimes referred to hereinafter as dependent requests for convenience), which are forwarded to kernel means or to other functional modules for processing. The kernel means communicates received dependent requests to the access module for processing. The access module handles primitive operations in relation to the entities that make up the complex system.

Generally, the present invention is a system for retrieving administrative information for a population of entities in response to instructions specifying time parameters, wherein the entities interface with the population to control primary information processing functions and the entities further interface with the system. The feature is that the management information can be accessed by the user. The system retrieves the storage device containing the records, each record containing an indication of the relevant time, associated with the management information, and retrieves the management information contained in the records or from the entity in response to instructions. It consists of an information manager with a schedule for accessing management information and possibly issuing a series of dependent accesses or searches corresponding to instructions, possibly multiple times, according to a time schedule.

In one embodiment, the system includes a historical data recorder that periodically accesses and stores new management information in a record according to a predetermined schedule. The system is adapted to respond to commands specifying at least one time range, possibly in the past, present,
and future times, and the information manager may access information relating to the specified time range from the entity, if possible, by retrieving the management information contained in the record, or otherwise. satisfies the command. The M-report manager determines the time period, including all time before the specified time, by searching records stored in the record during the time range, and by accessing information from the entity at other times. Configured to specify instructions with ranges. The information manager is also configured to fulfill instructions by immediately accessing management information from said entity.

General Description FIG. 1A is a functional block diagram of an apparatus constructed in accordance with the present invention for controlling and monitoring the status and conditions of a complex system. (The complex system itself is not shown.) An example of a complex system controlled by the apparatus preliminarily shown in FIG. and other components. An example of such a digital data processing system is described in a US patent application. It will be appreciated, however, that the controller shown in FIG. 1A is not limited to controlling distributed digital data processing systems, but can be used to control many different types of complex systems.

Such complex systems require management, especially since the state and capabilities of the complex are constantly changing. Therefore, the management facilities and functions it provides must also change to adapt to the new management requirements of the system.As will be explained in more detail below, the device of Figure 1A has the feature of scalability. , which allows the device to be modified to efficiently adapt to complex systems.

For the purposes of this document, we will refer to the components of a complex system as entities. Describe entities in terms of classes and stages. An entity class specifies a particular type of entity. For example, one class includes all of the local area network bridges for a given vendor. Each entity is a member of a class and forms a stage of that class.

Referring to FIG. 1A, the controller controls the presentation module IO
A to l0K (identified as a whole by the reference numeral 10),
Functional modules IIA to IIM (generally reference numeral 1
1), and access modules 12A to 12M (generally identified by the reference numeral 12). Presentation module 10
generally provides a user interface for a user to take control of a complex system, including control of terminals used by system operators. Each I! Each access module 12 generally performs administrative control and monitoring in connection with a class of functions, and each access module 12 generally provides a set of functions belonging to a class of controllable entities within the control system. The presentation module 10, which provides administrative control over controllable entities of the form, communicates with the functional module 14 through the presentation and functionality aspects of the kernel 13.14 (hereinafter simply referred to as the presentation and functionality kernel 13); 13
．． It communicates with the access module through 14 function/access aspects (hereinafter simply referred to as function/access kernels 14).

The functionality required from the control module 10.11.12 may vary widely depending on the topology of the complex system being managed. Therefore, for adaptive and scalable management, the control module 10.11.12 dynamically adds and subtracts devices to and from devices into a particular complex topology and changes in that topology. can be adapted to

Furthermore, for the purpose of adaptability and scalability, the control modules 10.11.12 form a "work force" for the tasks to be performed in the management of the complex system. In this way, for example, duties associated with the management protocols of the distributed data processing system can be separated from duties associated with, for example, displaying management information to the user.

A. Presentation module More specifically, the presentation module 1o performs presentation services, which may include, for example,
Operator accesses various function modules 11 and
A user interface, such as a video display terminal, personal computer, or computer workstation, that controls module 12 and that can be used to control and monitor various entities within the complex system.
It can be configured from an interface support device. The services presented are required independent of the management function or entity managed by the system shown in FIG. 1A, and are therefore provided regardless of the nature of the management function or entity.

Each operator interface or terminal can be controlled by multiple presentation modules. Various presentation modules 10 control various aspects of the operator interface, including such details as portraits, menus, graphics, and assistive devices for displaying and reviewing command lines. Other presentation modules 10 provide specific output support for various types of graphical displays, such as histograms, bar diagrams, pie diagrams, or other forms of pictorial representations to be displayed on the terminal screen to the operator. , yet another presentation module 10 sends administrative requests to and from the presentation/function kernel 13, which may be annotated by portraits, menus, graphics, or commands entered by the operator on the command line. Transferring the management information to a video display terminal used by an operator for display.

B0 Functional Module Functional module 11 is associated with and supports specific management applications performed by the controller shown in FIG. 1A. The management application includes the presentation services performed by the presentation module 10 (other than to the extent that the presentation module 10 informs the operator about the management applications performed in the control management) and the specific services that make up the complex system being managed by the control management. exists independently of the entities in it.

The management aggregation that the functional module 11 can perform is, for example, communication load analysis of a distributed data transmission system. To perform such an analysis, the functional module accesses communication data such as the number of packets and the number of bytes sent by several entities of the distributed data transmission system.The functional module then averages the information. Check against higher level information such as packet size and communication resource utilization of the transmission system. This information can then be sent to the user or made available to other functional modules when running other management applications.

As can be seen in the example above, functional modules ``add value'' to the management information available from the complex system in the form of data matching or correlation services.

In addition, functional modules utilize data produced by other functional modules to provide high-level services for managing complex systems.

In one particular controller for controlling a distributed digital data processing system, one functional module 11
, for example, manages the topology of the network and presents the topology to the operator through the presentation module 10 .

Other functional modules 11 define, for example, the configuration of the distributed digital data processing system, i.e. the various stages of entities and their interrelationships, and allow nodes and other entity stages to be added or subtracted from the network to provide operator control. A configuration system that allows an operator to control the configuration of a network, change access rights for various users of a node, and maintains a configuration (or stage) database that allows an operator to decide on changes to the configuration of a network at any time. A functional module can be provided.

Other functional modules 11 within the controller may, for example, control various alarms indicating that certain events have occurred in the distributed digital data processing system. The alarm function module 11 monitors the status and conditions of various entities of the distributed digital data processing system and generates alarm instructions to the operator, while an appropriate presentation module 10 responds to a condition B having a predetermined value. and advise the operator.

Yet another l! The functional module 11 can, for example, define the domain of an entity within a distributed digital data processing system and limit or facilitate control or monitoring by an operator.

Other functional modules 11 operate, for example, as historical data recorder functional modules 11, periodically balling various entities in the complex to determine their values at particular times and establishing a time and numerical database. , making it easier to maintain and create usage statistics.

Still other functional modules 11 are not capable of controlling certain aspects of the complex, but instead act as walk-throughs, allowing operators to control or monitor primitive functions of the complex through direct access modules 12. Make it.

A management application may require the services and operations of a number of access modules 12 in a particular order, and the functional module 11 supporting the management application may require the services and operations of a number of access modules 12 in a particular order. Adjust the sequence of actions.

Additionally, a management application provided by one functional module 11 may require the application of another functional module 11 in the control device, whereby that one functional module is also adjusted.

The functional module 11 is initially called by the presentation and functional kernel 13 in response to an administrative request entered by an operator obtained by the presentation module 10; the functional module 11 is called by a request received directly from another functional module 11. is also called. Additionally, functional module 11 can generate requests for processing by access module 12.

C. Access Module The access module 12 is associated with various primitive management operations provided by the controller in connection with the various entities that make up the complex system managed by the controller shown in FIG. 1A; We support this. For example, in a distributed digital data processing system, an entity refers to the various hardware of the system, including various computers, disk and tape storage devices, routers, etc., that can constitute the nodes of the distributed digital data processing system. In addition to components, it can also include software components, including virtual circuits, databases, and the like.

Access module 12 is called by function access kernel 14 in response to a request from function module 11.

The access module 12 that controls and monitors the distributed digital data processing system can control several different types of nodes or different levels to generate and transfer messages depending on the message transfer protocols used by the nodes. , one access module 12 can, for example, control and monitor the status of various parts of a bridge connecting two local area networks, and can route messages between two local area networks.
To enable communication between nodes of an area network. Such an access module 12 is
For example, you can initialize a bridge, enable it to start working, disable the bridge, monitor its end-to-end operation, see how many messages are passing through the buffers it has, and You can check whether you have enough buffers to operate effectively.

Other access modules 12 indicate the operation of the message generating and decoding sections of the various nodes of the distributed digital data processing system, virtual circuits, established sessions and other links between the nodes, and their associated activities and inactivities. Various timers and counters can be controlled and monitored.

Similarly, other access modules 12 control network layer portion operations of the node that control the actual transmission and receipt of messages through the network, including various message transmission receipt counters, transmission receipt timers, etc.
can be monitored.

In addition to monitoring the values of various timers and counters, one node can maintain and establish other default and operating parameters using the access module 12 that controls both timers and counters. Limits on the number of concurrent virtual circuits and sessions may also be established.

In certain embodiments, the access module provides access connectivity testing to management functions at the Ethernet LAN bridge.
or IEEE 80211-enabled Ethernet station, port fraction control/check function in an Ethernet repeater, or management a in an FDDI entity.
Noh can be prepared. In addition, the access module is
DECnet Pha announced by Equipment Company
It can be provided to access management support equipment at se19 or PhaseV nodes or DEC terminal servers.

D. Request Control Modules 10.11.12 interact with each other and with users through requests. There are two general forms of requests. A request, for example, can cause something to occur within a complex system.

That is, the state or condition of the complex system can be caused to change. access to process such requests, in which one or more assessment modules 12 perform predetermined actions that change the state or condition of one or more entities of the managed complex system; - Module 12 generates state information indicating the state of the request and returns this to the function access kernel 14.

Alternatively, the request may request information regarding the state or condition of one or more entities in the system, and the entity is identified by the request.

In processing such requests, one or more access modules 12 determine the state or condition of the entity and return visibility information to the functional access kernel 14, otherwise the controller The information stored (such as by a historical data recorder functional module) may be used to satisfy the request.

Alternatively, the request may be in the form of an image.

That is, a request may change the state or condition of one or more entities, and may also request information regarding the changed state or condition of the entity. In processing such a request, the access module 12 may cause changes and return state information regarding the state of the request as well as information regarding the state or condition of the entity.

The request may occur in response to operator action at the terminal presentation device. In that case, the presentation module 10 controlling the terminal generates a request and communicates this to the presentation and functionality kernel 13. Additionally, requests can be generated directly from the appropriate module 11. For example, a functional module 11 that operates as a historical data recorder.
generates requests to periodically check the state or condition of each entity in the complex system and store it in a historical database for later processing as required by the operator.

E. Kernel Kernel 13.14 has information manager 15.20 (hereinafter simply referred to as information manager 15 or information manager 20, but they form one and the same information manager), dispatcher 16.21 ( and a data storage element 17, hereinafter referred to simply as dispatcher 16 or dispatcher 21, forming one and two dispatchers.
．． 22 (hereinafter referred to simply as data storage device 17 or data storage device 22, forming one and the same data storage element as explained below).

F. Data Storage Devices Data storage devices 17.22 may include one or more RAMs with dispatcher data structures, or one or more fixed disk drives, or other storage, depending on the type and amount of data to be stored. Apparatus means may be provided. Additionally, data in various formats may be stored in various storage means for later use by the kernel;
All these means are combined into one data storage element 17.
Diagrammatically represented by 22.

Referring to FIG. 1B, in one embodiment, the data storage element 17.22 stores information at each time regarding the presence and status of the various entities that make up the complex system, and in particular the various entities controlled by the access module 10. as obtained by the historical data recorder functional module 11. This is stored in the historical database 26. Other information may also be stored in data storage element 17.22. In particular, as explained above, the configuration module may form a configuration database 23 that indicates the existence of entity stages within the complex system. The realm module may store a database 25 that describes the realms of entities used to limit the scope of a user's control. Alternatively, realm information may be stored as an element of a configuration database.

The alarm module may also use the alarm rule base 24 to ascertain alarm conditions within the complex system.

Other information relating to individual modules within the control device may also be held in the storage element 17.22. For example, as detailed below, Dispatcher 16.21
A dispatch table 28 used by the dispatcher can store the location of modules and the operations, entities, and attributes serviced by the dispatcher. Additionally, the controller may maintain a data dictionary 27 that stores attributes, commands, and subentities for each of the various classes of entities within the complex system. This latter information may be used, for example, to process requests from users;
Alternatively, it can be used to generate a menu and prompt a user request.

G. Information Manager Referring to FIG. 1A, requests from presentation module 10 to which information manager 15 can respond using information in data storage element 17, as described in more detail below. Upon receiving the request, the information manager 15 intercepts the request, generates a response to the request, and sends it to the appropriate presentation module 1.
0 and display it to the operator who generated the request. If the information manager 15 is unable to respond to the request, the manager determines whether the request pertains to the current time or to a future time. That is, information manager 15 determines whether the request should be processed immediately or scheduled for a specific time in the future. At the appropriate time, either immediately or at a scheduled time, the information manager 15 forwards the request to the dispatcher 16. From the nature of the request, the dispatcher 16 identifies the functional module 11 to which the request should be sent and forwards the request to that functional module 11.

In response to receiving the request from dispatcher 16,
Functional module 11 begins processing the request.

In response to a request, a functional module 11 initiates one or more operations, each represented by a request, hereinafter referred to as a dependent request, and communicates this to a pond functional module 11 or a functional access kernel 14 .

Upon receiving responses to all of the dependent requests, functional module 11 generates a response and communicates it to dispatcher 16 . The dispatcher 16 formats the response and communicates it through the information manager 15 to the appropriate presentation module 10 for display to the operator.

The functions and access aspects of the kernel 14 are handled by the information manager 20.
, dispatcher 21, and data storage element 22
A dependent request directed to the function access kernel 14 from a function module 11 comprising a function module 11 is initially received by an information manager 20. Data storage element 22
Also, information regarding the state of the complex system at each point in time generated from the historical data recorder function module 11,
In particular, certain information regarding the status and conditions of the various entities controlled by the access module 10 may be provided.

When information manager 20 receives a dependent request from functional module 11 to which it can respond using information in data storage element 22, the manager intercepts the request and generates a response to the occurrence of the dependent request. This is then transmitted to the INN module 11, which is the source of the dependent request. If information manager 20 does not respond to a dependent request from functional module 11, it determines whether the request pertains to the current time or to a future time. That is, information manager 20 determines whether the request should be processed immediately or scheduled for a specific time in the future. At the appropriate time, whether immediate or scheduled, the information manager 20 forwards the dependent request to the dispatcher 21. In response to receiving a dependent request from information manager 20, dispatcher 21 identifies the access module 12 to which the dependent request should be communicated and forwards the dependent request to this access module 12.

In response to receiving a dependent request from dispatcher 21, access module 12 begins processing the request. Access module 12, in response to the dependent request,
One or more operations associated with an entity of the controlled complex system may be initiated. If the dependent request requests access module 12 to change the state or condition of the entity, access module 1
2 attempts to do so and generates a response containing status information indicating the status of the attempt, ie, for example, whether the modification was successful, unsuccessful, or partially successful. On the other hand, the dependent request is access module 1
2 to identify the state or condition of the entity, the access module 12 generates a response indicating the state or condition of the entity. Finally, if the dependent request requests access module 12 to do both of the above, access module 12 attempts to change the entity's state or condition and updates the attempted state and the entity's new state or condition. It also generates a response that indicates. In any case, the access module 12 communicates the response to the dispatcher 21, which sends it to the functional module 11 that originated the request.
Transfer to. The response from the access module 12 is used in formatting the module 11, its response to a request from the dispatcher 16, or its response to a dependent request from another functional module 11, as applicable. .

When a functional module 11 receives a dependent request from another functional module 11, it processes it in the same manner as it processes a request from a dispatcher 21.

advantage The control system shown in FIG. 1A has a number of advantages.

The controller essentially forms a processing chain in which each element along the chain attempts to process the request before passing it on to the next element. Accordingly, the information manager 15.20 can, based on the contents of the associated data storage device 17.22, without the need for further processing to other elements further down the chain.
If the request can be processed, the information manager 15.20
does so.

Furthermore, the control device is expandable so that it can be equipped with a separate presentation module i o, a function module 11 and an access module 11.
Modules 12 can be easily added without changing the structure of the control device, as described below.
The addition of functional modules 11 and access modules 12 is done by way of a registration procedure, which will be explained below in conjunction with FIG. Module 10.1
The addition or deletion of 1 or 12 may affect certain data structures of data storage elements 17.22, as described below, and other data fields maintained by presentation module 10, as shown in FIG. This can be done by simply modifying the contents of the file.

Additionally, the modular and expandable nature of the control device facilitates the management of the control device itself. The same dispatch and request models used to issue management commands to the complex system can also be used to issue commands to the management module itself. This eliminates the need for a separate management application to manage the control device itself.

Additionally, since the am of a module is specified in a standard format and available to the controller as a whole, the controller becomes a complete user interface supporter for the module, allowing the module designer to support the user interface for each module. Free yourself from the burden of doing so. This type of "automatic" user interface support ensures a similar look and feel to the user interface, regardless of the source or nature of the management module being used.

When the control device is used to control a distributed digital data processing system, the IIJiXl device, including its various elements, should include a plurality of routines processed by the various nodes and computers that make up the distributed digital data processing system. I can do it. That is, the computer equipment does not need to process the modules that make up the controller that controls the distributed digital data processing system in addition to those that make up the distributed digital data processing system being controlled. , using interprocess communication mechanisms, and internode communication mechanisms,
Communications, including requests, dependent requests, and responses, may be transferred between parts of the controller that may reside in different parts of the same process, in different processes of the same node, and in different nodes. When modules reside in different processes on the same node or on different nodes, the inter-process and inter-node communication mechanisms shown in FIG. 6 and described below handle requests and dependent requests as well as responses. It is also used to transfer between various processes and nodes.

1. Entity Model Before proceeding, it may be helpful to further explain the relationship between the controller shown in Figure 1A and the complex system being controlled, and in particular, Figure 2A. By reference, the control device comprises a command unit 35 with all of the presentation modules 10, a function module 11 and an accelerator module 12, together with a kernel 13.14.

A complex system includes one or more entities 36. Each entity 36 includes a service element 31, a management interface 30 and a service interface 3.
It has 3. The management interface controls and monitors service elements through agents 34. A service element is the actually managed part of an entity 36 and performs the primary aa or function of the entity, i.e. the service element 31 performs the functions of the entity required within the context of a distributed digital data processing system, e.g. , the service element 31 communicates when an entity communicates with a node through the network.

As noted above, service element 31 includes management interface 30 and service interface 33.
through an agent that communicates with the controller and in particular with the accelerator module 12. Communication through the management interface 30 facilitates opening and closing of the service element 31 and its initial configuration, and also allows the commander 35 to check the operating status of the entity 36. By communicating through the service interface 33, the commander 35 can control and monitor the service elements 31. If this is not the case, this may be a predetermined communication parameter in the case of the entity 36, e.g. communicating in the context of controlling the entity 36 or checking the value of a counter in the context of monitoring the entity 36. This is done by determining the attribute conditions.

An entity's management is characterized by the commands it supports and its attributes, which are parameters that broadly relate to its functioning and control as well as to commands. For example, in the case of a router where the entity communicates data packets through a distributed digital data processing network, the attributes of the router may include the number of packets communicated and the number of bytes communicated.

If the entity is a modem, the attributes may include counters and status registers related to modem operation. Examples of directives include 5HOW to search for attribute values;
and SET to modify attribute values.

Service interfaces are concerned with the functionality of the entity, and management interfaces are concerned with the behavior of the agent. The commands and attributes accessed through the service interface characterize the functionality of the entity, while the commands and attributes accessed through the management interface characterize the control and monitoring of the entity.

To clarify the role of the two interfaces and to provide an example of how to apply the above model to a specific entity, consider a controllable entity, a modem. A modem can have several functional attributes, such as baud rate, line selection, and power switch settings. Additionally, the modem may be provided with several management attributes, such as its line utilization and the amount of time elapsed since its last self-test. The baud rate, line selection, and power switch settings are related to the modem's immediate operation, and as such are accessible through the service interface 0 line utilization and the elapsed time from the modem's last self-test to general operation. , and itself are accessed through the management interface.

To refine the above example, note that the presentation module, while presenting management information to the presentation device, uses a service interface since the presentation of information is the primary service of the presentation device. However, the controller's accelerator module can also manage the presentation device, for example by polling and determining if it is on.

In addition to the attributes described above, there are other "pseudo-attributes" that are related to an entity but are not themselves stored by the entity. is an attribute that is not provided.

- Examples are attributes provided by the entity IMPLEM
IMPLEMENTATION, which is a composition of ENTATION TYPE and VER8ION, and CREATIONTIME of the entity. Pseudo-attributes are maintained by the access module responsible for accessing the entity.

It is worth noting at this point that an entity model is a general way of describing the directives and attributes of an entity, and does not imply the internal structure of the entity itself. An entity model is a tool that allows a controller to consistently reference the behavior and attributes of any entity. Any entity can be "plugged in" and controlled by the control device of Figure 1A (
1) Describe this consistent with the entity model,
(2) implementing an appropriate access module; and (3) plugging and registering the access module into the control device.

J. Management of Management Modules As noted above, in the control device that controls the distributed digital data processing system, various presentation modules 10
, functional modules 11, access modules 12, and kernels 13.14 are processed by the various nodes that make up the distributed digital data processing system. In that case, the various modules 10, 11 and 12 and the kernel 13.14 form entities within the complex system and are controlled in the same way as other entities, as described above. The dispatch and request models used to issue management commands to the complex system can also be used to issue commands to the management module itself. As can be seen from the dispatcher specification below, in addition to the management routines that manage the complex system, each module has self-management routines that manipulate the module's internal attributes. Both internal and external routines can be accessed by requests using request syntax. Therefore, as the ability to manage a complex system increases by adding new control modules, the ability to manage control devices increases as well.

Referring to Specification A, Management Module Structure 1, Overview FIG. 2B, in one particular embodiment,
The management module structure includes executable code 38 that implements the management functionality provided by the module. In particular, in the case of an access module, the executable code provides access protocols for the entity classes serviced by the access module.
In the case of functional modules, the executable code includes support for computing the higher level functionality provided by the module. In the case of a presentation module, the executable code comprises an interface protocol to the presentation device supported by the presentation module.

Modules may require proprietary storage to store various read-only and read/write variables related to the functionality of the module. This storage device is provided in the module as an allocated area 32. This storage can be used, for example, by the presentation module to store scrutiny table or presentation form data, or by the access module to store password information with wildcard requests (see below). .

Access points for the various procedures provided by the access module are dispatch entities 39A and 39.
It is indicated by the pointer of B.

As will be explained more fully below, the dispatch entity is fused to a dispatch table stored in kernel storage 17.22 and is used to locate the various procedures supported by the module. As shown in FIG. 2B, dispatch pointer 39A is associated with a procedure within a module that provides management services to the complex system;
B relates to procedures within the module that perform management services for the module itself. As explained above, when a module is registered with a controller, two sets of pointers are loaded into kernel storage for use in managing the complex or module that includes the controller.

In addition to the above structure, a module is associated with a command and response structure that requests services from the module, as well as a management specification 48 that describes the classes of entities and attributes serviced by the module. The management specification also specifies the management of the module itself. During module registration, the associated management specifications are loaded into the data dictionary.

2. Management Specifications The nature, configuration, and structure of the service elements 31 and service interfaces 33 of various entities including the control device as well as entities of the complex system managed by the control device (Figure 1) are based on the management specifications and dispatch specifications. Figures 3A to 3D are details of entity management specifications, and Figure 3E defines dispatch specifications used to initiate specific operations in relation to entities. .First, 3rd A
Referring to the diagram, the management specifications for the entity are in heading section 4.
0 and a main body portion 45.

Heading portion 40 includes a name field with a name that identifies the entity, a variant field with variant identification, and location information indicating the location of the entity within the complex (e.g., if the complex is a distributed digital data processing entity). In the case of a system, it includes certain identification information such as an a-ready field 43 comprising a node identification) and a format declaration field 44 indicating predetermined data format information.

In an alternative embodiment, the heading portion also includes a symbol/prefix field used in conjunction with symbol field 52, described below.

The management specification body portion 45 contains the actual management specifications for the entity.The body portion 45 is further defined in FIG. 3A. Preliminarily, the controller comprises two general types of entities: global entities and dependent entities. The control device, as made clear above, provides management that facilitates a hierarchy of entities, with global entities identifying entities at the top level of the hierarchy and subordinate entities identifying entities that are subordinate to other entities in the hierarchy. The main body part 45 of the specification includes provisions for two types of entities, namely provisions 45A for global entities.
, or one of provisions 45C5 for dependent entities.

A management module can provide services to entities of a global class or to classes of subentities within a global entity class. A specific example is the DEC from Digital Equipment, Maynard, Massachusetts.
net Phase IV. DECnet
In Phase ■, the adjacent node is a subordinate entity class and its superior entity is the Node 4 circuit. When a management node specifically services an adjacent node dependent entity class, the management specification
A mechanism must be provided to indicate that the management specification for a class exists within the management specification for another module (which manages the Node 4 circuit class).

Provisions 45A and 45C for global entities and dependent entities, respectively, are further defined in FIGS. 3A-3D. The entity definition 46 comprises a name field 47 comprising a name and a code by which the entity can be identified. Additionally, name field 47 identifies the entity as a global or dependent entity and identifies the entity's class name. If the entity provision is for a subordinate entity, it has an upper field 50 that identifies the higher level entity in the hierarchy.
The Mi Besshi field 51 will later become the Esotiti body part 5.
It has a list of attribute names for the attributes defined in 3. Finally, symbol field 52 contains symbols used to generate special compiler constant files with consistent names for use by entity developers.

In another example, the entity definition may include a DYNAMIC field. This field has the value T
RUE or FALSF, indicating whether the entity's management specifications should be stored in the configuration database (Figure 1B).

This gives the management module developer a way to precisely indicate which dependent entity stages should be stored in the configuration database. In this way, there is no need to store highly dynamic entities such as connections between nodes in the configuration of the system.

This eliminates the overhead caused by iteratively adding and subtracting dynamic steps. The pool value of the DYNAMIC field indicates whether the nature of the entity class is dynamic; if TRUE, the pool value of the entity class
Class stages are not stored in the configuration; if FALSE, entity class stages are stored in the configuration.

As noted above, the entity definition 46 for an entity includes a body portion 5 having a body portion 53.
3 is defined in detail in FIG. 3B. Referring to FIG. 3B, the main body part 53 of the management specification consists of four parts: an attribute partition regulation listdra 4, a collection regulation listdra 5, a command regulation listdra 6, and a list of subordinate entities in the entity class. 0 with Dependent Entity Listruff If the body part 53 comprises a dependent entity listruff, then each item in the dependent entity listruff has an entity definition 46 with a name field 47 containing rsUBORD INATEJ.
(Figure 3A).

As mentioned above, the entity body is an attribute partition list 54
and an attribute set listora 5.

At this point it is useful to explain the distinction between these lists. Each list takes a complete combination of attributes of an entity, and the groupings indicated by the 0-part list 45 combining each attribute into one or more groups are independent of those indicated by the set list, and each list is an independent precise specification of the attributes of an entity.

The partition list driver 4 identifies all attributes of the same shape and groups them. For example, the attribute PART I T I ON can comprise all counters or all state attributes (flazo). The word "partition" is used to indicate that the group formed by the attribute partition is the true partition of the attribute. An attribute cannot be a member of two partitions; each attribute must be a member of exactly one partition.

The aggregate list driver 5 identifies and groups all attributes having the same Il function. For example, the access module for the Node 4 global entity class is r
sQUARE" can be defined. The 5QUARE attribute set contains all attributes that affect the current performance of the node 4 class entity, e.g.
It may include an attribute in the form of a counter indicating the number of bytes sent and an attribute in the form of a characteristic indicating the pipeline allocation. In this example, the user would thus
0DE (instance>^LL 5QtlARE
You can view these statistics together with commands like

The term "set" is used to indicate that a set includes attributes that have similar functionality, but do not necessarily form a partition of attributes. An attribute can be a member of more than one set, and not all attributes need be members of a set.

Attribute partition definition list 54 may further include one or more attribute definitions 64 as defined in FIG. 3B. Each attribute partition specification 64 identifies the attribute as a particular type of attribute, including an identifier-type attribute, a status-type attribute, a counter-type attribute, a characteristic-type attribute, a reference-type attribute, or a statistics-type attribute. A type field 56 is provided.

For each attribute format, the data format is an additional field 68
It is established by Attribute partition definition 54 may also include fields 60 and 61 indicating a default polling rate and a maximum polling rate, respectively, for the attribute. As noted above, the historical data recorder functionality module 11 may periodically obtain status and condition information for storage in the data storage elements 17.22 in connection with various entities comprising the complex system.

The contents of the Polling Rate field identify the default rate and maximum rate at which each entity provides status and condition information. In addition, the attribute specification includes one or more attribute fields 62, each with an attribute name 63.
It is equipped with This field comprises a code by which the attribute can be accessed, and an associated attribute body 64. As shown above, all the specifications for attributes that are members of a partition are in one partition specification 54. Independent aspects of R-ness are indicated by one or more attribute body definitions 64. Figure 3B is attribute section regulation 5
The information contained in the attribute body 64 of the attribute field of No. 5 is further described.

Attribute book #64 may include a number of fields, including an access information field 65 indicating whether the attribute can be read or written and a display field 66 indicating whether the attribute should be displayed to the operator by the presentation module 10. can.

Default value field 67 identifies the default or initial value of the attribute. Symbol field 70 contains the symbol used to generate a particular compiler constant file with a consistent name for use by entity developers.

Attribute body 64 further includes a category field 71 that identifies one or more categories with which attributes can be combined. If the complex system is a distributed digital data processing system, the category is C0NF.
IGURATION.

FAULT, PERFORMANCE, 5ECURIT
Y, or ACCOtJNTING, 74-98
-4 Open Systems Interconnect (01)
In addition, the attribute body 64 may include, but is not limited to, a category defined by the i-case, and the polling speed for the specific attribute defined by the attribute body 64 is a field of the attribute partition definition 54. 60 and 6
If the polling speed is different from the polling distance specified in 1, fields 72 and 73 can contain polling speed information. Finally, the attribute body 64 may include a proprietary variable field 74 that identifies proprietary variables used by the management module when processing in connection with the attribute.

In another embodiment, polling speed information may be omitted from the attribute specification altogether, as the accuracy of this data is implementation specific. Additionally, in another embodiment, the attribute body 64 may include a UNIT field.

If a UNIT field is provided, data in numerical form can (and should) have its specified units.

Attributes can be grouped together to simplify the management of complex systems. The set definition portion 55 of the entity body 53 identifies one or more sets included in the entity. The contents of the attribute definition portion 55 are defined in detail in FIG. 3B. The set definition portion 55 includes a set name field 75 that identifies the set, and an attribute list 81 that identifies the attributes included in the set. The set definition part 55 may also comprise commands, ie requests, lists that can be processed by referencing the set.

The set definition portion 55 includes a symbol field 77 similar to the symbol field described above, a category field 80 that may include, but is not limited to, O3I category information, and a field 75 that includes a set identified by the set name. A proprietary variable field 82 may be provided to identify a proprietary variable used when processing an attribute.

The entities are respectively presented in the presentation module 10 and fi
Processes commands generated by the controller in response to requests from the functional module 11 and dependent requests. Each command includes a command request that specifies the action to be taken, and can have responses and exceptions that specify the response that the entity takes in conjunction with the action. Each command is defined by a command regulation 56.

3C and 3D show the structure of command provision 56 in detail. Referring to FIG. 3C, the specification specification 56 includes a name field 83 with a code by which the command can be identified and accessed. The directive includes a requirement specification field 9 that identifies the structure of the requirement or dependent requirement.
0, a response definition field 91 that defines the structure of a response, and an exception definition field 92 that defines the structure of an exception that can occur during processing of a command.

Details of fields 90, 91 and 92 will be discussed below.

Command provision 56 determines whether the command is an action command, that is, whether the command can change the condition or state of one or more entities of the complex system, or whether the command simply returns a state or information. A field 84 may also be provided to indicate whether or not it is only a start. In another embodiment, the effect field 84 may be set to
INE.

It can be replaced by a DIRECT TYPE field indicating whether it is of the type MODFY or ACTION. The EXAMINE directive operates only on attributes and does not modify them.

Examples include the 5HOW command or the DIRECTORY command. The MODEFY command operates only on attributes, examples of which make modifications are the SET, ADD, or REMOVE commands. CREATE is an example where the ACTION directive does not work on attributes, but on the entity itself.
There are commands and TEST commands.

A field 85 may be provided to indicate whether the command is accessible by the presentation module 10. An identifying text string may be provided in symbol field 86. In addition, category field 87 is
As defined above in connection with field 71 (FIG. 3), one or more O3I categories may be defined, but are not limited to this.

The structure of the requirement specification field 90 of the command specification 56 is defined in FIG. In addition to the words rRF, QtJESTJ, the request specification field 90 may comprise zero or more arguments 91 defined in a name field 92, each containing an access code. Additionally, the argument may be provided with a display field 93 indicating whether the argument should be displayed to the operator by the presentation module 1°. The argument includes a field 94 indicating whether the operator must provide a value for the argument, a default field 96 containing the default value, a symbolic field 97 containing an identifying text string, and a measurement of the argument value. A unit field 95 may also be provided to indicate the unit of . In addition, the argument 91 is a proprietary variable field 10 that identifies a proprietary variable used when processing in relation to the argument.
0 can be provided.

Response provision field 91 and exception provision field 92
The structure of is shown in Figure 3D. With reference to Figure 5D,
The response specification field 91 comprises a response name field 101 which can contain a code by which the response can be accessed. The violent field is 5U when the response fulfills the request specified by the request field.
Whether CCESS is indicated or the response is INFORMA
TIONAL or not. A text field 103 indicates a text string that the presentation module 1o can display to indicate a response to the operator; a, response specification fields each include a name field 105 . One or more argument fields 104 may be provided, including a unit field 106 and a symbol field 107.

In an alternative embodiment, the intensity field 102 can be replaced with a symbolic field with an identifying text string for the response, and the arguments field 104 includes a pool display field that indicates whether the response should be displayed to the user. be able to.

The structure of the exception definition field 92 is similar to the structure of the response layer field 91, which includes fields 111 to 117 similar to fields 101 to 107 of the response definition field 21. However, the severity field 112 indicates the severity of the error causing the exception, WARN
It can have three values, including ING, ERROR and FATAL.

In other embodiments, as in response provision 91, intensity field 102 may be replaced with a symbolic field with an identifying text string for the response, and argument field 104 indicates whether the response should be displayed to the user. A pool display field may be provided to indicate the pool.

3. Dispatch Usage Figure 3 defines dispatch usage 39A (Figure 2B), which is used to define the initiation of a particular action by an entity. The information in the dispatch usage for an entity is used to generate a pointer to the procedure that performs the operation. Referring to FIG. 3E, a dispatch use includes a heading 200 defining the beginning of the dispatch use and containing the table name, and a footer 200 indicating the end of the dispatch use.
01. Between heading 200 and data 201, the dispatch usage has one or more dispatch entries, each of which defines an action in association with one or more entities and attributes.

A dispatch entry comprises a verb portion 203 and an entity entry 204, which together identify an action. Effectively, the verb portion 203 and entry portion 204 of the dispatch entry correspond to a command prescribed by the management. Directives can operate on entities or on attributes defined by the attributes portion 205 of the entry defined in the entity entry. The contents of entity entry 204 correspond to the entity or subentity identified by the entity class and F1 hierarchy name in name fields 47 and 50 of entity specification 46. Similarly, the content of the attribute part 205 is the entity specification 46.
corresponds to the attribute identified by the name field 62 of the attribute definition 54 of the entity body 53 of .

The dispatch entry 202 also includes the procedure pointer part 20
6, which is the dispatch entry 202
The access manager processes the directive in relation to the entities and attributes identified in parts 203, 204 and 205 of the
Contains a pointer to the entry point to a procedure within the module. As discussed below in connection with FIGS. 5, 7A, and 8B, dispatch uses data structures, specifically the ability of the kernel 13.14 to route requests to the appropriate functional module 11 or access module 12 for processing. Dispatch table 28 used to forward
(Fig. 5) is used to stylize the dispatch entry 134 (Fig. 8B). A request or dependent request is essentially an I! The kernel compares the verb, entity, and attribute compartments specified by the request with the contents of the parts of the data structure defined by parts 203, 204, and 205, respectively, of the dispatch usage. do. If each part of the verb matches the contents of the corresponding part of the data structure (Figure 8B), then kernel 13.14 creates a dispatch function Il (3
The procedure defined in dispatch entry 134, taken from section 206 of Figure E, begins.

B. Data Files and Uses 1. Registering a data dictionary management module allows its management specifications to define new entity classes, sub-entity classes or attributes, global or sub-entity directives or events. The management specifications (Figures 3A to 3D) are used to configure the data dictionary;
Data dictionaries are used to construct other data structures,
This is described below in connection with Figures 5 and 8A, but in Figure 9.
Used as shown in the figure. The data dictionary consists of a 31W layered database having the general MIM or structure shown in FIG. Referring to FIG. 4, the organization includes a relative root node 220 that is associated with a global entity defined for administrative use (FIG. 3A). The global entity node includes a subordinate node 221 that lists all attributes, a subordinate node 219 that lists attribute partitions, and a subordinate node 222 that lists attribute sets in the hierarchical organization of the entity body 53 of the entity regulation 46 of the management specification. , refers to a plurality of subordinate nodes, including subordinate node 223, which lists directives, and subordinate node 224, which lists subentities.

Each subordinate node 219 to 224 refers to a respective element defined in the entity body.

That is, the -1 subordinate nodes 221 point to attribute definition nodes 225 each of which has a definition of the attribute defined in the attribute definition 54 of the entity body 53, and the attribute partition nodes 219 each of which has a definition of the attribute defined in the attribute definition 54 of the entity body 53.
Each of the set nodes 222 points to a set provision node 226 having a set provision defined by the set provision 55 of the entity body 53. , command node 22
3 refers to the command provision nodes 227 each having a provision of the command specified in the command provision 56 of the entity body 53, and the sub-entity nodes 224 each having a sub-entity provision defined in the sub-entity provision 57 of the entity body 53. Each command node 227 points to a sub-entity provision node 228 that contains the provisions for the entity, a request node 230, a response node 231, and an exception node 2.
32, each of which in turn corresponds to the requirements 90 of the management specification.
, response provisions 91, and exception provisions 92 (taken from Figure 3C). In addition, each subentity node 228 includes a dependency node 233 for attributes, a dependency node 233 for sets, and a dependency node 233 for attributes. node 234,
forming the root node of a sub-organization having a structure similar to that depicted for the global entity shown in FIG. . The organization shown in FIG. 4 is repeated for all subentities and their subentities defined in the management specifications shown in FIGS. 3A through 3D.

The information in the management specification is fused into respective nodes of the data dictionary to display entity information, including entity identification and response information, to the operator, and to other parts of the control equipment and complex system, as described below. is used to create a user interface information file 29 that is used by presentation module 10 in connection with the generation of a processing request by an entity. Various nodes of the data dictionary receive information from the elements of the management specification to form a complete database of data dictionaries. Information within the dispatch specification (Figure 3E) is used to create dispatch table 28, as described below in connection with Figures 8B and 9.

With this background, FIG. 5 shows one presentation module 10
．． Imm module 11 access module 12 and information manager 15.20 and dispatcher 16.
Kernel 13°14 with 21 is shown. Additionally, FIG. 5 depicts various portions of data storage element 17.22. In particular, data storage element 17.
22 includes configuration and domain databases 23, 25, alarm database 24, historical data file 26, data dictionary 27, and dispatch table 28.

2. Historical data file The historical data file 28 is the presentation of the kernel 13.
In the case of the function aspect, information about the state and conditions of the entity, in the case of the function/access aspect of the kernel 14,
It has an entity. In file 26, the status and condition information also includes timing information identifying the time at which the status and condition information occurred. Information management device 15゜20 is activated at a specific time! Upon receiving a request or a dependent request regarding a ll or condition, the information manager checks whether the information exists in the file 26 and updates the file 26 if the time indicated in the request or dependent request is in the past. Respond using the contents of .

On the other hand, if the time indicated in the request or dependent request is a time in the future, the information manager 15.20 effectively schedules the request to be processed at the indicated time. That is,
The information manager holds the request or dependent request until the indicated time, at which point it is accessed by the direct access module 12.
or from functional module 11, whichever is appropriate, or using file 26, if appropriate.

These features are fully described below under the heading "Scheduling."

3. Dispatch table Dispatch table 28 is dispatcher 16.2
1 to the appropriate functional module 1.
1 or access module 12. The contents of the distribution table 28 identify the location within the distributed digital data processing system of the entry point for the routines comprising each functional module 11 that are called in response to a request from the presentation module 10. More specifically, dispatch table 28 contains invocation information that facilitates initiation of various operations by respective functional modules 11.

Similarly, the contents of dispatch table 28 identify the location within the distributed digital data processing system of the entry point of the access module 12 routine.

This location is used to process dependent requests from functional modules 11, ie call information specifying various operations by the respective entities.

4. User Interface [a] The control device further comprises a user interface information file 29 with information regarding each of the functions provided by the functional modules 11 and the entities controlled by the access module 12. The user interface information file 29 comprises information obtained from the management specifications of each entity. Presentation module 10 uses the contents of user interface information file 29 in displaying menus and other objects on operator terminals to facilitate control of the complex system. The information in user interface information file 29 facilitates the display of various functions and operations associated with complex system entities.

5. Configuration Database As explained above, the configuration function module can create and maintain a configuration database that lists all entity stages of the current configuration (and past configurations, if necessary) of the complex system. This information can be, for example,
The presentation module can be used to create a review table or user menu that lists the available entity stages. The configuration database may also provide a domain database that limits the scope of user control to facilitate use of the complex system, as described below.

In addition to the above features, in one embodiment, a configuration database can be used in conjunction with the presentation module to support wildcarding of user instructions. When the presentation module receives a user instruction containing a wildcard, the presentation module issues a request to the configuration function module requesting an inventory of all entities in the configuration that match the wildcard request. uses information from the configuration database (along with region information) to create the list. Upon receiving the list, the presentation module expands the user request to all possible dependent requests that match the wildcard.

For example, request 5HOW N0DE large IN DOMAIN 5ITE
1 (where 5HOW is the directive, DOMAIN is the area entity class, 5ITEI is the area stage, MODE is the global entity class, and large is the wildcard) is the area named 5ITEI. is interpreted as an instruction indicating all the stages of a node within.

The presentation module thus sends each request 5 HOW N
0DE (inStanCe>(where <1nSta
nCQ) is the name of the stage〉, one is area 5I
We expand on several requirements corresponding to each stage of the N0DE class of TEI.

Partial wildcards can also be supported. In this case, the group of target entities whose stage names match the pattern specified by the partial wildcard name is the issued command.

Tato means “N0DE*OO” is rNODE FOO.”
and rNODE MAGOOJ, but rN
Zero-part wildcards, which are not compatible with ODEs, BARs, cannot be used for fields with certain data type identifiers, such as text or numeric strings.

In the preferred embodiment, wildcard expansions are not allowed in the global entity class field of user directives, and global class specifications are not wildcarded because doing so would provide insufficient control over the scope of the directive. It is from. This may generate an error if a directive name supported by one entity class is not supported by another. Even if a command name is supported by multiple classes, the command name may correspond to unrelated functions in different classes, resulting in unwanted side effects (eg, rDELETE*, command). Additionally, global entity wildcards can easily generate more information than the user intended (e.g. rsHOW*, directive). Note that wildcards are safely allowed in subentity classes. thing.

Wildcard embodiments may also delegate some or all of the wildcard expansion duties to the access module.

This is especially true if you do not use a configurator module; without a configurator module, the access module (which is typically concerned with accessing all modules of a class or subclass) It may be stored as part of proprietary storage 32 (Figure 2B). In this case, the access module will use the stage data to expand the wildcard of the received request. If not supported by a particular access module, an exception will be returned to the user indicating this condition.

C. Data File Management and Registration When a management module is added to a controller, or when new information related to the management of entities becomes available, the controller must adapt.

The control unit is data driven and to adapt the system to new modules or information the associated data files must be modified; this process is commonly known as data file management. The specific procedure for adapting the control device to a new module is known as registration.

1. Management of Historical Data Files - In one particular embodiment, the contents of historical data files 26 are provided and maintained in part by functional module 11, which acts as a historical data recorder functional module. In this embodiment, the historical data recorder functional module is controlled through requests submitted to presentation module 10 by an operator. Initially, such a request identifies an entity and one or more attributes, but, along with the polling speed, establishes a record for the identified entity and attributes in the historical data file, and the historical data recorder functional module , a dependency that allows an entity to respond to an entity at the polling rate specified in the request with a value representing the state of the entity in the complex specified by the entity and attributes specified in the request. In addition to allowing requests to be issued, other forms of requests may cause the operator to initiate other actions associated with the historical data recorder functional module, including changing the polling rate and Enable or disable and indicate the last value in the response.

2. Dispatch Table The contents of the dispatch table 28 and the user interface information file 29 contain registration information, which is provided by the various functional modules 11 and the access module 12 during the registration procedure. During the registration procedure that registers the module with the control device, the module loads display information, including name and code information, from its name field into the data dictionary. In addition, the module retrieves code information and other information specified in the management specification from the data dictionary (Figure 4) and dispatch information from its dispatch specification (Figure 3E) into the dispatch table 24.
Load into.

3. The user interface information presentation module 10 uses the display information of the user interface information file 29 to first display the entry,
Second, it is determined whether attributes, commands, etc. are to be displayed, and secondly, what is to be displayed. The user interface information file 29 is configured to:
A presentation module 10 receives the instruction and examines the instruction using a scrutiny table to obtain codes corresponding to the codes of the attributes specified in the request, entity, and management specifications, and passes this as a request. kernel 1
Transmit to 3.

Function modules and access modules are user
Note that it is not necessary to own the interface code; all user interface aids are provided for these modules, and the module designer
There is no need to worry about interfaces, which makes modular design incredibly easy and ensures that the system looks and feels uniform to the user, regardless of the actual modules being used.

Upon receiving the request from the presentation module, dispatcher 1
6 calls the function module 11 using the dispatch information in the dispatch table 28.

Dispatch table 28 also forms a scrutiny table, which is used by dispatcher 16 to route requests to eligible procedures to process requests, as described below in connection with FIG.

Using the code in the scrutiny table and in the dispatch table 28 while using presentation-specific information in the user interface information file 29, entities, attributes, etc. are provided to the operator by the presentation module 10, as used by the dispatcher 16. It can be seen that it is substantially separated from the displayed identification. Presentation module 10
The representations generated by the presentation module 10 can therefore be expressed in a variety of languages, while the requests generated by the presentation module 10 have the same identification of entities, attributes, etc.

Additionally, user interface information file 29 may store information already available in a more convenient format from configuration databases and data dictionaries.

For example, class data in the data dictionary (Figure 4) indicates all commands 223 supported by the entities of the complex system.

However, directives 223 are stored in a hierarchical format and are dependent on entity classes 220. Although this format is logical for representing entity class information, it is not very useful for scrutiny tables; user requests are typically directed first (e.g., rsH for rsHoW N0DE FOOJ
OW''), the scrutiny table should have the command as the first level of the hierarchy. As you can see from the example above, the scrutiny table is based on the class name (for example rN
ODEJ) is mixed with an a-level name (for example, the identifier FOO of rNODEFOO), this is necessary because the instruction is scrutinized. Therefore, after listing the available directives, the scrutiny table specifies the class names that support these directives.
The data types for these class stages should then be listed. Class and data type information is available through data dictionary reorganization, while for wildcard expansion stage data can be obtained from the configuration database. Accordingly, the scrutiny table in the user interface information file can integrate directives and entity classes, making the scrutiny of user input more efficient.

The above example also applies to graphical or menu-driven interfaces. However, in this type of interface, the user can specify a particular entity or area of an entity for further actions and the commands to be performed.
3I category (Category field 8 of Directive provisions)
You may wish to set the context for your command by graphically selecting one of the commands (listed in 7). Next, you can generate a menu listing all of the supported commands. Users can use pre-formed menus to request commands for one or more stages (e.g., by clicking on commands and stages) or for entire regions or entity classes (by clicking on commands only). can. EXAMINE format or CATEG
For ORY type commands, a separate menu may prompt the user to select an attribute pane or set. To implement this type of interface, the list of all domain and entity stages and the list of all stages within a domain must be retrieved from the configuration database. Can be stored.

The user interface information file may also store information on default values for a level or class provided by the user or by management specifications for the associated entity class. This allows the user to save typing time by specifying default values within the instructions. For example, users may be most interested in N0DE FOO.
N0DE FOOJ can be designated as the default node. Later, the user can use rsHOWROUT
ING", which would be interpreted as rsHOW N0DE FOOROUTINGJ. Similar usage of default values can be utilized in graphical environments. Other examples of user interface information are online supplementary files available to the user through the presentation module. The auxiliary file contains auxiliary information for utilizing the existing set of management modules. In the preferred embodiment, the auxiliary file is assembled from auxiliary information provided by the module when the module is registered.

The supplied auxiliary information may comprise a textual description of the classes of entities and subentities supported by the module and instructions for the classes supported by the module. Additionally, tutoring information can be provided to educate new users about the module and its commands.

Although the above information can be obtained from the management specification for the module, the auxiliary information file translates the management specification information into English, reducing the need for the user to learn the syntax of the management specification.

4. Historical Data Recording The historical data recorder functional module 11 uses the entity's polling information from its portions of the data dictionary, including the portions associated with the maximum polling speed field and the default polling speed field, to determine the attributes. Polling can be initiated and controlled in relation to the various attributes of the entity defined in the rules 54 and the responses thereto are stored by the historical data recorder function module 11 in its historical data file 26.

5. Module Registration Referring to FIG. 5, the access module 12, for example, while engaged in a registration procedure, registers the name and code information specified in the name and code information from its name field and its management specifications. Loads display information into the user interface information file 29, including information from the portion of the data dictionary that pertains to the display fields of the . Similarly, the functional module 11 stores code information and other information specified in the management specifications in a data dictionary (Figure 4).
and dispatch information from the dispatch specification (FIG. 3E) into the dispatch table 28.

D. Inter-Module and Inter-Node Communication 1. Control Functions In one module-specific embodiment, the operator can
The module 12 can be controlled through the control function module 11, which essentially generates dependent requests that are copies of the requests it receives directly from the dispatcher 16. In this embodiment, the presentation module 10 receiving the instructions includes:
The instruction is examined using the examination table of the user interface information file 29 to obtain codes corresponding to the codes for requests, entities, and attributes of the access module 12 specified in the management specification, and this is presented as a request. It is communicated to the functional kernel 13. Control function module 11 communicates the request as a dependent request to feature access kernel 14, where it is processed in the same manner as other dependent requests.

Upon receiving a dependent request from control function module 11, dispatcher 21 calls access module 12 using dispatcher information in dispatcher table 28. Dispatcher table 28 also forms a scrutiny table, which is used by dispatcher 21 to route the request to the appropriate procedure and process the request, as described below in connection with FIGS. 9A and 9B.

2. When the inter-mode communication controller controls a complex system consisting of a distributed digital data processing system, FIG. Function module 11 and access module 12 including 14 and associated data files 23, 24, 25, 26, 27
, a dispatcher table 28, and a user interface information file 29, which elements are included in a single process of a single node of the distributed digital data processing system. Presentation Module 10, Functional Module 11 and Access Module 12 If provided in different processes or nodes, the control device includes a dispatcher 16.21 in all processes and nodes. Referring to FIG. 6, one 1 of one node
When the dispatcher 16 (1) of the zero process receives a request from the presenting module 10 (1) that must be processed by the functional module 11 (2) of the second process or node, the dispatcher 16 (1) 11(2) in another process on the same node, then
The request is communicated to the processes of other nodes or to the dispatcher 16(2) of the node by an inter-process communication mechanism or by an inter-node communication aperture. dispatcher 16
(2) then selects the functional module IN2) to process the request. The dispatcher 16 (2) receives the response generated by the a-function module 11 (2) and transmits it to the dispatcher 16 (1) via the inter-process communication device I or the inter-node communication mechanism, and the dispatcher 16 (1) sends the response to the presentation module. 1G(1) allows the response to be displayed to the operator.

Similarly, the dispatcher 21 (2) can request access from the function module 11 (2) to other processes or nodes.
When the module 12 (3) receives a dependent request to be processed, it transmits the dependent request to the dispatcher 21 (3) of another process or node through an inter-process communication mechanism or an inter-node communication mechanism, respectively. dispatcher 21
(3) then sends the dependent request to the access module 12 (
3) Transfer for processing. Dispatcher 21 (
3) receives a response from the access module 12 (3) and transmits it to the dispatcher 21 (2) via an inter-process communication mechanism or an inter-node communication mechanism, and the dispatcher 21 (2) transmits it to the functional module 11 (
2).

3. Structure of Requests and Dependent Requests The structure and contents of the dispatch table 24 (which are similar to the structure and contents of the dispatch table 26) are shown in FIG. 7A. 7A and 7B) will be described in connection with FIGS. 7A and 7B. Information manager 15.20 and dispatcher 16.2 in connection with future request scrutiny
The process carried out by 1 will be described in connection with FIG.

Referring to FIG. 7A, the user interface information file 27 may be generated by the presentation module 10 in response to the contents of the user interface information file 27 and related actions by the operator.

The request comprises a plurality of parameters or can be generated by the information manager 15 during polling in connection with various entities of the controlled complex system.

All requests have the same structure: initial call identifier,
This is not shown, followed by the parameters shown in FIG. 7A. Kernel 13.14 as explained above
comprises a single dispatcher 16.21 having a presentation and function aspect 16 and a function access aspect 21.

The initial invocation identifier determines which of these aspects are enabled by each request. The initial call identifier may indicate a call to a functional module or access module, each directed to a corresponding aspect of the dispatcher. A presentation module or a function module can call a function module I! A function module or an access module can call an access module, whereas a presentation module can only call an access module through the control function module J described above.

The parameters include a verb field 12 whose content identifies the type of request, i.e. the action to be taken in processing the request.
0. As noted above, a request initiates a change in the state or condition of an entity of a complex system controlled by the II function module 11 or the access module 12 and changes the state or condition of such entity or its Information about both parties can begin to be sent back.

The contents of verb field 120 indicate the action to be performed by functional module 11 or access module 12.

The request also includes an input entity specification field 121, which identifies the entity of the complex being controlled. If the verb is a non-action verb, for example if you are requesting a response indicating the value of one or more attributes, then the request requires one or more actions to be taken in relation to this, as specified by the verb and the entity class. An attribute pointer field 122 is provided with a pointer to an attribute.

If the verb is an action verb, ie, the verb causes a change in a given entity, then the request does not include an attribute pointer field 122.

In addition, the request may point to a time data structure that contains certain timing information, including absolute system time, time interval specifications, and time accuracy specifications, and specifications for the time range in the request for scheduling purposes. An input time designator field 123 is provided. The input/output context handling field 124 contains values that identify requests in the context of multi-part operations, each part of which requires a separate request. Output entity specifier field 126 comprises a pointer to a data buffer that can be used by dispatcher 15 (or dispatcher 21 if the parameter forms part of a dependent request) in conjunction with the identification of the entity. .

The request also includes a pointer to the item stamp specification that is to be used by the functional module 11 (or the access module 12 in the case of dependent requests) in connection with forming the response. Finally, an optional data descriptor field 127 contains the data used in processing the request and contains a descriptor for the buffer in which the entity stores the data that constitutes the response. Each descriptor has a pointer to the starting position of its respective buffer and a length specifier indicating the length of the buffer.

In another embodiment of the invention, the request is made as a separate parameter or as a separate element of the parameter field described above.
A qualifier field may also be provided.

The WITH qualifier can be associated with an entity field that filters the entity list created by wildcards, for example. For example, rBR
IDG*WITH5TATUS='ON' AND
FILTERING='OFF'J refers to each bridge class entity with its state flag set to ON and its filtering flag set to OFF (this example is an AND
, OR, NOT, and XOH with qualifiers). In the preferred embodiment, all modules and information managers are used as entity parameters to implement the WITH qualifier. The system is configured to check the presence or absence of a WITH clause at each level (ie, global entity, sub-entity, sub-sub-entity).

Other qualifiers can be used as explicit parameters of the request.
Send to a file named i le name>
To<fi 1 ename>" qualifier, retrieve other request parameters from the file named <filename>rFROM<filename>" qualifier, a series of " 6 rVIAPATHJ @electronic (useful, for example, in specifying a fine-grained management module between several devices performing an operation), and specifying a particular network path to be used by the management module when performing an operation. rVIA PORTJ qualifier (useful for specifying that the access module performs diagnostic tests using a particular Ethernet port).

Similarly explicit parameter qualifiers can specify groups of entities.

“IN DOMAIN<domain name>
``qualifier filters the specification so that it applies only to members of the domain named <domain name>.

Also, explicit parameter qualifiers can authenticate or qualify requesters of management services with limited access rights. rBY ACCOUNTJ, rBY
PASSWORDJ, and rBY USERJ
Qualifiers are examples of specifying the customer's electronic name, password, or user identifier of the requester for these purposes.

In addition to the above, qualifiers specify times at which commands are to be executed. Generally this is done in the AT clause.

For the show instruction, the syntax of the AT clause is <AT-c 1
aus e> : : =”AT”<11me-
arg) [","<time-arg>. Here, the time argument <time-arg> is, for example, the start time ('5TART=<time>''),
End time (rEND=<time>") or connection time (rDURATION-<time-1engt
h>''), repetition period (rREPERT EVERY
[=]<time-1ength>">, time accuracy (rcONFIDENCE [=]<time-1en
gth>”), or sampling rate (rSAMP
LE RATE [=]<time-1ength>
”) can be shown. These arguments interact with each other to create a general schedule and range of interest for the request; in particular, in one particular embodiment, three time arguments, TART, END, and DURATION, two of which define the duration. It's related to what you do. Therefore, at least two of these qualifier arguments must be specified when displaying period-based entity statistics.

Other time qualifiers can also be used.

For example, a time qualifier in AT ORBEFORE<time> can be interpreted to request time-slumped information at or before the time indicated by <time>. Upon receiving such a qualified request, the argument module continually checks for actions that will produce the requested information. If information is generated, for example by the actions of other associates, it is returned to the requester. Otherwise, the management module continues to check for information until time (title>). If the information occurs, it is returned to the requester. Otherwise, time <time>
e>, the management module forces the ball of information from the access module or entity and returns the information to the requester.

N to select the AT ORBEFORE time qualifier.

- Time qualifiers can also be implemented. In addition, field 124 contains a handling pointer to a context data structure, which is a dedicated section of storage that stores processing context information. The handle is used, for example, as a notepad for communicating context information between the module and the information manager.

1. Time stamp Each item of data has a timestamp value.

For data returned to the user or management module,
The timestamp indicates the instant at which the event described by the data item occurred, the instant applied to the data value returned for the command, and the instant at which the requested action was actually performed.
For historical data stored in historical data files, a timestamp is the moment a given data item has a given value.For purposes of historical data files, the timestamp can be considered a key or index. I can do it. The time range specification of interest 123 can be used to request a search for a particular piece of information stored with a predetermined key or index.

26 Range of Interest The time range of interest specification is specified using the 0 time specifier provided on request using the time specifier field 123.
Other values of data than the "currently entitled value" can be displayed and processed, and statistics can be calculated over a period of time. In one particular embodiment, the "time range of interest" is represented by a prepositional phrase in the time specifier of the request. Although time specifiers are generally used with 5HO14 instructions, time contexts can also be applied to MODIFY style requests and actions.

The time ranges of interest are absolute instants, sequences of absolute instants, time intervals (start time rsTART, and duration rDt
lRJ), a repetition of an instant, or a repetition of a time interval.

These are all relative periods that specify the periodicity with which an instant, instants, or time intervals repeat.
) If a zero period is specified that can be associated with them, the original moment or sequence of moments or time interval is treated as a base and the period is added to this base. For example, time specification r5:00 EVERY O:1
5 is equivalent to 5:00, 5:15, 5:30, 5:45°, and so on. Absolute time instant (rUNTIL J
) can be specified to indicate when the iteration is to be terminated. For example, time specification r 5: EVERE
Y O:15υNTIL6:00. is 5:00, 5:1
5, 5 + 30, 5:45, 6: You can specify the 0 repetition time interval, which is equivalent to Go, in the same way6.
rSTART5:000UR:05 EVERYl:O
OJ is time interval 5:00-5:05, 6:Go -6:
It is equivalent to 05, 7:00-7:05...

3. Scheduling Scheduling information can also be indicated by the time designator field 123. A particular scheduling time can be expressed as either an absolute instant or a series of absolute times. Unlike a range of interest, a scheduling time cannot include a time interval; a time interval whose start and end points are equal is an "instant" (e.g., (TO
Break down into DAY, TODAY) ).

There are some rules that apply to time intervals. past time rr
The B interval may have a starting point indicated by the keyword YESTERD^Y or an absolute time in the past. Similarly, future time intervals are determined by the keyword lOHORROM,
Or it can have a dead center indicated by a future absolute time. Also, the start time of a time interval must be earlier than its end time.

4. Time Context Handling Structure As explained above, the scheduling and scope of interest information can be supplemented by requests with associated context handling. Handling is created by the module that executes the request and is subsequently used to communicate with the service provider. Upon receiving a call from a service provider, eg, an information manager, a context block is generated as a local reference to the request time context.

-a, context blocks and handling are used as criteria for the state of the request. Because an initial request can generate many dependent requests, it is possible to produce multiple handling and context blocks with a single request.6 Context blocks are the standard used by service providers, but handling is the criterion used by the service requester. Each process in the request/dependent request chain (i.e.
A module (or information manager) only knows about context blocks and treatments that are relevant to its local part of the chain.

Referring to FIG. 7B, in one particular embodiment, a time context treatment 172 created by a requester, e.g., presentation module 10, includes a range field 175 and a schedule field 176 related to the time specification 123 of the initial request. We are prepared. These fields supplement the request timer data and are used to determine the current state when multiple requests and responses exist for a single operation. Handling 172 also includes a context pointer 177 and a state variable 178. These data items are handled under W! A leap number and criterion function are created and stored using range field 175 and schedule field 176 when a request is made.

If there are multiple requests and responses for a single operation, the context field 177 will ultimately contain a pointer to another data structure 174, known as a context block. This is created and maintained by the service provider, e.g. the presentation and functionality surface 15 of the information manager, in response to an initial request requiring multiple responses (
Function modules and access modules can also create and maintain context blocks on demand).

The handling status field 178 has one of three values: rFIR3T,, rHORE,
, or r CANCELJ, these are used as flags to indicate further actions to take. When first created, the handling state is set to rFIR3T.

As explained above, if a request can be satisfied with a single response, a response is generated and returned to the requester. In a more general case, a service provider, for example a functional module, information manager or access module, cannot satisfy the request with one answer. For example, a requester can specify a group of entities by
Wildcards may be used in input entity parameters 121. Since each reply can only incorporate information from a single entity, several replies are required, one for each entity.

In other cases, requests for a single entity may include time specifiers with several different time values. Since each reply can only incorporate information for a single time value, several replies are required, one for each time. Requests featuring multiple replies include obtaining attribute data about an entity or entities, modifying attributes of some entities, and modifying the state of some entities;
may be for any type of operation, including

Once the service provider processes the request and determines that the request has another reply, it is responsible for indicating this to the requester. From then on, the requester is responsible for waiting for the service provider to make another reply.

To do this, an intermediate process, such as an information manager, must store information related to the request being generated.

This latter function, in addition to a pointer to a service provider's dispatch entry (see explanation below under the heading Dispatch Table), also points to handling that is concerned with dependent requests for a functional module, for example. Associated proprietary variables generated on demand, such as context pointers1
This is accomplished by creating a context block 174, which may include 73.

Handling and context blocks are used as follows. The service provider causes the requester to (1) cause the pointer 177 to point to the context block 174 of the requester treatment 172;
Set rHORE, to the value of rHORE, to signal that you have another reply using the appropriate handling modification routine. When the reply is returned to the requester, the requester looks at the r HORE status in its handling status field and knows that the service provider has another reply for this request. If the requester does not want these alternative replies, he must cancel the request (see below). If the requester wants a different reply, he must repeat the request without changing the parameters.

The service provider makes these repeated requests (this is rh).

(with a handling status field 178 equal to REJ), the appropriate handling access routine is used to locate and detect the r MORE J status.

The service provider then knows that the call is part of a previously established request. (Note that a treatment with a state of rFIR3T, indicates to the service provider that the associated call is the first invocation of the request.) For each call with a state of rHORE, a handling context field 177 Retrieve the pointed context block 174 and continue its execution using the context block to provide another reply. There is only one reply for each call made to the service provider. As long as the service provider keeps the handling parameters in the rHORE, state, the service provider has more replies to requests.

The service provider will notify the requester of its final reply (e.g.
(determined by scope field 175 and schedule field 176 in the requestor's treatment).
Requester handling status field 178 is rFIR3T
It is set back to the value of J (initial setting state B). When the return is sent to the requester with this final reply, the requester receives r
FIR3T, sees its handling parameter status set to + and knows that its request is fully satisfied.

Note that if the request is satisfied with a single reply, the service offeror does not preserve the context and never generates the state of the handling parameter that becomes the r MORE state, the requestor's handling is Configured rFIR8T
, indicating to the requester that the request is complete.

If the service provider returns the handling parameters in the rHOREJ state, the request must be repeated or canceled, if the request is otherwise discarded, due to the storage allocated to the handling and context blocks. This results in the loss of system resources.

Regarding the above discussion, note that if the service provider did not originate a dependent request, then the single treatment would suffice for the communication between the service requester and the provider. However, if a service provider originates a dependent request, then there are two or more separate treatments - an initial requester treatment generated by the call requester, and an initial requester treatment generated by, e.g., an information manager, e.g. There will be another treatment that is conveyed to the

If there are multiple requests and responses for a single operation, a scheduling dependent request to the service provider is made by the information manager and the time specification parameter 12
For each schedule time specified by the zero hour specification controlled by the schedule time precepts of No. 3, the information manager creates a request that causes the service provider to perform the requested action and generate a response.

When the service provider completes the requested action, it issues a response. When the information manager sees that the service provider has completed the requested action, it examines the scheduled time context for the initial request. If there is more time to schedule the requested operation, the information manager does not set the requester's handling status to rFIR3T, and rMOR
E, the requester sees that its handling parameters are still in the rHORE, state, knows that the entire request is not completed, and asks about the rest.The information manager then sets the predetermined schedule. Wait until the time is up and have the dispatcher make another call to the service provider. The service provider will send this next call to rFIR3T
Note that returning the handling state set to , does not preserve the context and is therefore indistinguishable from invoking a completely new request. It does not distinguish between the handling status of rHORE, generated by a service provider that is currently running, and the information manager that prepares a new schedule moment.

In the Pond embodiment, the handling access routine is enhanced to allow the requester to confirm the occurrence of the rHOREJ status of handling parameters.

During a request with multiple replies or multiple schedules, if the requester decides that he does not want any further replies from the service provider for this request, he must cancel the request, cancel the request. Possible reasons for attempting to do so include receiving an exception response indicating that no further data is useful, or receiving an error condition indicating that the desired action is not being performed correctly. It is the requester's responsibility. Cancellation terminates all activity of the request, including the scheduling and scope of the operation.

To cancel, the service provider sends rMORE to the requester.

This can be done when returning the handling parameter status. The requester performs the cancellation using the appropriate handling modification routine that changes the handling parameter state to the value rCANCEL, and reissues the call.

The requester must not change any other parameters to this call; when the service provider receives this call, it will set rcA instead of the expected rMOFtE, state.
Look at the handling parameters in the state of NcELJ. The service provider receives the context from the handling parameters,
It uses that context to perform any necessary cleansing, including canceling any lower-level requests it is making, terminating all processing, and returning system resources. Once the service provider has completed its purification, use the appropriate handling modification routine to adjust the handling parameters to rFIR3T.
The service provider then reinitializes and returns the state to
A special condition value return code of CANCELED is returned to indicate that the request was successfully canceled.

The requester cannot cancel the request after the service provider returns the handling parameter status of the rFIR3T. The request has already completed and there is no context for the service provider to cancel, so the cancellation routine described above will not return an error unless the handling state is rMORE.

F. Dispatch The dispatch table 28 includes a plurality of data structures, one of which is shown in FIG. 8A, and one of which is shown in FIG. 8B.
One or more dispatch lists containing the dispatch entries depicted in the diagram. The dispatch tree and dispatch list essentially form a review table used in reviewing requests, as described below in connection with FIG. Referring to FIG. 8A, the dispatch tree includes multiple entity nodes 130. entity node 1
30 are organized into a tree structure to aid in scrutiny, but they can be organized into other data structures. Entity nodes identify various entities within the complex system with which requests can be generated.

Entity nodes 130 each have a pointer to a dispatch entry 134 (FIG. 8B) of a dispatch list maintained in their respective dispatch table 128.

The term "entity node" is used to describe data structure 130. This is because it satisfies the entity model shown above. In general, data structure 130 satisfies the entity model because it comprises a hierarchical structure and its child structures that resemble it.

The term "entity node j" used to describe data structure 130 should not be confused with the term "entity" used to describe elements of a complex system.

Entity node 130 includes several fields, including a class/stage flag field 140 that indicates whether entity node 130 relates to an entity class or stage within a class. Each entity may be at the level of a class, and the class is defined by a class name distinguished by the entity's entity definition 46 (Figure 3A),
Table 24 lists other entities related to classes and stages, as described in Figure 9 and below.
A node 130 is provided.

While reviewing the request, the class name and stage name of the entity and its attributes are stored as data # in the format shown in Figure 8A.
I structure is used to probe, but the structure is used separately when inspecting class names and stage names. The status of a class or stage is indicated by a class/stage flag.

Entity node 130 also includes tree link pointers that identify various other elements within dispatch table 28. Modules that service requests related to several entities of the same class can be identified by wildcards or ellipses. If so, the associated entity node has a wildcard pointer in field 141 or an ellipsis pointer in field 142. Each wildcard pointer and ellipsis pointer is
It consists of tree link entries as described below. If the entry node pertains to a class with no levels, an example of which is described below in connection with FIG. - Equipped with a pointer. Finally, field 131 contains the code
An entry includes a code that identifies the class or name of the entity stage associated with the entity node as well as the link pointer.

The code entry field 131 shown in entity node 130 of FIG. 8A is one entry in the coded list. (The remainder of the list is not shown.) When referring to the class or name of an entity's stage, the encoding list refers to the entity's management specification (see Figures 3A through 3D) as defined by the entity's management specification (see Figures 3A through 3D). It is a linked list with the names of classes. Each coded entry 131 has a pointer 150 pointing to the next coded entry in the list, a class code/stage each numeric field 151, and a link entry 133 with a pointer to an entry node 130 or dispatch entry 134. Field 1
It is equipped with 52.

Class code/stage numeric field 151 of coded entry 131 comprises the class code or stage name. The contents of field 151 will be 0 if the class/stage flag field 140 of entity node 130 is adjusted to identify the entity node associated with the class.
Alternatively, the contents of field 151 comprises the stage name if the class/stage flag field 140 of entity node 130 is adjusted to identify the entity node associated with the stage.

Referring to Figure 8B, dispatch entries 134 in the dispatch list are used to identify the particular procedure to process the request. The dispatch list is an linked list of one or more dispatch entries 134, each entry 134 containing information useful in forwarding a request or dependent request to the appropriate functional module 11 or access module 12. More specifically, dispatch entry 134 includes a pointer 160 that points to the next dispatch entry 134 in the list. Field 161 contains the identifier of the functional module 11 or access module 12 during whose registration a dispatch entry 134 is generated. Dispatch entry 134 includes a series of fields 162-164 that point to procedures, processes, and nodes within the complex to handle requests. Field 165 identifies the verb to which the dispatch entry pertains, and attribute field 166 identifies the verb to which the dispatch entry relates;
The set of attributes identified by the attributes defined by the attribute definition field 54 of Figure B) is identified. Finally, the count field 167 indicates that the dispatcher has entered the dispatch entry 13 in connection with processing a request or dependent request.
Identify the number of times 4 was used.

With this background, the process followed by dispatcher 16 in reviewing and dispatching requests from presentation module 10 will be described in connection with FIG. dispatcher 2
It will be seen that 180 performs a similar process in conjunction with dependent requests from functional module 11.Referring to FIG. 9, request 180 is as follows.

5l(OW NODB <node nalle>ROUTIN
G CI RCU I T < routing ccu
it name >CHARACTERISTIC5 This is used in conjunction with distributed digital data processing systems. Request 180 includes a number of compartments, including a verb compartment 181, namely 5HOW, an entity compartment consisting of a plurality of entity class codes and stage names 182-186, and an attribute compartment 187 consisting of a plurality of attributes. In this example, the verb 5HOW initiates the generation of a response from the entity named in the request that is related to the named property.

In request 180, the entity partition, element 18
2 to 186, comprises a large number of class/stage pairs. In particular, element 182, MODE, is the class code and element 183, <node naIIe
> identifies the stage of entity class N0DB by the stage name <node nane >.

In a distributed digital data processing system, identifying nodes within the distributed digital data processing system,
(node name > identifies a node within a distributed digital data processing system.

In addition, the request 180 further includes an entity class code 184 that has no stage in the entity partition, RO
Equipped with UTING. Request 180 also has another entity class code, elRcUIT, which is <ROUTING CIRCUIT
It has a stage identified by NAME >.

Referring to Figures 3A through 3D depicting management specifications, various elements of requirements associated with an entity are specified by the management specifications. In particular, the verb section 181 of the request is taken from the directive specified by directive specification 56, the entity class salt and subentity class salt 182.184.185 are taken from the entity class code field 47, The attribute section 187 is taken from the attribute definition 54 of the management specification for the entity.

The stage names of entities and subentities are taken from stage data known to the user (eg, by reference to a configuration database or through automatically generated menus).

In response to receiving the request, dispatcher 16 uses entity node 130 (FIG. 8) to begin scanning the elements within the entity partition, starting with global entity class code element 182. In particular, with reference to FIG. 9A, the dispatcher 16 begins (step 190) with a root entity node that is provided with a class/stage flag 140 that identifies the entity node associated with the class code and selects the MODE. Class code field 15 with class code
Dispatcher 1 looks for an entry in its encoding list 131 that contains an encoding entry with 1.
6 cannot find such an entry in the dispatch table 28, the dispatcher 16 looks for a wildcard or ellipsis pointer (see below). When the dispatcher 16 locates such an entity node 130 in the dispatch table 28, it proceeds to the next step of the probe operation (step 191), in which: The stage specified in the entity element 183 (nod
Entity node 1 associated with e naIIe )
Trying to track down 30. In this operation, the dispatcher 16 uses the contents of the pointer field 152 of the encoded entry 131 to identify the entity node associated with the stage name and whose encoded list identifies the entity 180 requesting the stage name entry. Entity nodes with class/stage flags 140 that have a coded entry corresponding to (node naIle > of element 183 are located. Again, dispatcher 16 places such nodes in dispatch table 2.
If you can't find 8, look for a wildcard or ellipsis pointer (see below).

On the other hand, in step 191, the despatcher 16
Once the entity node associated with element 183 is located in table 28, the next step (step 192) is to attempt to locate the entity node associated with class code 184, ROUTING.

With this operation, the dispatcher 16 sends coded entry 1
31 and the entity element RO1JTI NG from the request to identify the entity node associated with the class code whose coded entry list comprises ROlJTING. Locate an entity node 130 with a class/stage flag 140 that has an encoded entry 131 with a class/stage flag 140 . In this situation, the entity class RO
Since UT I NG is a stageless entity class, pointer field 152 of encoded entry 131 is null. In this case, the null pointer field 143 of the entity node 130 points to the second entity node 130 associated with the class entity CIRCUIT.

In step 192, dispatcher 16 uses the null pointer of entity node 130 pointing to the ROUTING class entity located in step 192 to determine that the class/stage flag 140 is associated with the class code. the second entity node 1 indicating
30 and its class code field 151 is C
locating the encoded list comprising the encoded entry 131 comprising the IRCUIT (step 193);
If the dispatcher cannot locate such an entity node, it looks for a wild-card or ellipsis pointer (see below).

On the other hand, if the dispatcher 16 locates the entity node 130 in step 193, it proceeds to step 194, where the stage entity element (ROlJTING CI
RCUIT NAME>. With this action, dispatcher 16 causes field 1 of coded entry 131 to
52 pointer to its class/stage flag 1
40 identifies this as being associated with a stage name and its coded list indicates that its stage name field 151 is associated with request 18.
(ROUTING
CIRCUIT NAME). dispatcher 1
If 6 cannot locate such an entry, it looks for a wildcard or ellipsis pointer (see below).

On the other hand, if dispatcher 16 locates stage entity node 130 identifying stage entity element 186 in step 194, dispatcher 16
80 entity sections 182 to 186 have been successfully examined.

Dispatcher 16 then uses the pointer in field 152 of encoded entry 131 located in step 194 to process the request using the verb in element 181 and the attributes in characteristic element 187 of the request. Identifying dispatch entries 134 (FIG. 8B). In particular, following step 194, dispatcher 16 uses the pointer in field 152 of coded entry 131 to identify a list of dispatch entries 134. Thereafter, Dispatcher 16 has its verb field 165 whose content corresponds to verb element 181 of request 180, in this case 5HOW, and whose attribute field 1
An attempt is made to locate the dispatch entry 134 whose contents in 66 correspond to the attributes of characteristic element 187.

If dispatcher 16 locates such a dispatch entry 134 in step 195, it uses the contents of procedure identification field 162, process identification field 163, and node identification field 164 to invoke a procedure to process the request; With this action, dispatcher 16 effectively forwards the request to the processing entity. As discussed in connection with FIG. 6, if the process identifier in field 163 and the node identifier in field 164 identify a process or node other than that associated with the dispatcher, then the dispatcher will accept the request for processing. Transfer to the dispatcher of the other process or node identified in the respective fields 163 and 164.

Described above is the use of coded entries in the dispatch table. Wildcards and ellipsis pointers provide additional functionality to tables. g4 For example,
One management module can handle all requests for modules of a particular global or subordinate entity class. Without wildcards and ellipsis pointers, all class stages and subclass stages would be listed in the dispatch table. To avoid this, wildcards and ellipsis pointers can be used to 39A to indicate in a general way which entity classes or stages service management modules.

An example of such a dispatch specification is N0DDE ROUTING CIRCUIT, which specifies that a module is a global node of the N0DE class.
In all cases of the entity, it is indicated that all the subentities of the CIRCUIT class subentities of the subentity class CIRCUIT can also be handled. The asterisk (*) matches any stage name, and the ellipsis (
) matches all of the subentity stages or subentity class/stage pairs that may follow6. For example, the expression N0DE foo ROLJTING CIRC
IJIT bar LINK fred conforms to the batch specifications. Because “ゝ” is rfoo.”
, and r , , , is rbar LINK
This is because fredJi is compatible.

Referring to FIG. 9B, to enter the wildcard dispatch specification for the dispatch table 28, step 19
1 (FIG. 9A), which corresponds to the stage name of the N0DE class entity. The wildcard pointers 141 are changed to point to new entity nodes 130 containing class codes, one of which is the class code ROtJTING (step 196), and the child pointers associated with the class code ROUTING become null. (Similar to step 192 (Figure 9A)), the null pointer points to a new entity node 130 in the pond that will have a child pointer corresponding to the class name CIRCUIT (step 197>).

This child pointer points to another new entity node 13
0 (step 198) and its ellipsis pointer points to the dispatch entry for the module (step 199).

The examination of the modification table is the same as that described with reference to FIG. 9A up to step 191. In step 191, the dispatcher 16 sends the name, e.g. rf.

If this name is found in a coded entry (three are shown for illustration purposes), the dispatcher follows the child pointer of the coded entry.

However, if the name "rfoo" is not found in the coded entry (indicated by the null NEXT ENTRY pointer of the last coded entry), the dispatcher looks for a non-null wildcard pointer in step 191. After determining the
The dispatcher proceeds to step 196.

Steps 196 and 197 are the same as steps 192 and 193 in FIG. 9A. The dispatcher in step 196 (class code rRO1JTING.

) and move to step 197 using the null pointer corresponding to the class code rCI RCU I T.

The child pointer corresponding to is used to move to step 198.

In step 198, the dispatcher searches the linked list of encoded entries (three are shown for illustration purposes) and r
Find out the stage name "bar". If this name is not found in the encoded entry, the dispatcher looks for a non-null wildcard pointer; if this is not found, the dispatcher looks for a non-null ellipsis pointer.

This was discovered and it took 4f until the dispatch entry.
(step 199). The contents of the dispatch entry are used to call the appropriate module.

Wildcards and ellipsis pointers allow general matching of entity class codes and stage names, but only after the coded entries in the dispatch table have been checked. In this way, the dispatcher does not look for the "best match" for the entity name and therefore, for example, the first module
IT can be provided. This module is N.

DE class global entity stage rJoe
” indicates that all stages of all CIRCUIT class subentities of the ROUTING class subentity can be handled. The second module is dispatch specification N0DE Joe ROUTING CIRCU
IT... can be provided. This module is N.

DE class global entity stage rJoe
” indicates that all stages of all CIRCUIT class subentities of the ROlJTI NG class subentity can be handled.

“In order not to contradict the most obvious conformity J rule, N0
DE Joe ROUTING CIRCUIT
All commands for subentities should be sent to the second module. This is accomplished using a dispatch table mechanism.

Because the stage name "rJoe" appears in the encoding entry in step 191, "rjoe" is ROUTING
If it is a stage name in a request to CIRCUIT,
jOe'' encoding entry will be used (because it is checked first) and the wildcard pointer will not be used.

To properly traverse the dispatch tree, the dispatcher must also use the stack. Let me explain why this is necessary with a simple example. Consider a new module with the dispatch specification N0DE jim DISKDRIVE-. This means that the module
Global entity stage til of N0DE class
t'Jim'' indicates that all stages of the subentities of the DISDRIVE class can be handled. This specification is entered into the tree in step 191 in a manner similar to FIG. 9B by appending the stage name "rJim" to the encoding entry followed by appending the new entity code. Following this, dispatching the request using the global entity class and stage name N0DE Jim will cause the dispatcher to transition to the new entity node.

However, N0DE Jim ROUTING CIRCU
Requests with entity names starting with IT will require a new module to be DISKDRIV for NUDE stage 'jim'.
It cannot be serviced by a new module because it only supports subentities of the E class, hence the dispatcher uses the class name ROU'T'ING
Once you have determined that CIRCUI'T' is not supported by the new module, return to step 191 and optionally use other encoding entries or wildcards or ellipsis pointers to set rNODE jim ROUT
INGCIRCUITJ must be provided to find a module to service the request, therefore, as the dispatcher traverses the dispatcher table, the dispatcher has severed the stack of pointers from the root node to the entity node 13.
Maintain for all 0's. As the pointer moves up and down the tree structure of the dispatch table, it is pushed in and out of this stack in an attempt to find the appropriate dispatch entry.

If no matching dispatch entry is found,
Errors are returned to the requester (i.e., presentation module or function module).

As explained above, the control module can serve as a pass-through from the presentation module to the direct access module. To achieve such pass-through, the ellipsis pointer to the root node of the Present9 functional aspect in the dispatch table (which matches the name of any entity in any request) points to the dispatch entry for the control functional module. When a request is received, the control function module simply issues the same request to the function access aspect of the dispatcher. In this manner, all requests that do not conform to the dispatch specifications in the Presentation and Functional Dispatch Table are communicated to the Functional Access Dispatch Table for compliance. This allows the presentation module's requests to access the primitive functionality available from the access module.

In another embodiment of the dispatch table, the null pointer field 143 is a linked list structurally similar to the list of coded entries 131 to allow for more than one class code without stages. The first element can be provided. The second, "null" list will contain code values for class codes with no stages. The null list is scrutinized after the code list and before checking for wildcards.

G. Domains and Configurations As mentioned above, configuration function module 11 maintains a configuration database that defines the entities that make up the complex system. With appropriate instructions from the operator, the configuration function module 11 can add stages of entities defined by the data dictionary to the configuration database, delete them from the configuration database, and alter the definitions in the configuration database. As noted above, the domain functionality module 11 establishes domain entities in the configuration database that refer to subsets of entities already defined in the treetop database. Through the presentation module 10, an operator can control and monitor an entity comprising a particular area without regard to the potentially countless other entities that make up the complex system. Additionally, the operator initiates control or monitoring actions in relation only to the entities within the area, without initiating the generation of requests by the presentation module 10 for each entity, thereby simplifying the control and monitoring of the complex system. can be converted into

The domain functionality module establishes a domain database for each domain entity that identifies the entities that make up the domain entity within or in addition to the configuration database. Upon receiving the urgent request, the domain functional module 11 adds the entity to the domain database, thereby adding the entity to the domain, removing the entity from the domain database, thereby removing the entity from the domain, and thereby removing the entity from the domain database. Generating a response identifying the entities that make up the region and deleting the region database, thereby effectively deleting the region.

Referring to FIG. 9C, the format of the configuration database and the region database (which can be combined into a single database) for each entity stage within a configuration, and similarly for each entity stage within a region, is as follows:
It has a field.

The realm database includes an entry 230 for each member of the realm, listing the realm name and stage 11R name of each member of the entry or subentity. In addition, the realm database includes an entry 232 for each entity that is a member of a realm, listing each stage name and the realm of which it is a member. The region functionality module may update this information as the region is modified and utilize this information to quickly determine the members of the region, or alternatively, quickly determine the region members of the entity.

In another example, the first region can incorporate members of the second region by referencing the second region;
In this way, the size of the area database is reduced. In other embodiments, the domain database may establish a hierarchy of domains similar to a hierarchy of entities and sub-entities, and instructions may be conveyed similarly to domains and sub-domains.

The configuration database includes entries 234 for each entity and subentity, organized hierarchically within the database.

A full name is provided for each entity and subentity stage. This information can be used by the configuration functionality module to quickly determine a configuration to display (via the presentation module) to the user, for example, a map of configurations or a menu of entity stage names.

As explained in connection with FIG. 1 in the H and W reports, one functional module 11 includes an alarm functional module 11,
This determines the alarm condition upon request from the presentation module 10 and detects the occurrence of the alarm condition using various conditions recorded in, for example, a user interface information file 29 of the entities of the complex system. can do.

FIG. 10A shows the functional organization of the alarm function module 11. Referring to FIG. 10A, the alarm function module 11 includes:
A general alarm module 200 is provided that receives requests from the modules and translates them so that one or more detector modules 201 or one or more rule maintenance modules 202 can act accordingly. As indicated above, the alarm function module performs two general types of operations: maintaining alarm conditions and detecting alarm conditions.

The operation of maintaining the alarm conditions of the alarm function module 11 is performed by the rule maintenance module 202. This module is
Alarm rule base 203 maintains rules that identify each alarm condition. Each rule represents a set of conditions that must be evaluated to determine the presence or absence of an alarm condition; in particular, rule maintenance module 202, in response to a request from presentation module 10, performs the following in connection with FIG. 10B: As described, rules are generated and stored in the alert rule base 203. In addition, the rule maintenance module 202 can modify the rules in the alert rule base 203 in response to a corresponding request from the presentation module 10, so that the alert condition represented by the rule exists. Conditions are modified.

Similarly, the operation of detecting an alarm condition is performed by the detector module 20.
1, this module uses, for example, condition information located in the historical data file (Figure 5) and alarm rules located in the alarm rule base 203, as described below in connection with Figure 10B. , each rule has a condition part that identifies the condition.Detector module 2
01 determines whether the contents of the historical data file comply with the conditions of various rules, for example, to detect an alarm condition. If so, the detector module 201 generates an alarm indication and the general alarm module 201
00 via the notification module 204 to, for example, the presentation module 10 and displayed to the operator.

The general form of an alarm rule generated by rule maintenance module 202 is shown in FIG. 10B. With reference to FIG. shows. The condition part is the expression part 212
, a relational operator 213°, and an expression numerical part 214. The relational operator 213 converts the expression part 212 into the expression numerical part 2.
14, the condition part 210 is logically TRUE.
(true) is logically evaluated to FALSE (false) If the 0 expression part 212 itself evaluates to logically TRUE or logically false, the relational operator 213 and the conditional part 2
It can be seen that the numerical value part 214 of formula 10 is unnecessary.In any case, the condition part is logical TR
As assessed by the UE, an alarm condition exists.

The rule includes an entity and attribute portion 212 and a time value portion 216. rel-Op value part 213
associates the value of one attribute with one numeric part 214, the zero time value part 216 establishes a time function, and the condition part 21
0 may indicate the time or time interval that the alarm detector module 201 should use.

The provision of the alarm fi function module 1 allows the operator to define alarm conditions dynamically and on demand. Since the V-reporting conditions do not need to be predetermined within the control device, the control device can be used to control and monitor a wide variety of complex systems, e.g. When used to control and monitor a distributed digital data processing system, which may include nodes, alarm conditions can be established by an operator based on a particular configuration. Additionally, if a new alarm condition is discovered during operation of the complex system, the alarm condition can be added by adding a rule to the alarm rule base 203.

We describe a system that provides control and management over a population of entities, in which entities interface with the population to control primary information processing functions, and entities further interface with the system to provide control and management functions to the population. To be able to perform a function. Such a system is equipped with a storage management module that performs management functions by independently translating and executing predetermined management-related commands, and the kernel translates the commands and sends the commands to each module to be executed. The register is used to register new management modules with the system by adding another pointer to the table.

We will further describe a system that controls and manages a group of entities.
Entities interface with populations to control key information processing functions, and entities further interface with systems to enable them to perform management functions.

Such a separate system has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions, and the kernel has a storage management module adapted to perform management functions by independently translating and executing predetermined management-related instructions. Stores a table of dispatch pointers that direct instructions to.

A system that controls a group of entities and performs management functions will be described separately. This system is equipped with a storage management module that independently translates and executes predetermined management-related commands, and stores a table of dispatch pointers that translate and direct instructions to the respective modules to be executed, and the register registers a new management module with the system by adding another pointer to the table. used.

Alternatives to such systems may include a management module adapted to request one or more state information from the entity, modify management parameters of the entity, or enable a self-test mode of the entity. The storage management specification information lists attributes related to the functionality and control of the entity, and the management capabilities of the entity, according to a universal specification language with a common syntax for representing the attributes and behaviors of any manageable entity. Management specification information may further list attributes and behaviors of entities that are subordinate to other entities. The management specification information can include polling information in a predetermined field of a common syntax. The polling information can include a to-yield that specifies a default rate and a maximum polling distance at which the value of the attribute should be requested from the entity.

Further describing the system, in this system, the management specification information can include partition information in a predetermined field of a common syntax, the partition information represents a group of attributes having a common data format, and the management specification information has a common syntax. The set information may be provided in a predetermined field of the entity, the set information represents a group of attributes having related functions in the management of the entity, and the management specification information may be provided with instruction information in a predetermined field of a common syntax. lists the administrative functions that the entity is supposed to perform, the MWi of commands to issue to the entity, and the 1111 structure of replies to receive. The structure of the request to be issued may also include fields that list arguments to the command. The structure of the reply to be received may also include fields used to indicate successful completion of the requested action.

Further, an alternative is described in which the structure of the reply to be received can include a field used to indicate an error condition that does not successfully complete the requested action. At least one management module includes an access module implementing a protocol for communicating with one or more entities. The protocol conforms to the Ethernet standard, or the protocol conforms to the DECnet P standard.
The protocol conforms to the DECnet Phase ■ standard.

Another alternative is described in which each instruction has a field listing at least one related entity and operation. The kernel includes a dispatcher that receives and communicates instructions based at least on the entities and operations listed therein. dispatch·
The table of pointers can comprise a data structure, a pointing graph of a continuous data structure with a graph corresponding to the fields of the instruction. The dispatcher includes a scrutinizer that traverses the instruction graph according to the entities and operations listed in the instruction and locates terminal data structures with dispatch pointers. The instruction graph can include wildcard flags and continuous data structures that can correspond to any value of a particular field of the instruction, or the instruction graph can correspond to any number of values of a field of the instruction. can be an ellipsis flag,
and a continuous data structure, or the scrutinizer determines the most accurate match for the field of the instruction by first looking for an exact match for the field and then for an exact wildcard match for the field. unit can be provided.

An alternative to such systems is a scrutinizer with a best fit unit that determines the most accurate fit to the field of the instruction by first looking for an exact fit to the field and then an ellipsis fit that seals the field. It is equipped with The instruction graph includes wildcard flags and continuous data structures that can correspond to any value of a particular field of an instruction, ellipsis flags that can correspond to any number of values of a field of an instruction, and continuous a data structure, the scrutinizer finds the most accurate match for the field of the instruction by first looking for an exact match for the field, then for a wildcard match for the field, then for an ellipsis match for the field. The best fitting unit is determined. A presentation device is used to display information to a user and receive instructions from the user, the instructions and information being represented in a particular predetermined format.

Yet another alternative system receives instructions from a presentation device;
A presentation module is used to communicate information to a presentation device, the presentation module including a translation code that converts information received from an entity into a predetermined format for the presentation device, and a transfer code that communicates instructions from the presentation device to a dispatcher. .

The presentation module may include user interface information that defines the mode in which a user interacts with the system. User interface information may include assistance information that provides information to the user regarding how to use the system. User interface information may include graphics mode information that defines the contents of pop-up menus and command line review tables.

The kernel may further include a class database that defines the different management information available from each entity. The presentation module may include a menu generation routine that extracts data from the class database and generates a menu of valid instructions to display to the user. The menu generation routine may determine information related to the composition of the population and generate a menu of available entities to display to the user.

Describes a system that provides control and management functions for the members of a computer network, in which the members interface within the network to control key information processing functions, and
Members also interface with the system to enable them to perform administrative functions. Such a system consists of a storage management module that performs management functions by independently translating and executing predetermined management-related commands, and a dispatch module that translates the commands and directs the commands to the respective modules to be executed. - A kernel that stores a table of pointers and a register that is used to register a new management module with the system by adding another pointer to the table. The register is adapted to register new management modules at any time during system operation. An alternative to such a system describes a system in which storage members store records related to administrative functions, each record including an associated time indication. The instructions specify a time range, and the information manager satisfies the instructions by retrieving administrative information contained in the records, if possible, and in other cases, by retrieving the specified time range from members of the network. means for satisfying the instructions by accessing information related to the instructions. Another alternative to such systems is that at least one module stores rules identifying predetermined alarm conditions, but includes a rule generator that generates and stores the rules and detects the alarm conditions depending on the content of the rules. Equipped with an alarm condition detector. The first category of management modules comprises functional modules adapted to perform all functional manipulations of data presented by members of the network. The second category of management modules comprises access modules adapted to implement protocols for communicating with members of the network. The presentation module is adapted to receive instructions from the user and communicate information to the user using the primary information processing capabilities of the members of the network.

The storage device further includes region designation information defining groups of members of the network. The kernel can cause commands to be issued to all members of the group by issuing individual commands to the appropriate management module. The at least one management module is further adapted to perform self-management functions for itself by independently translating and executing self-management instructions. The information manager further includes a scheduler responsive to instructions specifying a time schedule. The scheduler is used to possibly enable successive dependent accesses or searches in response to instructions, possibly multiple times, according to a time schedule.

Describes a process in which an entity provides control and performs management functions over a population of entities, in which an entity interfaces with the population to control primary information processing functions, and in which the entity also performs management functions. It can be so. The process includes the steps of providing a management module that performs management functions by independently translating and executing predetermined management-related commands, dispatching commands to translate commands and directing commands to the respective modules to be executed. - It consists of providing a kernel with a table of pointers and providing a register that registers new management modules in the system by adding another pointer to the table.

In order to be used in a system that controls and performs management functions over a group of entities, a management system is stored in such a way that it performs management functions by independently translating and executing predetermined management-related instructions. We refer to modules, in which an entity interfaces within a collective to control primary information processing functions, and an entity can further interface with a system to perform management functions, where a system has multiple management modules and commands. A kernel with a table of disbatch pointers that directs instructions to each module to be translated and executed. refers to the module,
related to the instructions translated and executed by the module,
Disbatch pointers are also discussed.

[Brief explanation of drawings]

FIG. 1A is a functional block diagram of a control device constructed in accordance with the present invention. FIG. 1B is a block diagram of information stored in the storage elements of FIG. 1A. FIG. 2A is a functional block diagram of a part of the control device shown in FIG. 1A, particularly a portion defining entities forming the control device. Figure 2B shows the structure of the management module. 3A to 3D define management specifications that define control charts provided by the functional modules and access modules that make up the control device shown in FIG. 1A, and FIG. Defines dispatch specifications for modules. FIG. 4 shows the structure of a data dictionary containing information defined by the management specifications shown in FIGS. 3A to 3D. 5 and 6 are functional block diagrams showing various modules and data structures of the control device shown in FIG. 1A. FIG. 7A shows the parameters used for requests generated by the presentation and functional modules of the controller shown in FIG. 1A. FIG. 7B shows the #I structure of the temporal context handling and context block used by the requirements of FIG. 7A. 8A and 8B show dispatch table data used by the dispatcher shown in FIGS. 5 and 6 in connection with processing requests from the presentation module and functional module of the controller shown in FIG. 1A. #S″ii. FIGS. 9A and 9B illustrate the operation of a dispatcher in conjunction with its associated dispatch table in processing requests from presentation or functional modules. FIG. 9C illustrates the configuration database and Figure 10A shows the structure of the functional modules used to establish and detect alarm conditions, and Figure 10B shows the structure of the rules used to establish alarm conditions. 10... Presentation module 11... Function module 12... Access module 15... Information manager 17.22... Data storage device

Claims (1)

[Scope of Claims] 1. A system for retrieving management information for a population of entities in response to an instruction specifying a time parameter, wherein each record related to the management information includes an indication of an associated time. a storage device comprising a record; and a storage device for retrieving or accessing administrative information contained in said record in response to instructions, possibly multiple times according to said time schedule. an information manager with a scheduler possibly issuing a series of dependent accesses or searches corresponding to said instructions. 2. A system for retrieving administrative information about a member of a computer network in response to instructions specifying time parameters, the member interfacing with the network to control primary information processing functions, and the member further controlling the system. a recording device comprising records associated with said management function, each record including an indication of an associated time; and instructions. retrieving administrative information contained in said record or accessing administrative information from said member in response to said time schedule, possibly in a series of accesses or retrievals corresponding to instructions, possibly multiple times according to said time schedule; an information manager having a scheduler for generating information, wherein events occurring within the network are processed as components of the state of the network and stored in the record. 3. A method for retrieving management information for a collection of entities in response to instructions specifying time parameters, the entity interfacing with the collection to control primary information processing functions, and the entity further interfacing with the system. providing access to said management information by: providing a storage device comprising records relating to said management information, each record including an indication of an associated time; retrieving administrative information contained in said record or accessing administrative information from said entity in response to said instruction, said sequence of dependent accesses or retrievals corresponding to said instruction possibly multiple times according to said time schedule; A method comprising the steps of providing an information manager having a scheduler that issues a scheduler.