JPH03105547A - Alarm based on role for entity managing system - Google Patents

Abstract

PURPOSE: To process a primitive operation in connection with entity constituting a composite system by providing a rule generator which stores a rule for discriminating a prescribed alarm condition in at least one module of storage management modules which operate managing functions, and generates the stored rule, and an alarm condition detector. CONSTITUTION: A rule maintenance module 202 generates a rule according to a demand from a presentation module 10, and the rule is stored in an alarm rule base 203. Also, the rule maintenance module 202 corrects the rule in the alarm rule base 203 according to the corresponding demand from the presentation module 10. A detector module 201 decides whether or not the content of a historic data file is suitable to the condition of each kind of rule in order to detect an alarm condition, and when it is suitable, the detector module 201 generates an alarm instruction, and the instruction is transferred through a communication module 204 to, for example, the presentation module 10 by a synthetic alarm module 200, and displayed to an operator.

Description

DETAILED DESCRIPTION OF THE INVENTION FIELD OF INDUSTRIAL APPLICATION 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, become smaller and less expensive, individual computers are being used by individuals and small groups. To increase the economy of data distribution, communication between users, and the involvement of resources that individuals do not use frequently, computers, in addition to those directly used by each user, can be used, for example, by many users in a system. Connected to a network that communicates by messages conveyed through communication links, including servers that store large amounts of data that may be accessed, used, and updated, thereby facilitating the distribution of data. It is coming. The server may also control printers, telecommunications links, etc. In addition, the server may perform specialized computational services such as database searching, classification, etc. The various computers, called 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 controller for controlling and monitoring complex systems, such as distributed digital data processing systems, in which multiple computers communicate through a local area network. This is what we provide. Briefly summarized, the controller processes requests generated in response to commands from an operator through one or more presentation modules, functional modules, and power channel 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 commands from an operator and presenting responses thereto. In response to instructions from an operator, the presentation module generates requests.

The kernel means receives requests and communicates them to functional modules for further processing. Functional modules handle general functional operations in connection with processing requests. In response to a request, a functional module generates one or more requests (sometimes referred to hereinafter as dependent requests for convenience), which are forwarded to kernel means for processing or to other functional modules. The kernel means communicates received dependent requests to the access module for processing.The access module handles primitive operations in connection with the entities that make up the complex system.

In general, the present invention is a system for controlling and performing management functions over a population of entities, wherein the entities interface with the population to control primary information processing functions, and the entities further interface with the system to perform management functions. The system is characterized by being able to perform The system includes a storage management module adapted to perform management functions by executing predetermined management-related instructions, at least one module storing rules identifying predetermined alarm conditions; The apparatus includes a rule generator that generates a storage rule, and an alarm condition detector that detects an alarm condition according to the content of the rule.

The management module performs management functions by independently translating and executing predetermined management-related commands.
At least some management functions generate management information that indicates the status of one or more entity's primary information processing functions. A rule specifies the value of management information one or more times. The system includes a storage device with records of management information, each record containing an associated time indication. The system includes a historical data recorder that periodically accesses and stores new management information in a record according to a predetermined schedule.

The first category of management modules comprises functional modules adapted to perform functional manipulation of data provided by members of the network. The second category of management modules comprises access modules adapted to implement protocols for communicating with members of said network. The presentation module is adapted to receive instructions from the user and convey information to the user using the primary information processing capabilities of the members of the network. The system has a kernel consisting of a class database that specifies the different management information available from each member of the network. The presentation module is
It has a menu generation routine that extracts data from the class database and generates a menu of valid commands to display to the user. The menu generation routine determines information related to the configuration of the network and generates and displays a menu of available network members to the user. The system includes a storage device with area specification information defining groups of members of the network, and the power channel issues commands to all members of one group by issuing individual commands to the appropriate management module. It looks like this. At least one management module is further adapted to perform self-management functions for itself by independently translating and executing self-management instructions. The kernel also has a table of dispatch pointers that translate and direct instructions to each module to be executed, and the register registers new management modules with the system by adding another pointer to the table. ．． The kernel further includes an information manager with a scheduler responsive to instructions specifying a time schedule, the scheduler possibly enabling a series of dependent accesses or retrievals in response to the instructions, possibly multiple times according to the time schedule. ．． 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.) Preliminary An example of a complex system controlled by the apparatus shown in FIG. - Equipped with a data processing system.

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. IA 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 apparatus of FIG. 1A has scalability features that allow the apparatus to be modified to efficiently accommodate 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 contains all local area network bridges from a given vendor. Each entity is a member of a class and forms a stage of that class. Referring to FIG. IA, the controller is connected to the presentation module IO
A to 10K (identified as a whole by the reference numeral 10),
Functional modules IIA to 11M (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 functional module 11 typically provides administrative control and monitoring associated with one class of functionality. Each access module 12 is generally a set belonging to a class of controllable entities within the control system and provides administrative control over a particular type of controllable entity. Presentation module 1
0 communicates with the functional module 11 through the presentation and function aspects of the kernels 13 and 14 (hereinafter simply referred to as presentation and function kernel l3), and the functional module 11 communicates with the function module 11 through the presentation and function aspects of the kernels 13 and 14 (hereinafter simply referred to as presentation and function kernel l3);
It communicates with the access module through 14 function/access aspects (hereafter simply referred to as function/access kernel 14). The functionality required from control modules 10, 1l, 12 may vary widely depending on the topology of the complex system being managed. Therefore, the control modules 10, 11 are designed to provide adaptive and scalable management.
, 12 can be dynamically added or subtracted to the device to adapt the device to the topology of a particular complex system and to changes in that topology. Furthermore, for purposes 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 10 performs presentation services, which may include, for example, system
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 presentation service is required independently of the management function or entity managed by the system shown in Figure IA, and is 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 may provide various types of graphical displays, e.g.
Provide specific output assistance to the operator regarding histograms, bar diagrams, pie diagrams, or other forms of pictorial representations to be displayed on the terminal screen. Yet another presentation module 10 provides administrative requests to the presentation and functionality capabilities panel 13, which may be annotated by portraits, menus, graphics, or commands entered by the operator on the command line.
and transfers management information from the presentation and functionality kernel 13 to a video display terminal used by the operator for display.

B. Functional Module Functional module 11 is associated with and supports specific management applications performed by the control device shown in FIG. IA. Management applications include 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 by the control manager) and the specific entities that make up the complex system managed by the control manager. It exists independently of. A management application that the functional module 11 can perform is, for example, analyzing the communication load of a distributed data transmission system. To perform such analysis, the functional module accesses communication data such as the number of packets and the number of bytes sent from several entities of the distributed data transmission system. The Il function module then matches the information with higher level information such as average packet size and utilization of communication resources 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 add value to the management information available from the complex system. In one particular controller for controlling a distributed digital data processing system, one I!! function module 11 performs, for example, the topology of the network. The topology is managed and presented to the operator through the presentation module 10. Other function modules 11 define, for example, the configuration of the distributed digital data processing system, i.e. the various stages of entities and their interrelationships. , nodes and other entity levels can be added to and removed from the network, allowing operators to control the structure of the network, modifying access rights by various users of nodes, and providing a configuration (or level) database. A control function module may be provided which maintains the network configuration and allows the operator to decide on changes to the configuration of the network at any time. The alarm function module 11 monitors the status and conditions of various entities of the distributed digital data processing system and issues alarm instructions to the operator. However, a suitable presentation module 10 advises its operator depending on the state or condition having a predetermined value.A further functional module l1 may, for example, determine the domain of an entity within a distributed digital data processing system. and may limit or facilitate operator control or monitoring.

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, the 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 function module 11 is initially called by the presentation and function kernel 13 in response to an administrative request entered by an operator obtained by the presentation module 10. The R function module 11 is connected to other function modules. - It is also called by a request received directly from the module 11. 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 as shown in FIG. , 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. It can include not only constituent elements but also software elliptical elements including virtual circuits, databases, etc. Access module 12 is called by function access kernel 14 in response to a request from function module 11.

The access module l2 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 send 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 the 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 include various information indicating the operation of the message generation and decoding portions of the various nodes of the distributed digital data processing system, virtual circuits, secession and other links established between the nodes, and their activity and inactivity. Timers, counters, etc. can be controlled and monitored.

