 |
Description  |
|
|
REFERENCE TO A MICROFICHE APPENDIX
This application contains a microfiche appendix, designated A, which lists
program instructions incorporated in the disclosed expert system. The
total number of microfiche is 2 sheets and the total number of frames is
135.
TECHNICAL FIELD
This invention relates to maintaining computer systems and in particular to
maintaining such systems using an expert system.
BACKGROUND OF THE INVENTION
Modern private branch exchanges (PBX) use a computer to control a switching
network. PBXs are also referred to as customer switching systems or
private automatic branch exchanges (PABX). In addition to controlling the
PBX, the computer is continuously running basic diagnostic tests not only
on itself but also on the switching network and communication facilities
interconnecting the PBX to other PBXs and other types of computer systems.
In addition to permanent faults/alarms, these diagnostic tests find many
transitory faults within the PBX. The transitory faults may indicate that
a component of the PBX is marginally faulty or that the PBX's
environmental conditions have induced a failure in the PBX. Such
environmental conditions result from a variety of sources ranging from
error conditions on the communication facilities to electrical noise in
the AC power supplied to the PBX at its site. Each fault occurring on a
PBX must be investigated by a service technician to determine the severity
of the fault. When a PBX manufacturer has thousands of PBXs to maintain in
the field, the cost of making such investigations becomes enormous.
Some manufacturers have equipped their PBXs to report all faults to a
centralized service reporting center. A technician at the service
reporting center reviews the faults reports and then remotely accesses the
PBX to determine the cause of the faults. Whereas the ability of a
technician to remotely maintain PBXs is an improvement, the manufacturer
still incurs considerable costs in maintaining PBXs in the field because
of the labor cost of technicians.
Expert systems have been extensively used to assist in the maintenance of
remote systems by directly supporting maintenance technicians. U.S. Pat.
No. 4,697,243 discloses an expert system which assists technicians in the
maintenance of elevators. In that system, an expert system running on a
central computer leads an on-site technician through a diagnostic session
with menus, questions, and directions displayed to the technician on a
remote terminal. The technician communicates fault and test data to the
expert system via the terminal. The expert system then diagnoses the
elevator fault and sends the diagnosis back to the technician who then
repairs the elevator.
U.S. Pat. No. 4,517,468 discloses an expert system executing on a central
computer for collecting data from remote steam turbine generator power
plants. After collecting the data from a plant, the expert system
determines if a fault condition exists in that plant by using field
knowledge incorporated into the expert system. Upon detection of a fault
condition, the expert system communicates the information to the plant
operator with suggested actions to be taken. However, the expert system
does not directly run any tests on the plant or alter the state of data
within the plant. Further, the system requires an unique mechanism for
accessing the data from the plant since the system cannot use the same
means to gather data as used by technicians.
The problem with prior expert systems that diagnose fault conditions in
remote computer systems, is that they require a human technician to
determine the fault condition or to test and retire fault alarms in those
systems. Also those expert systems require special mechanisms for gaining
access to remote system data which add to the operating costs.
SUMMARY OF THE INVENTION
A technical advancement is achieved by an expert system that maintains
remote computer systems by directly accessing the remote computer systems,
diagnosing, and clearing fault conditions on those computer systems. The
expert system performs those functions by first accessing a fault report
from a centralized service reporting center, establishing a data
connection to the computer system reporting the fault, invoking diagnostic
routines on the computer system to gather data about the reported fault,
analyzing the data, and, if appropriate, clearing the reported fault from
the computer system. Advantageously, if the fault cannot be cleared, the
expert system recommends maintenance procedures and replacement parts for
a technician who the expert system dispatches to the remote computer. The
recommendations are based on field experience stored in rules and
databases maintained by the expert system. The centralized service
reporting center receives faults or alarms directly from the computer
systems, and the expert system accesses the reporting center via a digital
link.
The expert system accesses the remote computer system in the same manner as
a technician by placing a data call through the public telephone switching
network. After gaining access to the remote computer system, the expert
system invokes test procedures to obtain further data from the computer
system and retires alarms representing transitory faults. When the remote
computer system is controlling a customer switching system (PBX), the
expert system only invokes testing procedures in the computer system which
do not disrupt stable telephone calls. In addition, the expert system is
capable of maintaining different vintages of the same PBX and identifies
the vintage by interrogating each PBX.
In addition, the expert system maintains databases in which the results of
previous accesses to any individual PBX are recorded. That information is
continuously reused for each access to an individual PBX to diagnose
alarms on that system and identify recurrent problems.
These and other features and advantages of the invention will become more
apparent from the following description of an illustrative embodiment of
the invention considered together with the drawing.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of a plurality of systems including a computer
that executes an expert system embodying the principles of the invention
for maintaining the illustrated PBXs;
FIGS. 2 through 24 illustrate, in flow diagram form, the logical flow of
the expert system of Microfiche Appendix A;
FIGS. 25 through 33 provide an example of information displayed by the
expert system;
FIG. 34 illustrates a portion of the SINGLE FAILURE database;
FIG. 35 illustrates a portion of the MULTI-FAILURE database; and
FIG. 36 illustrates a portion of the HISTORY database.
DETAILED DESCRIPTION
FIG. 1 illustrates expert system 102 which embodies the principles of the
invention for performing maintenance on a plurality of PBXs (105 and 114)
via public telephone network 113. Expert system 102 is executing on
computer 100 which advantageously may be of the AT&T 6300 family of
personal computers. PBX 114 and 105 (also referred to as customer
switching systems) are telephone switching systems whose telephone
switching network is controlled by a stored program computer. Within each
PBX, the computer is constantly executing diagnostic routines checking for
fault conditions. For example, within PBX 105, computer 122 is
periodically running diagnostic routines to verify not only the state of
switch 123 but also the state of the central office trunks such as DS-1
120, digital transmission facility (DCIU) 124 and tape unit 121. If a
fault is detected with one of these units, PBX 105 records that fault.
Such a fault is commonly referred to as an alarm or an alarm condition and
results in a call being placed by PBX 105 via the public telephone network
113 to the service reporting center 104. Upon completion of the call,
computer 122 transmits the alarm information to service reporting center
104 where it is recorded. The process of recording alarms by service
reporting center 104 is referred to as generating a trouble report or
trouble ticket.
Once service reporting center 104 has recorded the trouble ticket in its
internal database, then either a human technician or expert system 102
accesses service reporting center 104 to obtain the trouble ticket. Either
the technician or expert system 102 accesses PBX 105 via public telephone
network 113 to run diagnostic procedures (PROCs) on computer 122 to
perform a complete diagnosis of the state of PBX 105. The accessing of PBX
105 for this purpose is referred to as a session. For the AT&T System 85,
detailed information on the operation of the PROCs is set forth in the
manual entitled, "AT&T System 85, Release 2, Version 4, Maintenance."
After either the technician or expert system 102 has initiated a session
with PBX 105, a listing of the alarms found by computer 122 is obtained
and then PROCs are run to perform diagnostic tests and gather additional
information concerning the nature of the alarms. Many alarms can be
resolved through the execution of PROCs and do not require the replacement
of any parts within PBX 105. After finishing the session with PBX 105,
both the technician and expert system 102 generate a report indicating
what alarms, if any, still exist on the system and a recommendation about
the desirability of sending a technician to the site. Expert system 102
also recommends what spare parts may be needed to resolve the remaining
alarms.
Consider now in greater detail the operations of expert system 102 in
maintaining PBX 105. As illustrated in FIG. 1, PBX 105 consists of switch
123, computer 122, tape unit 121, and DCIU 124 which interconnects PBX 105
to message center 125. The remainder of this description uses the
following example to illustrate the operation of expert system 102. The
example assumes that computer 122 has determined the existence of alarms
with respect to computer 122, tape unit 121, and a data transmission
facility such as DS-1 120 which are unit-type alarms 13, 2, and 68,
respectively. These alarms are illustrated in FIG. 27.
Expert system 102 is constructed using a rule-based methodology. Such a
methodology allows expert system 102 to represent units of knowledge in
the form of rules which allows easy change of the knowledge represented in
each rule without disturbing the rest of the system. A rule-based system
consists of three components: working memory, rule memory, and an
inference mechanism. The working memory describes the current state of the
rule-based system, and moderates all communication between rules. If a
rule needs to pass values to another rule, then it must do so through the
working memory. The programmer declares items in working memory using a
format that is similar to type-declaration information in standard
programming languages.
The rule memory is a collection of rules. Each rule consists of a set of
conditions and a set of actions. The programmer constructs the rules so
that each represents a functionally independent and meaningful portion of
the problem solution. In addition, the rule base has access to databases
where additional knowledge and PBX specific history information is stored.
An example of such databases is in expert system 102, the SINGLE FAILURE
and MULTI-FAILURE databases.
In procedural languages, the sequence of program statements and explicit
control statements determine execution order. In rule-based programming,
the inference mechanism regulates the matching, selection and execution of
rules. The inference mechanism is similar to an interpreter executing the
following four-step loop:
(1) In the match phase, the inference mechanism collects all rules whose
conditions match the current state in working memory.
(2) During the select stage, the inference mechanism selects the rule to be
executed. If there is more than one rule that matches the current state, a
process called conflict resolution specifies how rule priority is
determined.
(3) In the act stage, the actions specified by the selected rule are
executed. This results in modifications to the state of working memory.
(4) After the rules actions are executed, the inference mechanism again
begins the match stage. This loop continues until no more rules match
working memory, or until an explicit halt is encountered.
Expert system 102 is based on the C5 programming language which is similar
to OPS5 programming language designed and built by Carnegie-Mellon
University. Further details concerning C5 can be found in the article
entitled, "Rule-Based Programming in the Unix.RTM. System," G. T.
Vesonder, AT&T Technical Journal, Jan.-Feb. 1988, Volume 67, Issue 1.
Expert system 105 is illustrated in C5 source language in Microfiche
Appendix A.
Expert system 102 not only incorporates engineering and field experience
within the rules of the program, but also in databases. In particular, the
SINGLE FAILURE and MULTI-FAILURE databases are used to store
recommendations on whether to replace parts which have caused alarms
within PBX 105. In addition, expert system 102 maintains ADMINISTRATION,
HISTORY, and SWITCH databases. The ADMINISTRATION database contains
information detailing how the different components are utilized within a
PBX. The SWITCH database records information about configuration reported
to expert system 102 by each particular PBX with which it has
communicated. Finally, the HISTORY database contains a history of the
alarms found and action taken for each PBX session. The HISTORY database
is used to anticipate serious problems within a particular PBX and to
gather additional field experience for later incorporation into the rules
(see Microfiche Appendix A) and into the SINGLE FAILURE and MULTI-FAILURE
databases.
Expert system 102 is executed by processor 106 in computer 100 as
illustrated in FIG. 1. Programs are stored in memory 107 whereas the
databases are stored in disk 108. Initially, controller 101 accesses
service reporting center 104 via modem 111 and public telephone network
113. From service reporting center 104, controller 101 obtains the trouble
ticket information for PBX 105. Expert system 102 then obtains the trouble
ticket from controller 101. Expert system 102 then opens a session with
PBX 105 by accessing PBX 105 via VMAAP 103, modem 110, and public
telephone network 113. As described in greater detail with respect to FIG.
2, expert system 102 now obtains customer data and data concerning the
functions of PBX 105. After obtaining this information, expert system 102
requests and obtains from PBX 105 the number of alarms presently existing
on the PBX and detailed information about the unit-type and location of
each alarm.
For the present example, this information is illustrated in FIG. 27. A
unit-type 2 alarm indicates that there is a tape unit problem. A unit-type
68 alarm indicates that there has been an error on a data transmission
facility such as DS-1 120, and a unit-type 13 alarm indicates a failure on
a port data section of the memory of computer 122. As will be described in
greater detail with respect to FIGS. 13 and 14, expert system 102 performs
the appropriate PROCs with respect to tape unit 121 and determines that
the unit-type 2 alarm cannot be cleared since the trouble/fault still
exists on tape unit 121. Then by utilizing the data within SINGLE FAILURE
database, expert system 102 recommends that a service technician be
dispatched to PBX 105 with a new tape cartridge to replace the existing
one. Expert system 102 next analyzes the unit-type 13 and 68 alarms by
executing the appropriate PROCs and utilizing the SINGLE FAILURE and
MULTI-FAILURE databases. Expert system 102 will successfully cause PBX 105
to recover from these two alarms.
In addition, during each session, expert system 102 performs preventive
maintenance with respect to PBX 105 by determining whether computer 122
has undergone any initializations. Based on a examination of these
initializations using the HISTORY database, expert system 102 will
recommend whether a service technician should be dispatched to PBX 105 to
perform specified service procedures which can include the part
replacement.
FIG. 2 illustrates the initial setup and logging on to PBX 105 by expert
system 102 via VMAAP 103. Initially, expert system 102 obtains information
concerning the trouble ticket from controller 101. Upon obtaining this
information, expert system 102 creates initial working memory elements
using block 203 and opens the necessary output files via block 204. An
example of such a working memory element is the switch memory element
which contains the information illustrated in FIG. 25 in lines 2501 and
2502. An example of an output file opened by block 204 is one used to
store information such as illustrated in FIGS. 25 through 33. Block 205
initiates database table structures.
Using block 206, the expert system 102 instructs VMAAP 103 to place a call
to PBX 105 in order to open the session with PBX 105. Block 206 transmits
a command to VMAAP 103 which contains the necessary information to
identify PBX 105. Expert system 102 waits in block 206 until it receives
information back from VMAAP 103 indicating that the connection has been
made. Expert system 102 then requests the status of the connection via
block 207. Based on the status determined by block 207, decision block 208
determines if a connection has been made. If the connection status is "A1"
indicating a successful login to PBX 105, then path 216 is followed to
block 209. However, if the status is not "A1", block 210 is executed via
path 215. Execution of block 210 indicates that expert system 102 was
unable to log on to PBX 105 via VMAAP 103. This information then is
displayed via block 211 (see FIG. 22).
If it was possible to log on to PBX 105, expert system 102 requests, in
block 209, the customer data from PBX 105 via VMAAP 103. Upon receiving
the customer data, block 209 parses this data so that it is in a usable
form.
Next, expert system 105 determines the available modes of operation and
switch parameters of PBX 105. This is accomplished in FIG. 3. Blocks 301
through 307 determine what modes are implemented and available. The modes
include the administration, maintenance, and tape modes. The modes are
required in order to avoid interaction problems with other entities that
may also be doing work on the PBX, such as an on-site craftsperson. The
administration mode allows administration of the different characteristics
of the PBX such as which telephone numbers are assigned to which physical
ports. The maintenance mode allows the different maintenance procedures to
be executed. The tape mode allows the administration data stored on-line
in the PBX's memory to be transferred to tape unit 121.
The first decision that must be made is whether the PBX 105 is of a version
that requires the modes. This is done by block 301. Certain earlier
versions of PBX 105 did not have modes since only one entity at a time
could access the PBX. If the decision is made in decision block 301 that
the PBX under test does have modes, block 302 requests the data on which
modes are available. Next, block 303 checks if the maintenance mode is
available. If the maintenance mode is not available, path 325 is followed
to block 305 where the recommendation is set so that the message
"maintenance mode not available" is displayed during the display
recommendation portion of the session by block 211. If the maintenance
mode is not available, expert system 102 must stop the session with PBX
105 at this point since it cannot proceed without itself setting the
maintenance mode. If the maintenance mode is available, decision block 303
via path 326 checks whether the administration mode is available. If the
administration mode is available, then block 307 via path 328 sets both
the administration and maintenance modes. If the administration mode is
not available, path 327 is followed from decision block 304 to block 308
which sets the maintenance mode only. If the administration mode is not
available, the session does not stop since expert system 102 can perform
limited maintenance functions without the administration mode.
Blocks 310 through 321 determine whether computer 105 in PBX 105 is
duplicated, e.g., has two processors. One processor is online and the
other one is offline waiting to be brought online if the current online
processor fails. If PBX 105 has duplicated processors, it is necessary to
test both of them. Two Procedures (PROCs) perform the duplication testing.
These PROCs are detailed in the aforementioned AT&T Maintenance Manual.
First, PROC 275 is executed by block 309. Decision block 310 checks the
information returned by PBX 105 in response to PROC 275. If no error code
is returned by PBX 105, path 332 is followed to decision block 316. If an
error code of "3" is returned, expert system 102 determines that an error
may have occurred, and block 311 once again executes PROC 275 in PBX 105.
Decision block 313 checks the results of the execution of block 311; and
if no error code is returned, path 334 is followed to decision block 316.
If decision block 310 finds an error code other than "3" or if decision
block 313 finds any error code, paths 330 or 335, respectively, are
followed from these decision blocks to block 314. Block 314 executes PROC
613. The results of the execution of PROC 613 are checked by decision
block 319. If no error code is returned, path 340 is followed to block 318
since this indicates that PROC 613 has determined that computer 122 is
duplicated. If error code 74 is returned, path 342 is followed to block
317 since this indicates that PROC 613 has determined that computer 122 is
not duplicated. If any other error code is returned, path 341 is followed
to block 320 which indicates that the state of duplication is unknown.
If no error code was returned from the execution of PROC 275 in block 309,
then path 332 is followed from decision block 310. Decision block 316
examines field 10 of the information returned by PBX 105 in response to
PROC 275. This field indicates whether computer 122 is duplicated. If
computer 122 is not duplicated, then block 317 marks it as such. If PROC
275 indicates that the processor is duplicated, block 318 marks the system
as having a duplicated processor.
The information displayed in lines 2501 of FIG. 25 was obtained in block
209. Blocks 309 through 321 obtained line 2502.
FIG. 4 illustrates the additional administrative tasks that are performed
before the testing of PBX 105 can commence. Blocks 401 through 409 check
the SWITCH database to determine whether PBX 105 has had maintenance
performed on it in the past by expert system 102. First, block 401 queries
the SWITCH database to determine if it contains any data with respect to
the PBX under test. Decision block 402 then determines the number of
entries. If the PBX has not previously been encountered before, path 418
is followed to blocks 407 and 409 which build an entry in the SWITCH
database for this PBX. If paths 419 or 420 are followed, the switch has
previously had maintenance performed on it. However, what must still be
determined is whether the PBX's configuration has changed; and if it has
changed what the newest configuration is.
Path 420 is taken if the PBX has only one recorded configuration. If path
419 is followed indicating the existence of more than one past
configurations, then it is necessary to determine the newest entry which
defines the latest configuration that expert system 102 has encountered
with respect to PBX 105. After this has been determined, block 405 is
executed which determines (on the basis of the information received and,
as shown in FIG. 25 in lines 2501 and 2502) whether the present
configuration of PBX 105 represents a change from its last recorded
configuration. If there has been a change, block 407 via path 420 creates
a new database entry for this PBX. If there has not been a change, path
421 is followed to decision block 410.
Blocks 410 to 413 are concerned with obtaining the local time maintained by
PBX 105. The local time is important since PBX 105 may be located anywhere
in the world, and the PBX alarms which will be discussed later are
time-stamped relative to this local time. If decision block 410 determines
that the administration mode has been set by expert system 102, path 423
is followed to blocks 412 and 413 which obtain the local time from PBX
105. Block 414 then displays the local time as indicated in line 2503 of
FIG. 25. If the administration mode is not available, path 422 is followed
to connector 416.
Having obtained the information defining the system parameters of PBX 105,
expert system 102 now obtains an overall view of the maintenance condition
of PBX 105 by execution of PROC 600. Execution of PROC 600 on PBX 105
obtains the number of alarms on the PBX and then requests are made for
detailed information about each alarm. Block 501 transmits the PROC 600
request to PBX 105 via VMAAP 103. PBX 105 responds to this request with
the number of alarms which are outstanding within the PBX. This number is
read by block 502, and decision block 503 makes a determination of whether
any alarms exist on PBX 105. If no alarms exist, path 522 is followed to
block 506 which proceeds to check the off line processor, if any, for
alarms.
If alarms exist, then path 523 is followed to block 504 which displays
lines 2701 of FIG. 27. Expert system 102 obtains information concerning
each of these alarms by the repetitive transmission of the "next circuit"
command of PROC 600 by block 507. As information about each alarm is
received, it is displayed by block 508 to create each line in lines 2702
of FIG. 27. Warning alarms and the trunk software alarms identified by
decision blocks 510 and 512, respectively, are immediately cleared by
block 511 via paths 524 and 527, respectively. The sequence of block 504
through 512 is terminated by decision block 514 after information on all
the alarms has been obtained. As long as there is still an outstanding
alarm, path 530 is followed back to block 507. After information about all
alarms has been obtained from PBX 105, path 531 is followed to decision
block 515. Blocks 515 through 518 account for the fact that DCIU 124 and
tape unit 121 within PBX 105 can each have multiple alarms. Since the
diagnostic tests performed for these units are complete, it is desirable
only to perform each test once per session. Hence, blocks 515 through 518
remove all but at most one alarm for DCIU 124 and tape unit 121.
There are three overall goals that must be achieved in the execution of
each of the diagnostic PROCs. First, expert system 102 determines the
failures that caused each alarm by executing diagnostic routines on PBX
105. Secondly, expert system 102 generates a report detailing the results
of the diagnostic routines and indicating the remaining alarms on the
system. Finally, expert system 102 provides recommendations for replacing
hardware on PBX 105 if necessary. An example of such a recommendation is
illustrated in FIG. 33 where it is recommended to replace the tape
cartridge of PBX 105.
FIG. 6 is concerned with the order in which the alarms obtained in FIG. 5
should be processed. The aforementioned AT&T Maintenance Manual indicates
that the alarms should be processed in the order in which they are
received upon execution of PROC 600. This order is given by the entry
index number as illustrated in FIG. 27. However, field knowledge obtained
and incorporated into expert system 102 indicates that if both unit-type
11 and 23 alarms are encountered, then the alarm with a unit type of 23
should be processed first. Decision block 601 and block 602 accomplish
this. Similarly, experience has shown that if unit-type 55, 56 and 57
alarms are present together, then the alarms should be processed in
descending order by unit type (i.g. 57 then 56 then 55). This is
accomplished by blocks 603 and 605. Otherwise, if none of these special
cases are encountered, block 606 simply chooses the unprocessed alarm with
the highest index number.
Decision block 607 results in the execution of the diagnostic PROCs
detailed in FIGS. 7, 9, 11, 12, 13, and 15. It is important to remember
expert system 103, whose overall logical flow is illustrated in FIGS. 2
through 24 is implemented in a rule-based language (see Microfiche
Appendix A.) For more complete details on how each diagnostic routine is
implemented, the code starting at page 36 and entitled, "Referred PROCs"
in Microfiche Appendix A should be examined.
The following is a description of the operation of each of these PROCs.
Note that in our present example alarm information received from PBX 105
as illustrated in FIG. 27 indicates the existence of alarms of unit-types
2, 68, and 13. Unit-type 2 alarms indicate a problem with the tape unit.
Unit-type 68 alarms indicate that there has been an error on a data
transmission facility such as DS-1 120. Unit-type 13 alarms indicate a
failure in the port data section of the memory of computer 122. However
for unit-type 13 alarms, field experience incorporated into expert system
102 has shown that a variety of different equipment failures within PBX
105 may result in that type of alarm. Those failures will be further
detailed during the discussion of unit-type alarm 13.
FIG. 13 shows the logical operations performed by expert system 102 in
response to a unit-type 2 alarm. This alarm indicates that an error has
been encountered on tape unit 121. Decision block 1301 represents the
logical select stage of rule-based expert system 103 for a unit-type alarm
2.
Logical blocks 1302 through 1306 are concerned with versions of PBX 105
which require modes. If PBX 105 is of a non-mode version, then path 1315
is followed to block 1307. If modes are required, then blocks 1303 and
1304 determine whether the tape mode is available to expert system 102. If
the tape mode is not available, path 1317 is followed from decision block
1304 to block 1305 which marks the alarm as "uncleared."Marking the alarm
as uncleared causes a message indicating that fact to be printed. If the
tape mode is available, then block 1306 is executed via path 1318 to set
the tape mode.
Because of the nature of tape unit 121, failure status information only is
collected from this unit and no diagnostic tests are actually run on it.
However, as will be illustrated later, a recommendation may be made to
replace the tape cartridge. In response to the execution of PROC 610,
decision block 1308 determines whether tape unit failures have occurred.
If no tape unit failures are outstanding, blocks 1309 and 1310 are
executed via path 1320. These blocks note that the alarm has been cleared,
and a command is sent to PBX 105 to clear the indication in the PBX. In
FIG. 14, blocks 1401 through 1403 collect all the failures associated with
the unit-type alarm 2 on PBX 105.
FIG. 7 illustrates the logical flow performed in utilizing PROC 620 to
determine the cause of a network alarm. First, logical decision block 701
ascertains whether there are any such alarms. If there is an outstanding
network alarm, then control is passed to block 703 via path 729. Block 703
first obtains the unit-type and location of the failing network unit by
execution of PROC 620. Decision blocks 705 through 709 check whether there
are special cases which make it undesirable to execute the diagnostic
portion of PROC 620. Decision block 705 determines whether there are
intermodule calls that could be dropped if the diagnostic portion of PROC
620 is executed. If intermodule calls could be dropped, control is
transferred to block 710 via path 716. Decision block 706 checks whether
the failing network unit is the attendant console interface (unit-type
44). If the attendant console interface is failing, this test cannot be
performed since to properly perform the test, the attendant console
headset must be unplugged which requires a craftsperson on site. If the
unit failing is unit-type 44, path 718 is followed to block 710; if not,
path 719 is followed to decision block 707. The latter decision block
checks whether the alarm is of unit-type 45 which indicates an anxiliary
trunk circuit pack. In order to test that circuit pack, the DIP switches
must be set to a particular setting which is impossible to verify
remotely. If the alarm is of unit-type 45, path 720 is followed to block
710, otherwise path 721 is followed to decision block 708.
Decision block 708 determines whether the failing circuit pack has been
marked as "maintenance busy" indicating that there is a craftsperson on
site performing maintenance tests on this particular circuit pack. If the
circuit pack is marked as maintenance busy, path 722 is followed to block
710; otherwise, path 723 is followed to decision block 709. Decision block
709 checks a number of special situations where stable calls could be
dropped/disconnected if the diagnostic portion of PROC 620 is executed. If
stable calls could be dropped, path 724 is followed to block 710 since it
is undesirable to perform a test that could potentially drop calls. If the
testing would cause no stable calls to be dropped, path 725 is followed to
connector 712. Block 710 marks the alarm as "uncleared," which terminates
the session. Connector 711 interconnects to a portion of the program which
obtains the board type. This portion is executed so that the board can be
checked to insure that it is of the proper vintage and is properly
administered.
FIG. 8 illustrates another special case where the diagnostic portion of
PROC 620 often cannot be run. Unit-type 68 alarms indicate a failing DS-1
trunk unit such as unit 120 which has 23 separate channels, each capable
of carrying a telephone conversation. Since the probability is extremely
high that at least one of these channels will be active at any given point
in time, a non-invasive PROC (PROC 625) is used to investigate the status
of this particular facility. Decision block 801 checks if the failing
facility is of unit-type 68; and if it is, p | | |
