Data processing: measuring – calibrating – or testing – Measurement system – Performance or efficiency evaluation
Reexamination Certificate
2000-02-10
2002-11-19
Assouad, Patrick (Department: 2857)
Data processing: measuring, calibrating, or testing
Measurement system
Performance or efficiency evaluation
C210S088000
Reexamination Certificate
active
06484128
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a data processing system, and more particularly, to a data processing system which is constituted by a plurality of basic modules.
2. Description of the Related Art
Communications network systems involve a number of functional units such as signal transmission devices and switching subsystems. Those network elements are electronic systems which are generally composed of a plurality of circuit boards, or basic modules, each providing a specific function. Such a modular design allows maintenance people to repair the system easily when a failure occurs and some function is lost. This is actually accomplished by replacing a particular module that is relevant to the lost function. Although such replacement tasks seem simple, it is still possible for maintenance people to install a wrong module in place of the failed module, because they have to maintain and manage a large number of basic modules which constitute today's complex electronic systems.
To avoid the above problem, researchers have proposed several management methods. One example of such proposals is Japanese Patent Laid-open Publication No. 7-219806 (1995), which discloses a method to avoid mounting of an inappropriate module by mistake. This is achieved by comparing two instances of property data of basic modules. More specifically, one set of property data is maintained in the management system, based on the modules mounting locations. This is compared with the other set of property data that is stored in each basic module's identification data memory, thereby detecting erroneous installation of basic modules.
FIG. 21
is a diagram which shows a typical system configuration where the above-mentioned prior art method is employed. In this system of
FIG. 21
, the management system
1
monitors and controls each target system
30
-
1
to
30
-n through a network
20
. The network
20
, which is configured as a data communication network (DCN) or the like, permits the management system
1
and target systems
30
-
1
to
30
-n to communicate with each other. The target systems
30
-
1
to
30
-n serve as network elements (e.g., transmission units, switches), each comprising a plurality of basic modules. Although not explicitly shown in
FIG. 21
, each basic module has a unique identifier in its storage portion to distinguish itself from others. When required, this information is supplied to the management system
1
.
This management system
1
comprises a notification message parser
1
a
, a hardware change manager
1
b
, a failure record manager
1
c
, a system configuration database
1
e
, and a monitor console
1
g
. The notification message parser
1
a
receives various messages from the target systems
30
-
1
to
30
-n and delivers them to relevant portions of the system
1
, parsing the content of each message. The hardware change manager
1
b
becomes active when a basic module is replaced in any of the target systems
30
-
1
to
30
-n. It retrieves information about the replaced module from the system configuration database
1
e
and displays it on a screen of the monitor console
1
g
. The failure record manager
1
c
, on the other hand, becomes active when a module failure has occurred in any of the target systems
30
-
1
to
30
-n. It then retrieves information about the failed module, consulting the system configuration database
1
e
, and displays it on the monitor console
1
g
. The system configuration database
1
e
stores information on the mounting locations of basic modules constituting each target system, together with their identification data and the like. The monitor console
1
g
, which may be, for example, a cathode ray tube (CRT) display, visually presents information supplied from the hardware change manager
1
b
and failure record manager
1
c.
The above-described conventional system operates as follows. Now suppose that the target system
30
-
1
has encountered a problem with a certain basic module. The target system
30
-
1
detects this failure and notifies the management system
1
of the failure event and the properties of the failed basic module, along with the information for identifying the target system
30
-
1
itself. What are referred to here as the “failures” include recoverable failures and non-recoverable (or fatal) failures. In the management system
1
, the notification message parser
1
a
receives and parses the notification message from the target system
30
-
1
, recognizing that the received message is a failure notification concerning a specific basic module. Thus the message is passed to the failure record manager
1
c
. With reference to the basic module's properties extracted from the message, the failure record manager
1
c
searches the system configuration database
1
e
to find information relevant to the failed module. This search yields more information related to the basic module, and the failure record manager
1
c
then displays it on the screen of the monitor console
1
g
, together with the information showing which target system holds the failed basic module.
In the way described above, the management system
1
permits the system administrator to readily find the target system and basic module in question. Further, since the screen presents the device name, vendor name, version number, and other information for identifying the failed basic module, the administrator can quickly understand which basic module should be replaced if the failure is unrecoverable.
The target system
30
-
1
to
30
-n are designed to operate as follows, when a basic module is replaced. Suppose, for example, that a certain basic module in the target system
30
-
1
has been replaced with a new one as a result of deterioration or other causes of failure. The target system
30
-
1
then notifies the management system
1
of that module replacement. Also, the target system
30
-
1
sends property data read out of the new basic module, together with information for identifying the target system itself. This message is received and parsed by the notification message parser
1
a
in the management system
1
. Finding that the message is intended for notification of replacement of a specific basic module, the notification message parser
1
a
supplies the information to the hardware change manager
1
b
. Based on the given information, the hardware change manager
1
b
searches the system configuration database
1
e
for data relating to the previously mounted basic module. The hardware change manager
1
b
also compares the new module with the previous one in terms of their module types (e.g., module name, vendor name, version number). If they do not agree with each other (or if the new module is not listed as a possible alternative to the previous module), the hardware change manager
1
b
displays an alarm message on the screen of the monitor
1
g
to alert that an inappropriate module is currently used in the target system
30
-
1
. This allows the system administrator to readily determine whether the recent module replacement was properly performed or not.
The above-described conventional method, however, provides only a limited capability of module management. While the conventional method provides maintenance information about individual basic modules (e.g., which modules can be used for replacement), this may not always sufficient because the compatibility issues between one module and its related modules are lacking. Particularly, one could encounter a module incompatibility problem when trying to replace some module with another module from a different manufacturer or of a different version. That is, some replacement modules may not work together with other existing modules, because of the potential incompatibility between different vendor products or different product versions.
SUMMARY OF THE INVENTION
Taking the above into consideration, an object of the present invention is to provide a data processing system which checks the compatibility among basic modules used, so a
Horinouchi Yoshiaki
Kamada Masayoshi
Kobayashi Hirofumi
Mikami Koji
Sato Mitsuhiro
Assouad Patrick
Fujitsu Limited
Staas & Halsey , LLP
LandOfFree
Data processing system with configuration management... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Data processing system with configuration management..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Data processing system with configuration management... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2932023