Similarly, other access modules 12 control and monitor 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. be able to.

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 l2 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 an Ethernet LAN bridge or an IEEE 802111 capable Ethernet station, a boat fraction control and check function at an Ethernet repeater, or a management function at an FDDI entity. can do. In addition, the access module is the DBCnet Ph
It can be provided to access management support equipment at an aselv or PhaseV node or a DEC terminal server.

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. In processing such requests, one or more assessment modules 12 perform predetermined actions that change the state or condition of one or more entities of the complex system being managed. The access module 12 that processes such requests generates status information indicating the status of the request and returns this to the functional 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. In other cases, information stored in the controller (such as by a historical data recorder functional module) may be used to satisfy the request. In that case, requests can be of both types.

That is, a request can change the state or condition of one or more entities, and the changed state of the entity g.
or request information regarding the terms and conditions. In processing such a request, access module 12 causes changes, if possible, and returns 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 IO controlling the terminal generates a request and transmits it to the presentation and function kernel 13. In addition, requests can be generated directly by the appropriate functional module 11. for example,
A functional module 11 acting as a historical data recorder generates requests to periodically check the state or condition of each entity of the complex system and stores it in a historical database for later processing as required by the operator. let

E, Kernel The kernels l3 and 14 are information managers 15 and 20 (hereinafter simply referred to as the information manager 15 or the information manager 20, but we are referring to one and the same information manager), a dispatcher 16, 21 (hereinafter simply referred to as dispatcher 16 or dispatcher 21, the two members forming one and two dispatchers, and the data storage element 17)
, 22 (hereinafter simply referred to as data storage device 17 or data storage device 22, referring to one and the same data storage element as explained below).

F. Data storage device 17.22 may include one or more RAMs with dispatcher data storage, or one or more fixed disk drives, or other storage devices, depending on the type and amount of data to be stored. means can be provided. Additionally, data in different formats may be stored in various storage means for later use by the kernel.
All these means are integrated into one data storage element 17,
It is graphically represented by 22. Looking at Figure IB. In one embodiment, the data storage elements 17, 22 store information at each time regarding the presence and status of the various entities that police the complex system, and in particular the predetermined information regarding the status and conditions of the various entities controlled by the access module 10. information as obtained by the historical data recorder function module 11. This is stored in the historical database 26. Other information may also be stored in data storage elements 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 a user's scope of control. Alternatively, region information can be stored as an element of a configuration database.

Also, does the alarm module use the alarm rule base 24? You can check the alarm status within the complex system. Information on songs relating to individual modules within the control device may also be held in the storage elements 17, 22. For example, as detailed below, dispatchers 16, 21
The 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 control device may maintain a data dictionary 27 that stores attributes, commands, and sub-entities for each of the various classes of entities within the complex system. This latter information can be used, for example, to process requests from users or to generate menus to prompt user requests. G. Information Manager 15 Referring to FIG. 1A, the information manager 15 receives requests from the presentation module 10 to which it can respond using information in the data storage element 17, as will be explained in more detail below. Then, 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 the request to the operator who generated it. 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 a 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, hereafter referred to as dependent requests, and communicates this to other functional modules 11 or to the 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.
, a dispatcher 21, and a data storage element 22
It is equipped with Dependency requests from functional modules 11 directed to functional access kernel 14 are first received by 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. and transmits this to the functional module 11 that 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 immediately or at a scheduled time, the information manager 20 forwards the dependent request to the dispatcher 21.
In response to receiving the dependent request from the information manager 20, the dispatcher 21 identifies the access module 12 to which the dependent request should be communicated and forwards the dependent request to this access module.
Transfer to 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 transmits it to the functional module 11 that originated the request.
Transfer to. The function module 11 uses the response from the access module 12 in formatting its response to a request from the dispatcher 16 or its response to a subordinate request from the function module 11, as applicable. do.

When the functional module 11 receives a dependent request from the pond functional module 11, it processes it in the same manner as it processes requests from the dispatcher 21. Advantages The control system shown in Figure IA 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. Therefore, if the information manager 15.20 is able to process the request based on the contents of the associated data store 17, 22 without the need for further processing to other elements further down the chain, the information manager Vessel 15.20 does so.

Furthermore, since the control device is expandable, additional presentation modules 10.11 functionality modules 11 and access modules 12 can be easily added without changing the structure of the control device, as explained below. be able to. 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.11
The addition or deletion of or 12 includes certain data structures of data storage elements 17.22, as described below.
and other data structures maintained by the presentation module 10, as shown in FIG. Additionally, the modular and expandable nature of the control device makes it easier to manage the control device itself. The same dispatch and request models used to issue management commands to a 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 R capabilities of a module are specified in a standard format and available to the controller as a whole, the controller becomes a complete user interface support for the module, allowing the module designer to create a user interface for each module. Free yourself from the burden of providing support. This type of "automatic" user interface aid ensures a uniform look and feel for the user interface, regardless of the source or nature of the management module being used.

When a controller is used to control a distributed digital data processing system, the controller, including its various elements,
A distributed digital data processing system can include multiple routines that are processed by the various nodes and computers that make up the system. In other words, the computer equipment does not need to process the modules that make up the control device that controls the distributed digital data processing system, other than those that control the distributed digital data processing system being controlled. Traditional procedure invocation mechanisms, interprocess communication mechanisms, and internode communication mechanisms are used to communicate communications, including requests, dependent requests, and responses, to different parts of the same process, to different processes on the same node, and to different processes on the same node. Transfers can be made between parts of the control unit that may reside on different nodes. If the modules reside in different processes on the same node or on different nodes,
The interprocess and internode communication mechanisms shown in FIG. 6 and described below are used to transfer requests and dependent requests, as well as responses, between various processes and nodes. 1. Entity Model Before proceeding further, it may be helpful to further explain the relationship between the IIJ# device shown in Figure IA and the complex system being controlled. In particular, with reference to FIG. 2A, the controller includes a command unit 35 with all of the presentation module 10, a functional module 11, and an accelerator.
It has module 12 along with 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 33. 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 entity's main functions or functions. That is, service element 31 performs the functions of an entity required within the context of a distributed digital data processing system. For example, when an entity communicates with a node through the network, the service element 31 communicates. 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/closing of the service element 31 and its initial setting, and also allows the command unit 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 broadly the parameters that pertain to its functioning and control as well as to commands. For example, in the case of a router whose entity communicates data baggets 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 SHOW to retrieve attribute values;
There are also SETs that 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 roles 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. Modems can be equipped with 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. Baud rate, line selection, and power switch settings are related to the immediate operation of the modem and are themselves accessible through the service interface. Line utilization and the elapsed time since the modem's last self-test and general operation, and as such, 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 accelerator module of the control device can also manage the presentation device, for example by boring and determining if it is on. In addition to the attributes described above, there are other "pseudo-attributes" that are related to the entity but are not stored by the entity as such. Pseudo-attributes are generally needed to describe the entity model, but are not stored by the entity. This is an attribute that is not provided.

An example is the attribute IMPLEM supplied by an entity.
IMPLEMENTATION, which is a composition of ENTATION TYPE and VERSION, 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) Realize an ideal access module, (3)
Plug the access module into the control device (register)
It can be managed by J. As noted above in the management module management section, the control device that controls the distributed digital data processing system uses various presentation modules 1o.
．． 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 io, it, 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 a 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 the request syntax. Therefore, as the ability to manage complex systems increases by adding new control modules, the ability to manage control devices increases as well. Details explanation A. Management module Kozuzo 1. Overview Referring to FIG. 2B, in one particular embodiment,
In particular, in the case of an access module, the executable code comprises executable code 38 that implements the management functions provided by the module. It has a protocol.

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 can require private 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 modules 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, disbatch pointer 39A is associated with procedures within modules that perform management services for 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 Specification The nature, composition, 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 (FIG. 1) are specified by the management specification and the dispatch specification. be done. Figures 3A to 3D are details of the management specifications for the entity, and Figure 3E defines the dispatch specifications used to initiate specific operations in relation to the entity. 3rd A first
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 identifying the entity, a variant field with variant identification, and a position indicating the location of the entity within the complex system. Contains certain identifying information, such as an equipment field 43 comprising information (e.g., node identification if the complex system is a distributed digital data processing system) and a format declaration field 44 indicating predetermined data format information. I'm here. 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. 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 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, as made clear above. The main body part 45 of the specification includes provisions for two types of entities, namely provisions 45A for global entities.
, or provision 45C 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 produced by Digital Equipment, Inc. of Maynard, Massachusetts.
Occurs on Net Phase TV. 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 the 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, a name field 47 identifies the entity as a global or subordinate entity and identifies the entity's class name. If the entity definition is for a subordinate entity, it is provided with an upper field 50 that identifies an upper entity in the hierarchy.
The identifier field 51 is later converted to the entity body portion 53.
It has a list of attribute names for the attributes specified in . Finally, symbol field 52 contains symbols used to generate special compiler constant files with consistent names for use by entity developers.

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

This gives management module developers 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 system's ellipses. This eliminates the overhead caused by iteratively adding and removing dynamic steps.
The pool value of the DYNAMIC field is
Indicates whether the nature of the class is dynamic. If TRUE, the stage of the entity class is not stored in the ellipse. If FALSE, the stage of the entity class is stored in the structure.

As noted above, the entity provision 46 for the entity includes a body portion 53. Main body part 5
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 specification lister 4, a set specification lister 5, a command specification lister 6, and an entity class containing dependent entities. It is equipped with subordinate ente, iti restructuring 7. If the body portion 53 includes a dependent entity lister 7, each item in the dependent entity list 57 is rsUBORD INATE,
Entity definition 4 with a name field 47 containing
6 (Figure 3A) to #I commandment.

As mentioned above, the entity body is the attribute partition restorer 4
and an attribute set restructuring 5.

At this point it is useful to explain the distinction between these lists. Each list takes a complete combination of an entity's attributes and combines each attribute into one or more groups. The groupings indicated by the partition list 45 are independent of those indicated by the set list, each list being an independent precision of an entity's attributes. The partition listr 4 identifies all attributes of the same shape and groups them. do. For example, the attribute PART I T I ON may comprise all counters or all state attributes (flubs). ``Partition'' is used to indicate that the group implied 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. Set restructuring 5 identifies and groups all attributes that have the same function. For example, an access module for the Node4 global entity class may define an attribute set that reads rsQUARE. The SQUARE attribute set is a node 4 class.
It may include all attributes related to the current performance of the entity, such as attributes in the form of counters indicating the number of bytes sent and attributes in the form of characteristics indicating pipeline allocation. In this example, the user would thus be able to select SHOl4 NODE <instance> ALL
Commands like SQUARE allow us to view these statistics together.

The term "set" is used to indicate that a set contains attributes that have similar functions, but does 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. It has a type field 56.
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 distance and a maximum polling distance, respectively, for the attribute. As noted above, the historical data recorder functional module 11 may periodically obtain state 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 state and condition information. In addition, the attribute specification includes one or more attribute fields 62, each with an attribute name 63. This field contains the code by which the attribute can be accessed, and the associated attribute book #64. As shown above, all the specifications for attributes that are members of a partition are one partition specification 54.
It's inside. Independent aspects of an attribute are indicated by one or more attribute body definitions 64. FIG. 3B further describes the information contained in the attribute body 64 of the attribute field of the attribute partition definition 55.

The attribute body 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. ．． 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.6 Attribute body 6
4 further includes a category field 71 that identifies one or more categories with which attributes can be combined.
It is equipped with If the complex system is a distributed digital data processing system, the category is CONF IGUR.
ATION, FAULT, PERFORMANCE, S
including ECURITY or ACCOUNTING,
Categories defined in the 74-98-4 Oven Systems Interconnect (OSI) standard may include, but are not limited to. In addition, if the polling speed for a specific attribute specified by the attribute body 64 is different from the polling speed specified in fields 60 and 61 of the attribute partition specification 54, the attribute body 64 sets the polling speed in fields 72 and 73. Information can be prepared. Finally, the attribute body 64 may include a proprietary variable field 74 that identifies proprietary variables used by the management module in reaching and processing the attribute rWi.

In another real-life example, polling speed information can be omitted from the attribute specification altogether since the accuracy of this data is implementation specific. Additionally, in another embodiment, the attribute body 64 may include a UNIT field.
If the tJNIT field is provided, data in numeric format can have its specified units (
). Attributes can be grouped together to simplify the management of complex systems. The set definition portion 55 of entity book #53 identifies one or more sets that the entity has. The contents of the attribute specification portion 55 are specified in detail in FIG. 3B. The set specification portion 55 includes a set name field 75 for identifying a set, and an attribute list 81 for identifying attributes included in the set. The S case specification portion 55 may also comprise commands, ie requests, lists that can be processed by referring to sets.

Set definition portion 55 includes a symbolic field 77 similar to the symbolic field described above, a category field 80 which may include, but is not limited to, OSI category information, and a set identified by the collective name in field 75. A proprietary variable field 82 may be provided that identifies proprietary variables used in processing associated with the attribute being identified.

The entities process commands generated by the control device in response to requests and subordinate requests from the presentation module 10 and the functional module 11, respectively. Each command includes a command request that specifies the action to be taken, and can have responses and exceptions that define 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, which defines the structure of a response, and an exception definition field 92, which 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 acting 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 example, the effect field 84 is commanded to be EXAM.
I NE, MODFY format or ACTIO
DIRECT TYPE indicating whether it is of N format
You can replace it with a field. The EXAMINE directive operates only on attributes and does not modify them.

Examples are the SHOW command or the DI RECTORY command. The MODEFY command operates only on attributes and makes modifications. Examples are SET, ADD, or REMOvE
The ACTION command does not operate on attributes, but on the entity itself. For example, CREA
There are TE directives and TBST directives. A field 85 may be provided to indicate whether the command is accessible by the presentation module IO. 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 OSI categories may be defined, but are not limited to this.

The structure of the request specification field 90 of the command specification 56 is defined in FIG.
The request specification field 90 includes O or more arguments 91 defined in the name field 92, each containing an access code.
can be provided. Additionally, the argument may include a display field 93 indicating whether the argument should be displayed to the operator by the presentation module 10. The argument includes a field 94 that indicates whether the overletter 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 indicating the unit of can also be provided.
Additionally, the argument 91 may include a proprietary variable field 100 that identifies proprietary variables used in processing in conjunction with the argument.

The structure of response definition field 91 and exception definition field 92 is shown in Figure 3D. Referring to FIG. 5D, the response specification field 91 includes a response name field 101 which can include a code by which the response can be accessed. The egress field is the SUC when the response fulfills the request specified by the request field.
whether it indicates CESS or whether the response is INFORMAT
Identify whether it is IONAL or not. Text field 103 indicates a text string that presentation module 1o can display to the operator to indicate a response. @, the response specification field includes one or more argument fields 1, each comprising a name field 105, a unit field 106, and a symbol field 107.
04 can be provided.

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 specification field 92 is similar to that of the response specification field 91, which includes fields 111 to 117 similar to fields 101 to 107 of the response specification 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 action. Referring to FIG. 3E, the disbatch use includes a heading 200 that defines the beginning of the disbatch use and includes the table name, and a footer that indicates the end of the disbatch use.
It is equipped with 201. Between the heading 200 and the footer 201, the dispatch usage has one or more dispatch entries, each of which specifies 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 part 203 and the entry part 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 stage name in name fields 47 and 50 of entity specification 46 .

Similarly, the content of attribute portion 205 corresponds to the attribute identified by name field 62 of attribute specification 54 of entity book #53 of entity specification 46.

The dispatch entry 202 also includes the procedure pointer part 20
6, which is the dispatch entry 202
The access manager processes the directives in conjunction with the entities and attributes identified in portions 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, use of disbatch involves data evasion, specifically processing requests by the kernel 13.14 to the appropriate functional module 11 or access module 12. Dispatch table 28 used to forward for
It is used to format dispatch entry 134 (Figure 8B) in <Figure 5>. A request or dependent request essentially specifies verbs, entities, and attribute partitions, and the kernel dispatches the verbs, entities, and attribute partitions specified by the request to the data specified by portions 203, 204, and 205, respectively. Compare with the contents of Kozuzukuri's section. If each part of the verb matches the content of the corresponding part of the data ellipsis (Figure 8B),
Kernel 13.14 has dispatch entry 13 taken from section 206 of the dispatch specification (Figure 3E).
4. Begin the procedure specified in 4.

B. Data files and usage 1. Registering a data dictionary management module allows its management specification to specify new entity classes, subentity classes or attributes, global or subentity directives, or events. The management specifications (Figures 3A to 3D) are used to control 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 three-hierarchical database having the general organization 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 2l9 that lists attribute partitions, and a subordinate node 2l9 that lists attribute sets in the hierarchy Mi organization of entity book #53 of entity regulation 46 of management specifications. Dependent Node 222, Dependent Node 22 Listing Directives
3, and a subordinate node 2 that lists the subentities.
Refers to multiple subordinate nodes, including 24.

Each subordinate node 219 to 224 indicates each element defined in the entity body. That is, subordinate nodes 221 point to attribute definition nodes 225 each of which comprises definitions of the attributes defined in attribute definitions 54 of entity body 53, and attribute partition nodes 219 each of which comprises definitions of attributes defined in attribute definitions 54 of entity body 53. Zoning regulations 5
6, each of the aggregate nodes 222 refers to an attribute section node having the attribute specifications defined in 6.
The directive nodes 223 point to the set provision nodes 226 each having a set provision specified in the set provision 55 of the entity body 53, and the command provision nodes 227 each have a command provision specified in the command provision 56 of the entity body 53. , and each subentity node 224 has an entity body 53
subentity provision node 2 comprising the subentity provision specified in the subentity provision 57 of
Points to 28. Each command node 227 has a request node 230,
It refers to a response node 231 and an exception node 232, each of which in turn corresponds to the management specification request specification 90 and response specification 91.
, and request, response, and exception provisions taken from exception provision 92 (Figure 3C). Additionally, each subentity node 228 has a dependent node 2 for the attribute.
33, including a dependency node 234 for sets, a dependency node 235 for commands, a dependency node 237 for partitions, and a dependency node 236 for subentities;
It forms the root node of a suborganization with a structure similar to that depicted for the global entity shown in Figure 4. 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 processing requests by entities. Various nodes of the data book receive information from the elements of the management specification to form a complete database of data dictionaries. The information in the dispatch specification (Figure 3E) is used in the dispatch specification, as described below in conjunction with Figures 8B and 9.
Used to create table 28.

With this background, Figure 5 shows one presentation module 1.
0, fi function module 11, access module 1
2 and information manager 15.20 and dispatcher 1
Kernel 13,l4 with 6.21 is shown. Additionally, FIG. 5 shows various parts of data storage element 17.22. In particular, data storage element 1
7.22 comprises an ellipse and area database 23.25, an alarm database 24, a historical data file 26, a data dictionary 27, and a dispatch table 28.

2. Historical Data File The historical data file 28 is a representation 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 that identifies the time at which the status and condition information occurred. When the information manager 15.20 receives a request or dependent request regarding a state or condition at a particular time, the information manager determines that if the time indicated in the request or dependent request is in the past;
Check whether the information is present in file 26 and respond using the contents of the file.

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 dispatch table 28 include the entries in the distributed digital data processing system for the entry points of the routines forming each functional module 11 that is called in response to a request from the presentation module 10.
Identify location. In more detail, Disbatch
Table 28 contains invocation information that facilitates initiation of various operations by each functional module 11. Similarly, the contents of the dispatch table 28 are
The location of the entry point of the module 12 routine within the distributed digital data processing system is identified. This location is used to process dependent requests from functional modules 11, ie call information specifying various operations by the respective entities.

4. The user interface information control device further comprises two user interface information files containing information regarding the various functions provided by the functional module l1 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 the two user interface information files 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 entities of the complex system.

5. Configuration Database As explained above, the configuration 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 scrutiny 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, the configuration database The database can be used in conjunction with the presentation module to support wildcarding of user instructions. When the presentation module receives a user command containing a wildcard, the presentation module issues a request to the configuration function module, requesting an inventory of all entities in the structure that match the wildcard request. The Yokokai functional module then uses the information in the configuration database (along with the domain 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 SHOGA NODE IN DOHAIN SITE 1
(where S H O W is the command, DOMAIN is the ffll area entity class, SITEI is the area stage, NODE is the global entity class, and fire is the wildcard) is SIT
It is interpreted as an instruction indicating all stages of the node inside the region named EI.

In this way, the presentation module sends each request to S H O W
in the form N O D E <+nstance> (where <instance> is the name of the stage),
Expand into several requests, one corresponding to each stage of the NODE class of the area SITEI.

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 command issued. For example rNODE*oO
J is rNODE FOO” and rNODE MA
GOO, but not rNODE BAR. Partial wildcards cannot be used for identifiers with certain data types, such as text or numeric strings.

In the preferred embodiment, wildcard expansions are not allowed in user-directed global entity class fields. Global class specifications are not wildcarded. This is because then there would be insufficient control over the scope of the command. This can cause errors if directive names supported by one entity class are 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, the rDELETE*J command). In addition, global entity wildcards can contain more information than the user intended (for example, rsHOW large, command).
can easily occur. Note that wildcards are safely allowed in subentity classes.

Wildcard embodiments may also delegate some or all of the wildcard expansion duties to access modules. This is especially true when the Kaikai function module is not used. In the absence of a configuration function module, an access module (usually involved in accessing all modules of a class or subclass) stores stage data as part of its proprietary storage 32 (Figure 2B). be able to. In this case, the access module will use the stage data to expand the wildcard of the received request. If wildcards are not supported by a particular access module, an exception indicating this condition will be returned to the user. C. When data file management and registration management modules are added to the control device, or when new information related to the management of entities becomes available, the control device must adapt.

The controller is data driven and the associated data files must be modified to adapt the system to new modules or information. This process is commonly known as data file management. The specific procedure for adapting a control device to a new module is known as registration. 1. Management of Historical Data Files In one particular implementation, the contents of historical data file 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. For the first time, 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 uses the historical data recorder functional module. allows the entity to respond to the 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 subordinate 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 to indicate the last value in the response. 2. Dispatch Table The contents of the dispatch table 28 and of 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 loads 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. 3. The user interface information presentation module 10 uses the display information of the user interface information file 29 to initially display the entries,
Decide whether or not to display attributes, commands, etc. Second, decide what to display. 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 you do not need to own the interface code. All user interface support equipment is provided for these modules, and the module designer
There is no need to worry about the interface. This 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 defines a scrutiny table, which is used by dispatcher 16 to direct 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 virtually 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.

In addition, the user interface information file 29 may store information already available in a more convenient format from external databases and data dictionaries.

For example, the 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 subordinate to entity classes 220. Although this format is logical for representing entity class information, it is not very useful for scrutiny tables. User requests typically first include commands (e.g., rsHoW NODB FOOJ rsH
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 the stage name (e.g. rNODEFool
This is necessary because the instruction will be scrutinized if it is mixed with the identifier FOO). Therefore, after listing the available commands, the scrutiny table should list the class names that support these commands, and then the data types of the stages for these classes. Class and data type information is available by reorganizing the data dictionary, but for wildcard expansion, stage data can be obtained from the Kaikai 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, with this kind of interface, the user can specify a particular entity or area of the entity for further operations and the OS for the commands to be performed.
I category (Category field 87 of Directive provisions)
You may want to set the context for your command by graphically selecting the commands (listed in ). A menu can then be generated 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 be done. EXAMINE format or CATEG
For ORY-style commands, a separate menu can prompt the user to select an attribute pane or set. To implement this type of interface, the list of all regions and entity stages and the list of all stages within a region must be retrieved from the configuration database. Additionally, a morphological database can store commands supported by classes or domains. The user interface information file can also store default value information. Default values for a stage or class may be provided by the user or by administrative specifications for the associated entity class. This allows users to save typing time by specifying default values within the command. For example, users may be most interested in NODE FOO.
NODE Fool can be specified as the default node. Later, the user can use rsHOWROUT
You can type a command like ING, which is rsHOW NODE FOOROUTI NG,
It will be interpreted as A similar use of default values is available for graphical environments. Other examples of user interface information are online supplementary files available to the user through the presentation module. Auxiliary files contain auxiliary information for making use of 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 portions associated with the maximum polling speed field and the default polling speed field, to the attribute specification 54. Polling can be initiated and controlled in relation to various attributes of defined entities, and responses thereto are stored by the historical data recorder function module 11 in its historical data file 26. 5. Module Registration Referring to FIG. load display information into the user interface information file 29, including information from that portion of the data dictionary that pertains to the display field 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 in the dispatch specifications (Figure 3).
(Figure E) to the dispatch table 28. D. Communication between modules and nodes 1. In one specific embodiment of the control function module, an operator can access
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 user interface information file examines the instruction using two examination tables to obtain codes corresponding to the codes for requests, entities, and attributes of the access module 12 specified in the management specification, and presents this as a request. Transmit R capability to channel 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. Intermode Communication When the controller controls a complex system consisting of a distributed digital data processing system, FIG. and associated data files 23, 24, 25, 26, 27, functional module 11 and access module 12, dispatcher table 28, user interface information file 29; is contained in a single process on a single node of a distributed digital data processing system. Distributed digital data processing system presents module 10, functional module 11
and an access module 12. If provided in different processes or nodes, the controller includes dispatchers 16, 21 in all processes and nodes. Referring to FIG. 6, the dispatcher 16(1) of one process of one node presents a request to the functional module 11(2) of a second process or node to the dispatcher 10(1). If the functional module 11(2) is in another process of the same node, the dispatcher 16(1) dispatches the request to the process of the other node or to the Dispatcher 16 (2). The dispatcher 16(2) then selects the functional module 11(2) to process the request. Dispatcher 16 (2
) receives the response generated by the functional module 11 (2) and transmits it to the dispatcher 16 ( 1 ) via the inter-process communication mechanism or the inter-note communication mechanism, and the dispatcher 16 ( 1 ) sends the response to the presentation module 10 .
(1) allows the response to be displayed to the operator. Similarly, the dispatcher 21(2)
1 ( 2 ) to be processed by the access module 12 ( 3 ) of another process or node, the dependent request is sent to the dispatcher of the other process or node through the inter-process communication mechanism or the inter-node communication mechanism, respectively. 21 (3). The dispatcher 21 (3) then accesses the dependent request.
It is transmitted to module 12 (3) for processing.
The dispatcher 21(3) receives the response from the access module 12(3) and transmits it to the dispatcher 21 via an interprocess communication mechanism or an internode communication mechanism.
(2) and dispatcher 21 (2).
) couples it to functional module 11(2).

3. The structure of an elliptical request and dependent requests, particularly the parameters included with the request, is shown in FIG. 7A. The structure and contents of dispatch table 24, which is the same as the structure and contents of dispatch table 26, will be described in connection with FIGS. 7A and 7B. The information manager 15.20 and the dispatcher 16. 2
The process performed by 1 will be described in conjunction with Figure 9. Referring to FIG. 7A, information may be generated by presentation module 10 in response to actions by an operator associated with the contents of user interface information file 27.

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.

The requests all have the same 'JrI4 structure, with an initial call identifier, not shown, followed by the parameters shown in Figure 7A. Kernel 1 as explained above
3, 14 is a single dispatcher 16.3 having a presentation and function aspect 16 and a function access aspect 21. It is equipped with 21.

The initial invocation identifier determines which of these aspects are enabled by each request. The initial call identifier can indicate a call to a functional module or an access module, each directed to a corresponding aspect of the dispatcher. Although a presentation module or function module can call a function module and a function module or access module can call an access module, a presentation module can
The access module can only be called through the control function module.

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.
It is equipped with 0. As noted above, a request initiates a change in the state or condition of an entity of a complex system controlled by the functionality module 11 or the access module 12, and provides information regarding the state or condition of such entity, or both. You can start sending back the items.

The content of the verb field 120 is the function module 11'i
12 illustrates operations performed by access module 12;

Additionally, the request includes an input entity specification field 121, which identifies the entity of the complex being controlled. If the verb is a non-action verb, e.g. 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, if the verb causes a change in a given entity, then the request does not have an attribute pointer field 122. In addition, the request includes a pointer to a time data W4 structure that contains certain timing information, including absolute system time, time interval specifications, and time accuracy specifications, and specifications for that time range in the request for schedule creation 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 a multi-part operation, each part of which requires a separate request. Output entity specifier field 126 points to a data buffer that can be used by dispatcher 15 (or dispatcher 21 if the parameter forms part of a dependent request) in connection with the identification of the entity. It has a pointer.

The request also contains a pointer to the item stamp specification that is to be used by the functional module 11 (or access module 12 in the case of dependent requests) in connection with the shaping of 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. What about each descriptor? A pointer to the starting position of the 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.
It can also have a qualifier field. The WITH qualifier can be associated with an entity field that filters the entity list created by wildcards, for example. For example, rBR
IDG"WITH STATUS='ON AND
FILTER. ING-'OFF, refers to each bridge class entity with its status flag set to ON and its filtering flag set to OFF (this
It also illustrates the use of pool functions such as ND, OR, NOT, and qualified XOR). In the preferred embodiment, all modules and information managers implement the WITH qualifier by specifying the presence or absence of a WITH clause at each level of entity parameters (i.e., global entity, sub-entity, sub-sub entity). Other qualifiers can be used as explicit parameters of the request. For example, the communication qualifier may be configured to check that the response of the request is <f
Send to a file named i 1 e name>
rFROM <fi1 e na to search for the ``To<fi I e name>'' qualifier and other request parameters from the file named <fi I e name>
me>” qualifier, rVIAPATHJ specifying a series of “hops” along a path through the hierarchy of management modules.
qualifiers (e.g., useful in specifying a fine management module between several devices performing an operation), and rVIA PORTJ qualifiers (e.g.,
(useful for specifying that the access module performs diagnostic tests using a particular Ethernet boat). Similarly explicit parameter qualifiers can specify groups of entities.

rlN 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
The PASSWORDJ and rBYUsERJ qualifiers are examples of specifying the customer's name, password, or requester's user identifier for these purposes.

In addition to the above, qualifiers specify the time at which a command should 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” <t im
e-arg>[”,”<time-arg>]. Here, the time argument <time-arg> is, for example, the start time (r START=<time>).
〉, end time (rEND=<time>''), or connection time (rDURATION=<time-1
length>”), repetition period (rREPERT
EVERY [=] <t i me − 1 e n
gth〉”), time accuracy (rcONF IDEN
CE [=]<time-1ength>]i, or sampling rate (rsAMPLE RATE[
=ko<time-1ength>ノ) can be shown. These arguments interact with each other to create a general range of requirements and areas of interest. In particular, in one particular embodiment, three time arguments, START,
END and DURATION are related so that two of them define a period. Therefore, at least two of these qualifier arguments must be specified when displaying period-standardized entity statistics. Other time qualifiers can also be used. For example, ^T
The time qualifier in OIt BEFORE <til1e> can be interpreted as requesting time-slumped information at or before the time indicated by <tiIIe). Upon receiving such a qualified request, the argument module continually checks for actions that 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 the information until time <tiIle>. Once the information is generated, it is returned to the requester. Otherwise, the time <time>
Then, the management module forces the ball of information from the access module or entity and returns the information to the requester.

To complement the AT OR BEFORE tine qualifier, a No one time qualifier can also be implemented. In addition, field 124 contains a handling pointer to a context data ellipse, which is a dedicated section of storage that stores processing context information. The handle is used, for example, as a "notepad" for communicating contextual information between the module and the information manager.

1. time stamp Each item of data has a time a tan1 value.

For data returned to the user or management module,
A timestamp indicates the instant at which the event described by the data item occurred, the instant applied to the data value returned for a command, and the instant 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.

2. Range of Interest A time range specification of interest is provided on request using the time specifier field 123. Using a time specifier,
Other values of data than the ``currently owned 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. Generally, time specifiers are used with SHO commands, but time context can also be applied to HODIFY style requests and actions.

The time ranges of interest are absolute instants, sequences of absolute instants, time intervals (start time rsTART J and duration rDU
RJ), 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.
) can be related to them. If a period is specified, the original moment, sequence of moments, or time interval is treated as a base and the period is added to this pace. For example, time specification r5:oOEVEREY O:1
5, Ha, 5:00, 5:15, 5:30, 5:45
It is equivalent to... absolute time instant ( rUNTIL
J) can be specified to indicate when the iteration is to be terminated. For example, time specification r 5: EVER
EY 015UNTIL6:OOJ is 5:00, 5:1
Equivalent to 5, 5:30, 5:45, 6+00. You can specify the repetition time interval in the same way.
rsTART5:00 DUR:05 EVERY1:
OOJ is the time interval 5:00-5.05, 6:00-6
:05, 7:00 -7:05... is equivalent.

3. Scheduling Scheduling information may also be indicated by the time specifier field 123. A particular scheduling time can be expressed as either an absolute instant or a series of absolute times. Unlike the range of interest, the scheduling time cannot include time intervals. A time interval whose start and end points are equal is an "instant" (for example, (TO
[lAY,TOI)AY) ) ). There are some rules that apply to time intervals. The past time interval can have a starting point indicated by the keyword YESTERDAY, or by an absolute time in the past. Similarly, the future time interval is the keyword TOl40RROl4
, or 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′! M
As explained above, scheduling and scoping of information of interest can be supplemented by associated contextual requests. Handlings are created by modules that execute requests and are subsequently used to communicate with service providers. Upon receiving a call from a service provider, eg, an information manager, a context proc is generated as a local reference to the request time context.

In general, context blocks and treatments are used as criteria for the state of a request. Since an initial request can generate multiple dependent requests, it is possible to create multiple handling and context blocks with a single request. Context blocks are the criteria used by service providers, whereas handling is the criteria used by service requesters. Each process in the request/dependent request chain (i.e.
A module or information manager only knows about the context blocks and treatments associated with its local part of the chain. Referring to FIG. 7B, in one particular embodiment, the temporal context treatment 172 created by the requester, e.g., presentation module 10, includes #J
A range field 175 and a schedule field 176 are provided. 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, which indicate the state and criteria functions of the treatment, 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.
Functional modules and access modules can also create and maintain context blocks on demand). The handling status field 178 has one of three values: rFIRsT,, rHORE”,
or r CANCEL J, these are used as flags to indicate further actions to take. When first created, the handling state is set to rFIRsT J.

As explained above, if a request can be satisfied with a single response, a response is generated and returned to the requester. In more general cases, a service provider, eg 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. Although each reply can only incorporate information from a single entity, several replies are required, one for each entity.

In other cases, a request 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 that require multiple responses include obtaining attribute data about an entity or entities, modifying attributes of some entities, and modifying the state of some entities.
It can be for any form of action, including If a service provider processes a request and finds that the request has an alternative 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.

The 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; and (2) cause the requester treatment 172's status field 178 to
Use the appropriate handling modification routine to signal that you have another reply by setting rHOREJ to the value of rHOREJ. When the reply is returned to the requester, the requester returns r HORE. in its handling status field. Look at the status and see that the service provider has another reply for this request.

If the requester does not want these alternative replies, they must cancel the request (see below). If the requester wants a different reply, he must repeat the request without changing the parameters. These repeat requests (this is rHORE,
(with a handling status field 178 equal to ), the appropriate handling access routine is used to locate and detect the rlQREJ status.

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

The service provider provides the requester with a subsequent reply (e.g.
(determined by scope field 175 and schedule field 176 in the requestor's treatment).
Requester handling status field 178 har FIRS
The value of T J (initial setting!r!g) is reset and returned. When the return is sent to the requester with this final reply,
The requestor sees its handling parameter status set in rFIRsT J and knows that its request is fully satisfied. If the request is satisfied with a single reply, the service proposer does not preserve the context and sends rHORE. Note that the condition of a handling parameter that becomes a condition never occurs. The requester is handled according to its initial setting rFI.
It remains in state RsT J, indicating to the requester that the request is complete.

Once the service provider returns the handling parameters in the rHORE, state, the request must be repeated or canceled. If the request were to be discarded instead, system resources would be lost due to storage allocated to handling and context blocks.

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, two or more separate treatments may be used, one for the initial requester generated by the calling requester, and one for the initial requester 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 123
The schedule of time is controlled by the precepts. For each schedule time specified by the time specification, 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 set aside for the initial request. If there is more time to schedule the requested action, the information manager does not set the requester's handling status to rFIRsTJ and rMO
RE, leave in state. The requester sees that its handling parameters are still in the rHOREJ state, knows that the entire request is not complete, and asks about the rest. Next, the information manager waits until a predetermined schedule time,
Have the dispatcher make another call to the service provider. The service provider will send this next call to the rFIRs
Note that it does not retain any context after returning its handling state set to T, so it cannot be distinguished from invoking a completely new request. Also, the requester does not distinguish between the handling status of rHORE, generated by the service provider waiting for more replies to the request, and the information manager preparing a new schedule moment.

In another embodiment, the handling access routine is enhanced to allow the requester to confirm the occurrence of the handling parameter r l{ORE, condition.

During a request with multiple replies or multiple schedules, if the requester decides that he does not want any further replies to this request from the service provider, he must cancel the request. Possible reasons for attempting to cancel a request include receiving an exception reply indicating that no more data is available, or receiving an error condition indicating that the desired action was not performed correctly. The reason for cancellation is the responsibility of the requester. Cancellation terminates all activity of the request, including the scheduling and scope of the operation.

Cancellation can be performed when the service provider returns the handling parameter status of rMOREJ to the requester. The requester sends the handling parameter status rCAN CEL,
, and reissue the call using an appropriate handling modification routine.

The requester must not change any other parameters to this call. When the service provider receives this call, rCAN instead of the expected rMOREJ state
Look at the handling parameters in the state of CEL. The service provider receives the context from the handling parameters and uses the context to perform the necessary purification. This cleansing includes 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 rF IRSTJ.
Reinitialize and restore the state. Then the service provider
A special condition value return code of CANCELED is returned to indicate that the request was successfully canceled. The requester receives the service provider's rF IRST. You cannot cancel the request while returning the handling parameter status. The request has already been completed and there is no context for the service provider to cancel. Therefore, the cancellation routine described above will not return an error unless the handling state is rMORB. F. 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 figure. The dispatch tree and dispatch list essentially epitomize the scrutiny tables used in examining 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 tree structures to aid in scrutiny, but they can be organized into other data structures. Entity nodes identify various entities within a complex system that can have requests associated with them. Entity nodes 130 have respective dispatch nodes.
It has a pointer pointing to the dispatch entry 134 (FIG. 8B) of the dispatch list held in the 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, the data ellipse 130 satisfies the entity model because it has a hierarchical structure and its child structures that resemble it.
The term "entity node" used to describe data organization 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 pertains to an entity class or a 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 specification 46 (Figure 3A), and the
Table 24 includes further entity nodes 130 relating to classes and stages, as described below in connection with FIG.

While reviewing a request, the entity's class name and stage name and its attributes are verified using a data structure of the form shown in Figure 8A; Used separately. 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 in 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 is related to a levelless class, an example of which is described below in connection with Figure 9, field 143 points to another entity note that is removed from the tree link entry. It has a null pointer. Finally, field 131 contains the code
An entry is provided that contains 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 encoding list. (The remainder of the list is not shown.) When referring to the class or name of an entity's stage, the encoded list refers to the entity's 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 name 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 a class code or stage name. The contents of field 151 comprises a class code if the class/stage flub field 140 of entity node 130 is adjusted to identify the entity node associated with the class.

Instead, the class/stage flag field 1 of
40 comprises a stage name if adapted 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, the 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 for processing requests within the complex. 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 string of attributes identified by the attribute defined by the attribute definition field 54 in 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 is used. With this background in mind, the process carried out by the dispatcher 16 when examining and dispatching a request from the presentation module IO will be described in conjunction with FIG. dispatcher 2
It will be seen that 1 performs a similar process in conjunction with dependent requests from functional module 11. Referring to FIG. 9, the request 180 is as follows. SHOW NODE (node nane > ROUTI
NG CI RC U I T (routing ci
cut name )CHARACTERIST
ICS This is used in conjunction with distributed digital data processing systems. The request 180 includes a verb section 181, namely S H O W, an entity section consisting of a plurality of entity class codes and stage names 182 to 186, and an attribute section 187 from a plurality of attributes.
It has many compartments. In this example, the verb SHOW 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, has a large number of class/stage pairs. In particular, element 182, NODE, is the class code, and element 183, i.e., (node
) identifies a stage in entity class NODB by the stage name (node nane >). identifies a node in a distributed digital data processing system.
nane > identifies a node in a distributed digital data processing system. Additionally, the request 180 further includes an entity class code 184, ROUTING, that has no stage in the entity partition. Request 180 to another entity class code, CI
RCUIT, which is (ROUTING
It has stages identified by CIRCUIT NAME >. Referring to Figures 3A to 3D depicting management specifications, various elements of requirements related to entities 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 name and subentity class names 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. Entity and subentity stage names 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 (190) begins 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 a class of NODE. -Class code field 15 with code
Find an entry in that coded list 131 that contains a coded entry with a 1. dispatcher 1
6 cannot find such an entry in the dispatch table 28, the dispatcher 16 looks for a wildcard or ellipsis pointer (see below). (Reply with an error to the received module 10.) 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), where it , the stage specified by the entity element 183 (nod
Entity node 1 associated with e narme )
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 coded entries corresponding to (node naIle >
If you can't find 8, look for a wildcard or ellipsis pointer {see below}. On the other hand, the dispatcher 16, in step 191,
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, dispatcher 16 causes coded entry 1
31 field 152 and the entity element ROUTING from the request.
A class/stage flag 140 comprising a coded entry 131 identifying the entity node associated with the code and whose coded entry list comprises a class code field 151 with ROtJTING. Locate entity node 130. In this situation, the entity class ROU
Since T 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 is
Points to a second entity node 130 associated with the entity CIRCtJIT. At step 192, dispatcher 16 locates entity node 1 associated with the ROUTING class entity located at step 192.
The second entity node 130 and its class code use a null pointer of 30 to indicate that its class/stage flag 140 is associated with the class code.
Locate the coded list comprising the coded entry 131 whose code field 151 comprises CIRCUIT (step 193). If the dispatcher cannot locate such an entity note, it looks for a wildcard 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 (ROUTING CIR
CUIT NAME>. With this action, dispatcher 16 causes field 15 of coded entry 131 to
Using the Boin Yu of 2, its class/stage flag 14
0 identifies this as being associated with a stage name and its coded list indicates that its stage name field 151 is requested 180
(ROUTING
CIRCUIT NAME> is located. dispatcher 16
If cannot locate such an entry, look for a wildcard or ellipsis pointer (see below).

On the other hand, if the dispatcher 16 locates the stage entity node 130 that identifies the stage entity element 186 in step 194, the 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, the verb in verb element 181, and the attributes in request characteristics element 187 to identify the dispatch name to be used in processing the request. Identify entry 134 (Figure 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.

Dispatcher 16 then sends its verb field 1
65 corresponds to the verb summary 181 of the request 180, in this case SHOW, and its attribute field 16
An attempt is made to locate the dispatch entry 134 whose content corresponds to the attribute of the 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 other processes or nodes than those associated with the dispatcher, then the dispatcher will accept the request for processing. Transfer to the dispatcher of the pond 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. For example, one management module may handle all requests for modules of a particular global or subordinate entity class. Without the wildcard and ellipsis pointers, all class stages and subclass stages would be listed in the dispatch table. To avoid this, wildcards and ellipses are provided that can be specified in the Disbatch Specification 39A to indicate in a general way which entity classes or stages service the management module.

An example of such a dispatch specification is NODDE ROUTING CIRCUIT, which specifies that a module is a global node of the NODE class.
In all cases of an entity, all cases of a subentity class CIRCUIT indicate that it can also handle all subentities of other CIRCUIT class subentities. The asterisk (*) matches any stage name, and the ellipsis (
) matches all subentity stages or subentity class/stage pairs that may follow. For example, the expression NODE foo ROUTING CIRCU
IT bar LINK fred conforms to the dispatch specification. This is because "5" matches "rfoo" and r. ．． ．． , is rbar LTNK fr
This is because edJiM matches.

Referring to FIG. 9B, to enter the wildcard dispatch specification for dispatch table 28, step 19
1 (FIG. 9A), which corresponds to the stage name of the NODE class entity. Wildcard pointer 141 points to the class whose -2 is the class code ROUTTNG.
It is changed to point to the new entity node 130 containing the code (step 196). class code R
The child pointer related to OUT'T'lNG becomes null {
Similar to step 192 (FIG. 9A)}, the null pointer is
Points to another new engineering/eye node 130 which 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 looks for a stage in the NODE class with the name, eg, "rfoO." If this name is found in a coded entry (three shown for illustration purposes), the dispatcher follows the coded entry's child pointer.

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 locating the wildcard pointer,
The dispatcher proceeds to step 196.

Steps 196 and 197 are the same as steps 192 and 193 in FIG. 9A. The dispatcher returns a null value (corresponding to class code rROLJTINGJ) in step 196.
Use the pointer to move to step 197 and select the class code rC I R. Move to step 198 using the child pointer corresponding to CU I TJ. In step 198, the dispatcher searches the linked list of encoded entries (three shown for illustration purposes) and
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 is located and used to traverse to 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 encoding entries in the dispatch table have been checked. In this way, the dispatcher looks for the "best match" for the entity name. Therefore, for example, the first module is the dispatch specification NODB ROUTING CIRC.
LJIT can be provided. This means that the module is N
ODE class global entity stage 'jo
e', it indicates that all stages of all CIRCUIT class subentities of the ROUTING class subentity can be handled. The second module is the dispatch specification NODE joe ROUTING CI
RCUIT... can be provided. This indicates that the module can handle all stages of all CIRCUIT class sub-entities of the ROUTING class sub-entity for the stage "jOe" of the NoDE class global entity.

In order to be consistent with the "clearest match" rule, NO
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 is rjoe.”
appears in the encoded entry in step 191, so “jO
If eJ is the stage name in the request for ROUTING CIRCUIT, then the rjoe,1 coded entry will be used (because it is checked first) and the wildcard pointer will not be used. be.

To properly probe the dispatch tree, DispatchX must also use the stack. Let me explain why this is necessary with a simple example. Consider a new module with a dispatch specification NODE jim DISKDRIVE... This shows that the module can handle all the stages of the sub-entities of the DISDRIVE class as opposed to the stages of the global entities of the NODE class. This specification is entered into the tree in step 191 in a manner similar to FIG. 9B by appending the stage name "rj im" to the encoding entry, followed by appending the new entity code. Following this, dispatching a request using the global entity class and stage name NODE Jim causes the dispatcher to transition to the new entity node. However, NODE Jim ROUTING CI
Requests with entity names that begin with RCUIT will require a new module to be DISKDRI for the NUDE stage rj im'.
Since it only supports subentities of the VE class, it cannot receive services from new modules.

Therefore, the dispatcher uses the class name ROUTING
Once you have determined that CIRCUIT is not supported by the new module, return to step 191 and optionally use other encoding entries or wildcards or ellipsis pointers to create rNODB Jim ROUTIN.
A mechanism must be provided to find a module to service a GCIRCUITJ request. Therefore, as the dispatcher traverses the dispatcher table, the dispatcher maintains a stack of pointers for all of the entity nodes 130 that it has traversed from the root node. As the pointer moves up and down through the tree structure of the dispatch table, it is pushed in and out of this stack in an attempt to locate the appropriate dispatch entry.

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

As explained above, the control function module can serve as a pass-through from the presentation module directly to the access module. To achieve such pass-through, the presentation of a dispatch table (which matches the name of any entity in any request), the ellipsis pointer to the root node of the functional aspect, is used to create a dispatch table for the controlling functional module. It should point to the entry. Upon receiving a request, 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 Disbatch Table are communicated to the Functional and Access Dispatch Table for conformance. 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 with no stages. It can contain the first element. 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 Configuration As mentioned above, configuration function module 11 maintains a configuration database that defines the entities that make up the complex system. Upon appropriate commands from the operator, the configuration function module 11 may add stages of entities defined by the data dictionary to the configuration database, delete them from the configuration database, and modify provisions within the configuration database. . As mentioned above, the region functionality module l1 establishes region entities in the configuration database that refer to a subset of entities already defined in the configuration database. Through the presentation module lo, the operator is able to control and monitor an entity consisting of a particular area without regard to the possibly 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 region functionality module establishes a region database for each region entity that identifies the entities that make up the region entity within or in addition to the configuration database. Upon receiving the appropriate request, domain functional module 11 adds the entity to the domain database;
This adds entities to the region, deletes entities from the region database, generates responses that identify the entities that constitute the region defined in the region database, and deletes entities from the region database. , thereby effectively removing the area.

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 the configuration, and similarly for each entity stage within a region, is shown 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 name for 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 region database is reduced. In embodiment a, 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 structure database includes entries 234 for each entity and sub-entity, 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 configurations to display (via the presentation module) to the user, for example, a map of configurations or a menu of entity stage names.

H. As explained above in conjunction with FIG. 1, one functional module 11 includes an alarm functional module 1l;
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:
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 requests from presentation module 10, generates rules, which are stored in alert rule base 203, as described below in connection with FIG. 10B. 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. The conditions are corrected. Similarly, the act of detecting an alarm condition is performed by the detector module 201, which includes, for example, the condition information located in the historical data file (FIG. 5) and the alarm rules located in the alarm rule base 203. use. As discussed below in connection with Figure 10B, each rule includes a condition portion that identifies the condition. Detector module 201 detects an alarm condition by, for example, determining whether the contents of the historical data file comply with the conditions of various rules. If so, the detector module 201 generates an alarm indication, which is forwarded by the general alarm module 200 via the notification module 204 to, for example, the presentation module 10 for display to the operator. The general form of alarm rules generated by rule maintenance module 202 is shown in FIG. 10B. Referring to FIG. 10B, the alarm rule includes a condition portion 210, which indicates a set of conditions necessary to indicate an alarm. 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) logically evaluates to FALSE l). When the white of the expression part 212 evaluates to logical TRUE or logical FALSE, the relational operator 213 and the condition part 21
It can be seen that the numerical value part 214 of 0 is unnecessary. In either case, the condition part is a logical TRU
If it is rated E, there is a warning row.

The rule has an entity and attribute portion 212 and a time value portion 216. The relop value portion 213 associates the value of one attribute with one numerical value portion 214.
A time value portion 216 establishes a time function and a condition portion 210
can indicate the time or time interval that the alarm detector module 201 should use.

The provision of the alarm function module 11 allows the operator to establish alarm conditions dynamically and as needed.
Because the V-report conditions need not be predetermined within the controller, the controller can be used to control and monitor a wide variety of complex systems. For example, when the controller is used to control and monitor a distributed digital data processing system that may have a diverse configuration of nodes communicating through a network, alarm conditions may be based on a particular configuration. can be established by the operator. In addition, if a new alarm condition is discovered during operation of the complex system, the alarm condition can be added by adding the rule to the alarm rule base 203. A system that controls and manages a group of entities. In this system, an entity interfaces with a population to control primary information processing functions, and an entity further interfaces with the system to enable it to perform management functions. Such a system includes a storage management module that performs management 1a functions by independently translating and executing predetermined management-related commands, and the kernel translates the commands and assigns them to each module to be executed. Containing a table of dispatch pointers to which instructions are directed, 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 administrative 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.

Control and manage a group of entities 1111
1m will be described separately. This system is equipped with a storage management module that independently translates and executes predetermined management-related commands, and the kernel translates and executes commands for each module. The register is used to register new management modules with the system by adding another pointer to the table.

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-testing mode of the entity. The storage management specification information lists the attributes associated with 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 also 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 fields that specify a default rate and a maximum polling rate at which attribute values should be requested from an entity. Further describing the system, in which the management specification information may include partition information in predetermined fields of a common document, the partition information represents a group of attributes having a common data format. The management specification information may include set information in a predetermined field of the common syntax, where the set information represents a group of attributes having related functions under the control of an entity. The management specification information can include command information in a predetermined field of a common syntax, and the command information lists the management functions that the entity is supposed to perform, the structure of the command to be issued to the entity, and the structure of the reply to be received. are doing. The request form to be issued may also include a field that lists the 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 'JT4 structure of the reply to be received may include a field used to indicate an error condition that will 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 is DECnet
The protocol conforms to the PhaSe■ standard, or the protocol conforms to the DECnet PhaseV standard. Another alternative is described in which each instruction has a field listing at least one related entity and operation. The kernel has a dispatcher that receives and passes instructions based at least on the entities and operations listed therein. dispatch·
The table of pointers can be provided with an instruction graph of continuous data JtIJ structure with graphs corresponding to fields of data and instructions. The dispatcher is equipped with 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 that can correspond to any value of a particular field of the instruction, and a continuous data tree, or the instruction graph can correspond to any number of values of a field of the instruction. can have an ellipsis flag, and a continuous data structure,
Alternatively, the refiner may include a best match unit that determines the most accurate match to the field of the instruction by first looking for an exact match to the field and then an exact wildcard match to the field.

An alternative to such systems is to include a scrutinizer with a best match unit that determines the most accurate match to the field of the instruction by first looking for an exact match to the field and then an ellipsis match to the field. ing. 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. It is equipped with the best fitting unit to determine. 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 convey information to a presentation device, the presentation module including translation code that converts information received from an entity into a predetermined format for the presentation device, and a transfer code that conveys instructions from the presentation device to the dispatcher. There is. The presentation module may include user interface information that defines the mode in which the user interacts with the system. User interface information may include assistance information that provides information to the user regarding how to use the system. The user interface information may include graphics mode information that defines the contents of pop-up menus and command line scrutiny tables.6 The kernel may also include a class database that defines the different management information available from each entity. can. 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 performs management functions for members of a computer network, in which members interface within the network to control major information processing functions, and members further interface with the system. to perform management functions. Such systems include a storage management module that performs management functions by independently translating and executing predetermined management-related commands, a dispatch module that translates the commands, and directs commands to the respective modules to be executed. It has a kernel that stores a table of pointers and a register that is used to register new management modules with the system by adding another pointer to the table. The register is designed to register a new management module 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, with each record containing an associated time indication. The instruction specifies a time range and
The information manager satisfies the instructions by retrieving administrative information contained in records, if possible, and otherwise accessing information relating to a specified time range from members of the network. has the means to satisfy the command. Another alternative to such systems is a rule generator that generates and stores the rules, in which at least one module stores rules that identify predetermined alarm conditions, and a rule generator that generates and stores the rules and that determines the alarm conditions depending on the content of the rules. Equipped with an alarm condition detector to detect. The first category of management modules comprises functional modules adapted to perform functional operations on 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 uses the primary information processing capabilities of the members of the network to receive instructions from the user and convey information to the user. The storage device further includes region specification information that defines groups of members of the network. The kernel can cause commands to be issued to all members of a 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. A scheduler is used to possibly enable a series of dependent accesses or searches in response to instructions, possibly multiple times, according to a time schedule.

Describes a process that exerts control and performs management functions over a population of entities, in which an entity interfaces with the population to control primary information processing capabilities, and in which the entity also performs management functions. It can be so. The steps of the process are: providing a management module that performs management functions by independently translating and executing predetermined management-related instructions; dispatching instructions to the respective modules that are to translate and execute the instructions; - 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 for a group of entities, management-related instructions are independently translated and executed. We describe a management module that is adapted to be stored to perform functions in which entities interface within the population to control primary information processing functions, and in which entities also interface with other systems. Capable of performing management functions, the system includes a plurality of management modules and a kernel with a table of dispatch pointers that translates and directs instructions to the respective modules to be executed. Dispatch pointers, which point to modules and are associated with instructions translated and executed by the module, are also discussed.

[Brief Description of the Drawings] Figure IA shows a control device according to the present invention. This is a functional block diagram of the equipment. FIG. IB is a block diagram of information stored in the storage elements of FIG. IA. FIG. 2A is a functional block diagram of a part of the control device 61 shown in FIG. IA, 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 constitute the control device shown in FIG. 3A, and FIG. Defines dispatch specifications for modules. FIG. 4 shows the structure of a data dictionary containing information specified 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. IA. FIG. 7A shows the parameters used for requests generated by the presentation and functional modules of the controller shown in FIG. IA. FIG. 7B illustrates the temporal context handling and context block layout 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 and functional modules of the controller shown in FIG. IA. Show the structure. Figures 9A and 9B illustrate the operation of a dispatcher in conjunction with its associated dispatch table in processing requests from a presentation module or functional module 7. FIG. 9C shows the format of the composition database and the area database. FIG. 10A shows the structure of functional modules used to establish and detect alarm conditions, and FIG. 10B shows the structure of rules used to establish alarm conditions. 10... Presentation module 11... Function module 12... Access module I5... Information manager 17.22... Data storage device

Claims (1)

[Claims] 1. A storage management module that is a system that controls a set of entities and performs management functions, the storage management module performing the management functions by executing predetermined management-related commands. , wherein at least one of the modules stores rules identifying predetermined alarm conditions, a rule generator for generating rules for storing, and detecting an alarm condition depending on the content of the rules. system with an alarm condition detector. 2. A system for controlling and performing management functions over members of a computer network, wherein the members interface with the network to control major information processing functions, and the members further interface with the system. The device capable of performing the management function includes: a storage management module configured to perform the management function by executing a predetermined management-related command, and at least one of the modules a rule generator that stores rules identifying predetermined alarm conditions and generates rules for storing;
and an alarm condition detector that detects an alarm condition according to the content of the rule, wherein the rule specifies a value of the management information at one or more times. 3. A method for controlling and performing management functions over a collection of entities, wherein the entity interfaces with the collection to control primary information management functions, and the entity further interfaces with the system to perform the management functions. said management function by executing predetermined management-related instructions, at least one of which stores rules identifying predetermined alarm conditions; and providing a management module comprising a rule generator for generating rules for storage and an alarm condition detector for detecting an alarm condition depending on the content of the rules.