CA1253983A - Methods of servicing an elevator system - Google Patents
Methods of servicing an elevator systemInfo
- Publication number
- CA1253983A CA1253983A CA000514022A CA514022A CA1253983A CA 1253983 A CA1253983 A CA 1253983A CA 000514022 A CA000514022 A CA 000514022A CA 514022 A CA514022 A CA 514022A CA 1253983 A CA1253983 A CA 1253983A
- Authority
- CA
- Canada
- Prior art keywords
- user
- session
- knowledge base
- evidence
- elevator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired
Links
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B66—HOISTING; LIFTING; HAULING
- B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
- B66B5/00—Applications of checking, fault-correcting, or safety devices in elevators
- B66B5/0087—Devices facilitating maintenance, repair or inspection tasks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2257—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using expert systems
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
- G09B25/00—Models for purposes not provided for in G09B23/00, e.g. full-sized devices for demonstration purposes
- G09B25/02—Models for purposes not provided for in G09B23/00, e.g. full-sized devices for demonstration purposes of industrial processes; of machinery
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S706/00—Data processing: artificial intelligence
- Y10S706/902—Application using ai with detail of the ai system
- Y10S706/911—Nonmedical diagnostics
- Y10S706/918—Elevator
Abstract
ABSTRACT OF THE DISCLOSURE
A method of integrating an expert system having a knowledge base of elevator trouble-shooting information into the working environment of elevator service personnel, without special training of such personnel, and without compromising the security of the knowledge base. The method includes an interactive initialization procedure which includes successive, successful user and knowledge base initiated communication links between the user and knowledge base, before actual access to the knowledge base is permitted.
A method of integrating an expert system having a knowledge base of elevator trouble-shooting information into the working environment of elevator service personnel, without special training of such personnel, and without compromising the security of the knowledge base. The method includes an interactive initialization procedure which includes successive, successful user and knowledge base initiated communication links between the user and knowledge base, before actual access to the knowledge base is permitted.
Description
~Z~3983 ,, 1 52,553 METHODS OF SERVICING AN ELEVATOR SYSTEM
BACKGROUND OF THE INVENTION
Field of the Invention:
The invention relates in general to new and improved methods of servicing an elevator system, and more specifically to new and improved methods of integrating an expert system having a knowledge base of elevator trouble-shooting information into the working environment.
'De'scri tion o'f the Pr'ior Art:
p United States Patent No. 4,649,515, issued March 10, 1987, entitled "Methods and Apparatus for System Diagnosis and Control", sets forth an expert system which may be provided with a knowledge base suitable for diagnosing problems in an elevator system.
It would be desirable to be able to use an expert system as an inanimate consultant in the servicing of elevators, because elevator systems are very complex and time consuming to trouble shoot. Elevator service personnel must be given extensive and costly training, and their effectiveness varies with ability and experience. An expert system would provide the equivalent of the most able, most experienced service person as an immediately available consultant, whose expertise would not be lost by retirement. On the contrary, the know-ledge base would be constantly improved by taking advantage of the abilities and experiences of a large number of skilled elevator ~' "
.
:
.
~ Z S39 8 3
BACKGROUND OF THE INVENTION
Field of the Invention:
The invention relates in general to new and improved methods of servicing an elevator system, and more specifically to new and improved methods of integrating an expert system having a knowledge base of elevator trouble-shooting information into the working environment.
'De'scri tion o'f the Pr'ior Art:
p United States Patent No. 4,649,515, issued March 10, 1987, entitled "Methods and Apparatus for System Diagnosis and Control", sets forth an expert system which may be provided with a knowledge base suitable for diagnosing problems in an elevator system.
It would be desirable to be able to use an expert system as an inanimate consultant in the servicing of elevators, because elevator systems are very complex and time consuming to trouble shoot. Elevator service personnel must be given extensive and costly training, and their effectiveness varies with ability and experience. An expert system would provide the equivalent of the most able, most experienced service person as an immediately available consultant, whose expertise would not be lost by retirement. On the contrary, the know-ledge base would be constantly improved by taking advantage of the abilities and experiences of a large number of skilled elevator ~' "
.
:
.
~ Z S39 8 3
2 52,552 service personnel who, through a knowledge engineer, would add to and/or modify the domain dependent rule base.
For many reasons, it is important that the computer which runs the inference engine of the expert system, and the domain dependent rule base, be located in a centralized location. Security of the system is an important reason. It is also important because the centralized location may be used as a data gathering point for collecting and consolidating all elevator service field data which a knowledge engineer may study and use to add to and modify the rule base, as required, in order to improve the diagnostic ability of the expert system. Also, the centralized rule base would not be susceptlble to a number of different people making unco-ordinated changes. Further, a change made to a centralized rule base would be immediately available to all field service personnel.
Providing a plurality of expert systems for use by field service personnel would also not be desirable because such individual systems would be costly, bulky, and inconvenient to use, and it would require extensive training of high security personnel.
The problem then is how to efficiently integrate a centralized expert system into the every day working environ-ment of an elevator service technician, which will easily handle: (a) the inexperience of such personnel with expert systems, (b) the mistakes in inputting data required by the expert system in order to select and test the rules of the knowledge base, and (c) the interruptions which will occur in the communication between the field personnel and centralized location of the expert system. Further, the expert system must be easy to use without extensive, special training, so that field service personnel will want to make use of the expert system.
SUM~ARY OF THE INVENTION
Briefly, the new and improved methods of using an expert system eliminate the need for a highly skilled person to act as an intermediary between field personnel ~ ..
'`' ' : ` ~
. .
lZ~3983
For many reasons, it is important that the computer which runs the inference engine of the expert system, and the domain dependent rule base, be located in a centralized location. Security of the system is an important reason. It is also important because the centralized location may be used as a data gathering point for collecting and consolidating all elevator service field data which a knowledge engineer may study and use to add to and modify the rule base, as required, in order to improve the diagnostic ability of the expert system. Also, the centralized rule base would not be susceptlble to a number of different people making unco-ordinated changes. Further, a change made to a centralized rule base would be immediately available to all field service personnel.
Providing a plurality of expert systems for use by field service personnel would also not be desirable because such individual systems would be costly, bulky, and inconvenient to use, and it would require extensive training of high security personnel.
The problem then is how to efficiently integrate a centralized expert system into the every day working environ-ment of an elevator service technician, which will easily handle: (a) the inexperience of such personnel with expert systems, (b) the mistakes in inputting data required by the expert system in order to select and test the rules of the knowledge base, and (c) the interruptions which will occur in the communication between the field personnel and centralized location of the expert system. Further, the expert system must be easy to use without extensive, special training, so that field service personnel will want to make use of the expert system.
SUM~ARY OF THE INVENTION
Briefly, the new and improved methods of using an expert system eliminate the need for a highly skilled person to act as an intermediary between field personnel ~ ..
'`' ' : ` ~
. .
lZ~3983
3 52,553 and the centralized computer based expert system. Communi-cations are conducted directly between the elevator service technician and the central computer which r~ms the inference engine of the expert system, which in turn traverses the knowledge base network of domain dependent elevator service rules to create and propagate belief in a possible cause.
The possibility of unauthorized access to the knowledge base of the expert system is minimîzed by a method in which the elevator service technician establishes the initial contact with the central computer, and he enters a personal code known only to himself, such as his social security number.
If the personal code matches the code of an authorized user, the central computer asks the user for the building code which has been assigned to the building in which the elevator to be serviced is located. Once the building code is entered, the central computer breaks the user initiated communication link. If the building code is an authorized code, the central computer, using the authorized building code, obtains the information necessary to establish a computer initiated com~
munication link with the building in question. For example, it may use the building code to determine the telephone number of the elevator machine room of the associated building.
Thus, it is now known that the computer will be connected to a predetermined authorized telephone located in a secure location under the jurisdiction of authorized personnel.
Ease of operation is achieved by a terminal having a keyboard and a display. The terminal may be portable, or in the case of a large elevator installation, it may be fixed at the installation site. The central computer leads the service technician through the diagnostic session with menus, questions, and directions set forth on the display.
The central computer records each session such that inter-ruptions in the communication may be accommodated without requiring the service technician to re-input previously input evidence or data. The computer records the time the data is input, and before it is used ''~,.
. . .
: .
.
---` l.Z53983
The possibility of unauthorized access to the knowledge base of the expert system is minimîzed by a method in which the elevator service technician establishes the initial contact with the central computer, and he enters a personal code known only to himself, such as his social security number.
If the personal code matches the code of an authorized user, the central computer asks the user for the building code which has been assigned to the building in which the elevator to be serviced is located. Once the building code is entered, the central computer breaks the user initiated communication link. If the building code is an authorized code, the central computer, using the authorized building code, obtains the information necessary to establish a computer initiated com~
munication link with the building in question. For example, it may use the building code to determine the telephone number of the elevator machine room of the associated building.
Thus, it is now known that the computer will be connected to a predetermined authorized telephone located in a secure location under the jurisdiction of authorized personnel.
Ease of operation is achieved by a terminal having a keyboard and a display. The terminal may be portable, or in the case of a large elevator installation, it may be fixed at the installation site. The central computer leads the service technician through the diagnostic session with menus, questions, and directions set forth on the display.
The central computer records each session such that inter-ruptions in the communication may be accommodated without requiring the service technician to re-input previously input evidence or data. The computer records the time the data is input, and before it is used ''~,.
. . .
: .
.
---` l.Z53983
4 52,553 the age of the data is computed and compared with a prede-termined maximum time value. The computer asks the user if he wants to input new data when the age exceeds the maximum value.
In some instances, the service technician or user will have access to the memory of a solid state or computer operated elevator system, such as via a special terminal.
The special terminal may be a portable, plug-in terminal, or a permanent terminal installed at the elevator site~ In this situation, the central computer provides the user with the code that should be entered into the special terminal, in order to obtain a block of data, certain of which is required by the central computer. The block of data, for example, may be in the form of a two digit hex n~mber containing eight bits of information. The user then inputs the two digit hex number into the local terminal for communication to the central computer. Subsequently, the age of this data is also computed before use.
Sensor data input by the user is checked for range. If it is outside a predetermined range for this sensor, which would question the validity of the data, the user iQ asked to re-input the data, in order to catch reading errors, keying errors, or errors in transmission.
An input error recognized by the user is accommodated ~imply by the user actuating a predetermined key, such as a control "E", which selects an error routine. The error routine steps back through the questions and answers of the instant ~ession, starting with the most recent question and an~wer, giving the user the opportunity to correct each an~wer. When the correction is made, actuating a control "E" again terminates the error routine. The inference engine is re-run, using the revised data.
If the expert system fails to list the malfunc-tion symptom which the service technician has identified as being a problem in the elevator system, or if the expert system fails to accurately diagnose the problem of an identified symptom, the user enters this new symptom, the ~':
:
In some instances, the service technician or user will have access to the memory of a solid state or computer operated elevator system, such as via a special terminal.
The special terminal may be a portable, plug-in terminal, or a permanent terminal installed at the elevator site~ In this situation, the central computer provides the user with the code that should be entered into the special terminal, in order to obtain a block of data, certain of which is required by the central computer. The block of data, for example, may be in the form of a two digit hex n~mber containing eight bits of information. The user then inputs the two digit hex number into the local terminal for communication to the central computer. Subsequently, the age of this data is also computed before use.
Sensor data input by the user is checked for range. If it is outside a predetermined range for this sensor, which would question the validity of the data, the user iQ asked to re-input the data, in order to catch reading errors, keying errors, or errors in transmission.
An input error recognized by the user is accommodated ~imply by the user actuating a predetermined key, such as a control "E", which selects an error routine. The error routine steps back through the questions and answers of the instant ~ession, starting with the most recent question and an~wer, giving the user the opportunity to correct each an~wer. When the correction is made, actuating a control "E" again terminates the error routine. The inference engine is re-run, using the revised data.
If the expert system fails to list the malfunc-tion symptom which the service technician has identified as being a problem in the elevator system, or if the expert system fails to accurately diagnose the problem of an identified symptom, the user enters this new symptom, the ~':
:
5 52,553 cause of the symptom or malfunction and the troublsshooting steps which the user utilized in order to identify the Amalfunction cause and~solve the problem. This information may be used by a knowledge engineer to add to the malfunc-5 tion symptom menu, as well as to add new rules to the domain dependent rule base, thus allowing the expert system to be constantly improved and more reliable as new field data is gathered. It is conceivable that properly format-ted, the information input by the elevator technician may 10 be automatically used to modify the menu, and to make new rules in evidence-hypothesis format for the domain depen-dent rule base.
BRIEF DESCRIPTION OF ~HE DRAWINGS
The invention may be better understood, and 15 further advantages and uses thereof more readily apparent, when considered in view of the following detailed descrip-tion of exemplary embodiments, taken with the accompanying drawings, in which:
Figures 1 and lA may be co~bined to provide a 20 schematic diagram of the hardware involved in servicing a plurality of elevator systems utilizing a centralized expert system as a consultant, according to the methods of the invention;
Figure 2 is a RAM map of timers, flags and 25 program variables which will be used in the description of the program flow charts shown in Figures 4-11;
Figure 3 is a RAM map of an interrupted 3ession table maintained for each authorized user, which table is referred to in certain of the program flow charts of 30 Figures 4-11;
Figure 4 is a block diagram which broadly sets forth the teachings of the invention;
Figure 5 is a flow chart of a program which implements a "session initiate routine" shown in block form 35 in Figure 4;
lZS3983
BRIEF DESCRIPTION OF ~HE DRAWINGS
The invention may be better understood, and 15 further advantages and uses thereof more readily apparent, when considered in view of the following detailed descrip-tion of exemplary embodiments, taken with the accompanying drawings, in which:
Figures 1 and lA may be co~bined to provide a 20 schematic diagram of the hardware involved in servicing a plurality of elevator systems utilizing a centralized expert system as a consultant, according to the methods of the invention;
Figure 2 is a RAM map of timers, flags and 25 program variables which will be used in the description of the program flow charts shown in Figures 4-11;
Figure 3 is a RAM map of an interrupted 3ession table maintained for each authorized user, which table is referred to in certain of the program flow charts of 30 Figures 4-11;
Figure 4 is a block diagram which broadly sets forth the teachings of the invention;
Figure 5 is a flow chart of a program which implements a "session initiate routine" shown in block form 35 in Figure 4;
lZS3983
6 52,553 Figure 6 is a flow chart of a program which implements an "interrupted session routine" shown in block form in Figure 4;
Figure 7 is a flow chart of a program which implements a "symptom select routine" shown in block form in Figure 4;
Figures 8A and 8B may be combined to provide a flow chart of a program which implements an "interactive session routine" shown in block form in Figure 4;
Figure 9 is a flow chart of a program which implements a "session close routine" shown in block form in Figure 4;
Figure 10 is a flow chart of a program which expands upon a method step of the interactive session routine shown in Figure 8; and Figure 11 is a flow chart of an error correction subroutine which may be called by the interactive session routine shown in Figure 8.
DES'CRIPTION'OF'THE'PREFERRED'EMBO~TMENTS
Referring now to the drawings, and to Figures 1 and lA in particular, there is shown an elevator trouble shooting and servicing system 20 which may utilize the teachings of the invention. System 20 includes an expert system 22 located at a convenient, secure, central location 23, such as a manufacturing facility for elevator systems, and a plurality of remotely located elevator systems, such as elevator systems 24 and 26. Expert system 22 includes a knowledge base 28 of elevator trouble-shooting information and an inference engine 30, which may be the same as dis-closed in the hereinbefore mentioned U.S. Patent 4,649,515, and thus it need not be described in detail. In general, the knowledge base 28 includes a plurality of domain dependent rules formatted in evidence-hypothesis form by a knowledge engineer and one or more experts in the servicing of elevator systems. The inference engine 30 contains domain ~.
... . ... .. . .. .
. ~ ', . ~ .
Figure 7 is a flow chart of a program which implements a "symptom select routine" shown in block form in Figure 4;
Figures 8A and 8B may be combined to provide a flow chart of a program which implements an "interactive session routine" shown in block form in Figure 4;
Figure 9 is a flow chart of a program which implements a "session close routine" shown in block form in Figure 4;
Figure 10 is a flow chart of a program which expands upon a method step of the interactive session routine shown in Figure 8; and Figure 11 is a flow chart of an error correction subroutine which may be called by the interactive session routine shown in Figure 8.
DES'CRIPTION'OF'THE'PREFERRED'EMBO~TMENTS
Referring now to the drawings, and to Figures 1 and lA in particular, there is shown an elevator trouble shooting and servicing system 20 which may utilize the teachings of the invention. System 20 includes an expert system 22 located at a convenient, secure, central location 23, such as a manufacturing facility for elevator systems, and a plurality of remotely located elevator systems, such as elevator systems 24 and 26. Expert system 22 includes a knowledge base 28 of elevator trouble-shooting information and an inference engine 30, which may be the same as dis-closed in the hereinbefore mentioned U.S. Patent 4,649,515, and thus it need not be described in detail. In general, the knowledge base 28 includes a plurality of domain dependent rules formatted in evidence-hypothesis form by a knowledge engineer and one or more experts in the servicing of elevator systems. The inference engine 30 contains domain ~.
... . ... .. . .. .
. ~ ', . ~ .
7 52,553 independent rules which contro~ the selection and applica-tion of the domain dependent rules. The inference engine 30 builds a network of domain dependent rules which propa-gates belief in hypotheses to arrive at a probable cause of S malfunction symptoms input to the system 22 by a user. The programs for the expert system 22 are resident in a central computer 31, which may be dedicated to the elevator ser-vicing function, or which may be a large computer used to run a variety of other application programs.
iO Diagnostic system software 32, formulated accord-ing to the teachings of the invention, is also resident in the central computer 31, for integrating the expert system 22 into the working environment of an elevator service technician. 3~
A 15 A user's terminal ~ may also be located at the centralized location 23, with terminal 34 having a keyboard 36 and a display 38. Terminal 34 may be plugged directly into the central computer 31.
The central locatio~n 23 also includes means, such as a telephone and modem ~, for communicating with the plurality of elevator systems via a communication system 40, such as a telephone communication systern. Any other suitable communication means may be used, such as radio or microwave. Various communication links associated with communication means 40 are indicated generally at 41, 41' and 41".
Two elevator systems 24 and 26 are illustrated in Figures 1 and lA, in order to set forth two different remote communication arrangements which may be used at the various elevator system sites. Elevator system 24 includes a building 42 having one or more hoistways 44 for accommo-dating one or more elevator cars 46 and their counter-weights 47. Building 42 also includes a machine room 48 for the elevator drive machines S0, traction sheave 52, and elevator system control 54. Exemplary car controllers are illustrated in U.S. Patents 3,750,850 and 3,804,209, U.S.
Patent 4,416,352 sets forth exemplary drive machine con-` ~2~i~983
iO Diagnostic system software 32, formulated accord-ing to the teachings of the invention, is also resident in the central computer 31, for integrating the expert system 22 into the working environment of an elevator service technician. 3~
A 15 A user's terminal ~ may also be located at the centralized location 23, with terminal 34 having a keyboard 36 and a display 38. Terminal 34 may be plugged directly into the central computer 31.
The central locatio~n 23 also includes means, such as a telephone and modem ~, for communicating with the plurality of elevator systems via a communication system 40, such as a telephone communication systern. Any other suitable communication means may be used, such as radio or microwave. Various communication links associated with communication means 40 are indicated generally at 41, 41' and 41".
Two elevator systems 24 and 26 are illustrated in Figures 1 and lA, in order to set forth two different remote communication arrangements which may be used at the various elevator system sites. Elevator system 24 includes a building 42 having one or more hoistways 44 for accommo-dating one or more elevator cars 46 and their counter-weights 47. Building 42 also includes a machine room 48 for the elevator drive machines S0, traction sheave 52, and elevator system control 54. Exemplary car controllers are illustrated in U.S. Patents 3,750,850 and 3,804,209, U.S.
Patent 4,416,352 sets forth exemplary drive machine con-` ~2~i~983
8 52,553 trol, and U.S. Patents, 3,851,733 and 3,851,734 set forthsuitable group supervisory control which may be used. `
Elevator system 24 further includes communication means, such as a telephone and modem 56 in the machine room 48. Thus, a service technician 58 may bring a user terminal 60 into th~ machine room 48, or one may be permanently installed in the machine room, as desired. Terminal 60 includes a key-board 62 and display 64, which are connected to the telephone and modem 56.
The service technician 58 may take direct read-ings from various sensors and circuit points in the elevator system control 54. In certain solid state elevator control systems, the service technician 58 may have a portable, hand-held terminal 66 which plugs into the elevator system control 54 and gains access to the memory (RAM) of the control system.
The service technician keys in a specific code for each block of elevator sys'em signals desired to be read, and the display, for example, may provide eight binary signals in the form of a two digit hex number. The code and specific signals associated with each of the eight bit positions in the two digit hex number is also provided in the form of look-up tables in the central computer 31. Thus, when the expert system 22 desires predeter-mined evidence, i.e., sensor readings or signals for the domain dependent rules under consideration, system 22 will know when the service technician is using a terminal 66, and it will also know whether or not the required evidence is available via the use of terminal 66. When the evidence is available via terminal 66, system 22 will ask the service technician 58 to key in a predetermined code into the terminal 66. When the service technician receives the two digit hex number in response to the code, which appears on the read out or display of terminal 66, he will then enter the hex number into the keyboard 62.
:
, ,
Elevator system 24 further includes communication means, such as a telephone and modem 56 in the machine room 48. Thus, a service technician 58 may bring a user terminal 60 into th~ machine room 48, or one may be permanently installed in the machine room, as desired. Terminal 60 includes a key-board 62 and display 64, which are connected to the telephone and modem 56.
The service technician 58 may take direct read-ings from various sensors and circuit points in the elevator system control 54. In certain solid state elevator control systems, the service technician 58 may have a portable, hand-held terminal 66 which plugs into the elevator system control 54 and gains access to the memory (RAM) of the control system.
The service technician keys in a specific code for each block of elevator sys'em signals desired to be read, and the display, for example, may provide eight binary signals in the form of a two digit hex number. The code and specific signals associated with each of the eight bit positions in the two digit hex number is also provided in the form of look-up tables in the central computer 31. Thus, when the expert system 22 desires predeter-mined evidence, i.e., sensor readings or signals for the domain dependent rules under consideration, system 22 will know when the service technician is using a terminal 66, and it will also know whether or not the required evidence is available via the use of terminal 66. When the evidence is available via terminal 66, system 22 will ask the service technician 58 to key in a predetermined code into the terminal 66. When the service technician receives the two digit hex number in response to the code, which appears on the read out or display of terminal 66, he will then enter the hex number into the keyboard 62.
:
, ,
9 52,553 When terminal 66 is not being used, or when the desired evidence is not available via terminal 66, system 22 will specifically describe the sensor data to be obtained. In the following description, evidence taken directly by the service technician will be referred to as evidence from a sensor, and evidence taken indirectly via terminal 66 will be referred to as evidence from buffered sensors.
Elevator system 26, where similar to elevator system 24, utilizes like reference numerals except with the addition of a prime mark, and these like elements will not be described again. The difference between elevator systems 24 and 26 lies in the fact that in system 26 the user terminal 60' is not available for use directly in the machine room 48'. Thus, the service technician 58 com~uni-cates with a user 68, such as via telephones 70 and 72, respectively, located in the machine room 48' and at the location of terminal 60'. U~er 68 relays questions and suggestions from display 64' to the service technician 58', and the service technician 58' obtains the requested sensor evidence, or tries the suggested test procedures, and informs the user 68, who then keys an appropriate response into keyboard 62'.
Figures 2 and 3 are RAM maps which set forth program variable and tables utilized in the programs set forth in Figures 4-11. The programs o Figures 4-11, set forth in detailed flow charts, implement the diagnostic system software 32 shown in Figure 1, and they integrate tho expert system 22 into the work environment of the elevator service technician. This integration is accom-plished such that a technician with little experience with computers may easily interact with the knowledge base, without any compromise of security.
The letters in parenthesis in the function blocks of Figures 4-11, indicate whose action is involved in the ~ block. A "(U)" indicates the user of the remote terminal, a "(T)" indicates the remote terminal and a "(C)" indicates the central computer.
, ~, ~, .
lZS3983 52,553 Figure 4 is a functional block diagram of the diagnostic system 32 shown in Figure 1, which starts at terminal 80 and enters function 82 which is entitled "Session Initiate Routine". Function 82 attempts to establish a user initiated communication link with the central computer 31, and, as will be hereinafter described, it does so without requiring specialized knowledge or training on behalf of the user. Block 82 also performs the vital security functions which permit only authorized access to the expert system by authorized users. If the user is not authorized, function 82 disconnects and termi-nates the user initiated communication link, as indicated at 83.
If the central computer 31 recognizes an author-ized u~er, it breaks the user initiated communication linkand then attempts to call back to try to establish a computer initiated communication link with the proper building and user. If the central computer 31 is unable to e~tablish a communication link with ths user at this time, it will ~et a flag "no connect" shown in the RAM map of Figure 2, and ~tep 84 checks the state o this flag. If thi~ flag is set, step 84 terminates the communication, indicated at 86.
I step 84 finds the no-connect flag is not set, step 88 initializes a pointer PTR to ~n interrupted session table for the identiied user, ~uch a~ the ta~le shown in the RAM map of Figure 3. The centralized computer stores each session in memory, until the session ha~ been complet-ed. Thus, when a session for a user i5 not completed, for 80me rea~on, the central computer 31 already has the results of the session in memory and it makes an entry into the interrupted session table for the specific user. The table, which is a LIF0 table, includes a listing o each interrupted session for this user, by date and time-o-day.
Function 90 then checks pointer PTR to determine if there is an interrupted session for this user. Function 90 then also give~ the user the opportunity of reestablishing any ' ~ .
.
lZ~ 83 11 52,553 such session, stepping through the interrupted sessions, when there is more than one, starting from the most recen'.
Function 90 also gives the user the opportunity of starting from where the prior session ended, and the opportunity to review the session, including the chance to change prior evidence which was input during the session before it was interrupted.
The interrupted session routine at block 90 then proceeds to a symptom select routine in block 92. If this is not an interrupted session, function 92 displays a menu of elevator malfunction symptoms for the user to make a selection. An expansion of the user selection, through appropriate sub-menus, may also be made after the initial selection, if more specific information is required by the expert system.
Function 94 then performs an interactive ~ession with the user, in which the expert system asks the user for ~pecific information or evidence, as required by the evidence-hypothesis format of the knowledge based rules, until a possible cause of the malfunction symptom is identified. The expert system will display the possible cause, the confidence factor in the belief that this is the cause, as well as a suggested corrective action. If the information provided by the expert system does not solve the problem, the session continues until either the problem i ~olved or the user decides to terminate the session. If tho u~er decides to terminate the session, a session close routino, shown in blocX 96, is performed. During the functlon of block 96, information is provided by the user to the central computer on the success of the session and this function gives the user the opportunity to input information relative to the actual cause of the problem, and the trouble-shooting steps utilized to solve the ; problem, when the session was not successful. This infor-mation is then used by a knowledge engineer to update the system menu and rule base.
~' , ~
' ,~ -12 52,553 Step 98 then clears the current session from memory, since, upon reaching this point, the session has been completed. The entry into the interrupted session table for this particular user will also be purged.
step 100 checks to see if the session which has just been completed had been previously interrupted, such as by checking a flag "interrupted session". Such a flag may be set when the session is the completion of an inter-rupted session. If the interrupted session flag is set, then there may be other interrupted sessions that this same user may which to resume, so the program returns to func-tion 90. If the interrupted service flag is not set, the program returns to step 92 to give the user the opportunity to input a symptom of still another problem, or to give the user the opportunity to terminate the session. The program continues as hereinbefore described, until the user selects "exit", which is included with the list of symptoms in the symptom menu of function 92.
Figure 5 is a flow chart which may be used to implement the session initiate function 82 shown in Figure 4. Routine 82 is entered at input 80, the same as shown in Figure 4, and step 102 merely requires that the user insert the application disc into the terminal 60 and turn on the electrical power. Step 104, which is performed by the terminal 60, automatically dials the central computer 31.
Step 106, performed by terminal 60, checks to see if a connection has been made with the central computer. If not, the program continually loops through step 106, until either a user initiated communication link is established with the central computer, or the user desires to terminate the attempt to establish the communication link.
If step 106 finds that a connection has been made with the central computer, step 108 performs an automatic log-in function, which includes the terminal sending an account name and a password. The account name identifies that the user wishes to access the expert system for elevator trouble-shooting. The account name is necessary i2S;~983 13 52,553 when a large computer is involved, which may have many different application programs to run. The password is built into the disc, and identifies the disc as an authen-tic disc for establishing a communication link with the central computer.
Step 110 then requires the user to key in a personal code or password, known only to him. For example, the personal password may be the user's Social Security Number. Upon receipt of the personal password, the central compu~er, in step 112, checks to see if this password is associated with an authorized user. If it is not, step 114 records the number entered and increments a counter, such as the software counter shown in the RAM map of Figure 2.
Step 116 checks to see if the count has reached a predeter-mined value, such as three. If it has not reached thepredetermined count value, the program returns to qtep 110 in order to give the user the opportunity of entering a correct personal code. If the count of such attempts reaches the predetermined value, step 116 branches to step 118 which resets the counter and disconnects the communi-cation link. The record of incorrect numbers stored in step 114 is available for use by authorized personnel, should they desire to investigate the unsuccessful attempt to utilize the expert system.
When step 112 finds that the personal code is an authorized code, the central computer then resets the counter and advances to a portion of the program concerned with a code previously assigned to the building. The contral computer asks the user to enter the building code, and step 120 indicates the entering of the building code by the user. Step 121 checks to see if this code is an authorized code. If it is not an authorized code, step 122 records the building code actually entered and the counter shown in the RAM map of Figure 2 is incremented. Step 124 checks to see how many unsuccessful attempts at enteringthe building code have been made, and if the number reaches a predetermined value, such as three, the computer, in step ''" ' .
.
`:
~ .
14 52,553 126, resets the counter and disconnects the communica~ion link with the accessing terminal. If step 124 finds that the maximum number of attempts has not been reached, the program returns to step 120, to enable the user to enter S the proper building code.
If step 121 finds that the authorized building code has been entered, step 128 resets the counter and disconnects the user initiated communication link. The central computer then accesses a look-up table, using the building code, to obtain the telephone number of the machine room associated with the identified building. Step 130 also includes the function of dialing the telephone number found in the look-up table. Step 132 checks to see if a connection has been made, and if it finds that no connection has been made, step 133 checks to see if a predetermined period of time has expired since step 130 dialed the telephone number. Step 130, for example, may start a software timer, such as the timer shown in the RAM
map of Figure 2. The program loops through steps 132 and 133 until step 133 finds that the time has expired, which results in the computer setting the "no-connect" flag, as indicated in 134, or until step 132 finds that a connection has been made. When step 132 finds that a connection has been made, the program advances to step 84 at terminal 136.
As shown in Figure 4, step 8~ checks the "no-connect" 1ag shown in the RAM map o Figure 2, and if this flag was set in step 134 of Figure S, the computer ends the attempted session at 86. If step 84 shown in Figure 4 finds that the "no-connect" f~ag has not been set, step 88 inltlallzes the pointer PTR to the interrupted session table for the specific identified user, and the program advances to function 90.
Figure 6 is a flow chart which may be used to implement function 90, which is entitled "interrupted session routine". This routine is entered at 140 and step 142 checks to see if there are any interrupted sessions for the identified user. This is determined simply by checking , . . .
~ ~ , ,, ::
~:
' -lZ~39~
52,553 the pointer PTR to the user's interrupted session table.
If there is no entry at the initialized position of pointer PTR, there are no interrupted sessions and the program advances to step 166, which resets the interrupted session flag shown in the RAM map of Figure 2, and the routine exits at 168, which proceeds to function 92.
When step 142 finds an entry at the location of the pointer PTR, there is at least one interrupted session and the central computer displays the date and time of the interrupted session on the display of the user terminal 60.
This is indicated in block 144 of Figure 6. The central computer then asks the user, in block 146, if he wishes to resume the interrupted session displayed. If the user wishes to resume this session he indicates the desire by an appropriate entry on the keyboard 62, and the central computer, in block 148 reads the session data of the interrupted session into the current session memory. The central computer then asks the user iX he wants to review what has occurred in the interrupted session, as indicated in block 150. If the user wishes to review this informa-tion, such as to refresh his memory or to give him the opportunity of changing prior entries such as due to errors or due to the age of the data, the user indicates an affirmative answer on the keyboard 62. The central comput-er then set~ a review flag, shown in the RAM map of Figure2, as indicated in step 152. The review flag will be checked in a sensor check routine shown in Figure 10, which will be hereinafter described.
If step 150 finds the user does not wish to review the interrupted session, step 154 resets the review flag and step 156 sets an interrupted session flag, shown in Figure 2, in order to let subsequent routines Xnown that this session is the continuation of an interrupted session.
After the interrupted session flag is set in step 156, the program advances to function 92, as indicated at terminal 168.
:
.
~2S3983 16 52,553 Should step 146 find that the user does not wish to resume the interrupted session displayed, step 158 asks the user if he wishes to save the interrupted session displayed. If the user gives a negative reply, step 160 deletes that specific session from the memory. If step 158 finds the user wishes to save the displayed interrupted session, step 162 increments the pointer PTR to the inter-rupted session table. Step 164 then checks to see if there are any more interrupted sessions. If there are, estab-lished by the pointer PTR pointing to a non-zero entry, the program returns to step 144. If step 164 finds there are no more interrupted sessions, step 166 resets the inter-rupted session flag to indicate that the current session is not the continuation of an interrupted ~ession. The program then advances to function 92, as indicated at terminal 168.
A flow chart which implements the symptom select routine of function 92 is set forth in Figure 7. This routine is entered at terminal 170 and step 172 checks to see if the interrupted session 1ag is set. If it is set, indicating the current session ic the continuation of an interrupted session, step 174 reads the malunction symptom which was previously selected and stored in memory. Step 175 loads the. context of the selected symptom. Step 176 then asks the user if he has a hand held terminal 66. If he does, step 178 sets flag HHT, shown in the RAM map of Eigure 2, to indicate that the user has a hand held termi-nal, and the program advances to function 94 from exit terminal 180. If step 176 finds that the user does not hav- a hand-held terminal, step 178 is bypassed, with the routine exiting at terminal 180.
If step 172 finds that the interrupted session flag is not set, indicating that the current session is not the continuation of an interrupted session, ~tep 182 retrieves the main malfunction symptom menu from memory, and step 184 displays the symptom menu for the user on display 64. Table I sets forth an exemplary main menu.
.
. ~ :
~ .
~2S3983 17 52,553 The user makes a selection, indicated at step 186, and the central computer checks the selection to see if a sub-menu is required, in step 188. Some symptoms displayed in the main menu may be broad cateqories of malfunction symptoms, requiring a more detailed selection. When a sub-menu is required, step 190 obtains the appropriate sub-menu, and returns to step 184 to display the menu just obtained.
TABLE I
SYMPTOMS
1. Hand held terminal will not log on 2, Car will not run and car is at floor level 3. Car will not run and car i8 not at floor level 4. Car dynamic~
5. Car calls 6. Corridor calls 7. System processor not runni.ng 8. Car on block operation 9. Other message
Elevator system 26, where similar to elevator system 24, utilizes like reference numerals except with the addition of a prime mark, and these like elements will not be described again. The difference between elevator systems 24 and 26 lies in the fact that in system 26 the user terminal 60' is not available for use directly in the machine room 48'. Thus, the service technician 58 com~uni-cates with a user 68, such as via telephones 70 and 72, respectively, located in the machine room 48' and at the location of terminal 60'. U~er 68 relays questions and suggestions from display 64' to the service technician 58', and the service technician 58' obtains the requested sensor evidence, or tries the suggested test procedures, and informs the user 68, who then keys an appropriate response into keyboard 62'.
Figures 2 and 3 are RAM maps which set forth program variable and tables utilized in the programs set forth in Figures 4-11. The programs o Figures 4-11, set forth in detailed flow charts, implement the diagnostic system software 32 shown in Figure 1, and they integrate tho expert system 22 into the work environment of the elevator service technician. This integration is accom-plished such that a technician with little experience with computers may easily interact with the knowledge base, without any compromise of security.
The letters in parenthesis in the function blocks of Figures 4-11, indicate whose action is involved in the ~ block. A "(U)" indicates the user of the remote terminal, a "(T)" indicates the remote terminal and a "(C)" indicates the central computer.
, ~, ~, .
lZS3983 52,553 Figure 4 is a functional block diagram of the diagnostic system 32 shown in Figure 1, which starts at terminal 80 and enters function 82 which is entitled "Session Initiate Routine". Function 82 attempts to establish a user initiated communication link with the central computer 31, and, as will be hereinafter described, it does so without requiring specialized knowledge or training on behalf of the user. Block 82 also performs the vital security functions which permit only authorized access to the expert system by authorized users. If the user is not authorized, function 82 disconnects and termi-nates the user initiated communication link, as indicated at 83.
If the central computer 31 recognizes an author-ized u~er, it breaks the user initiated communication linkand then attempts to call back to try to establish a computer initiated communication link with the proper building and user. If the central computer 31 is unable to e~tablish a communication link with ths user at this time, it will ~et a flag "no connect" shown in the RAM map of Figure 2, and ~tep 84 checks the state o this flag. If thi~ flag is set, step 84 terminates the communication, indicated at 86.
I step 84 finds the no-connect flag is not set, step 88 initializes a pointer PTR to ~n interrupted session table for the identiied user, ~uch a~ the ta~le shown in the RAM map of Figure 3. The centralized computer stores each session in memory, until the session ha~ been complet-ed. Thus, when a session for a user i5 not completed, for 80me rea~on, the central computer 31 already has the results of the session in memory and it makes an entry into the interrupted session table for the specific user. The table, which is a LIF0 table, includes a listing o each interrupted session for this user, by date and time-o-day.
Function 90 then checks pointer PTR to determine if there is an interrupted session for this user. Function 90 then also give~ the user the opportunity of reestablishing any ' ~ .
.
lZ~ 83 11 52,553 such session, stepping through the interrupted sessions, when there is more than one, starting from the most recen'.
Function 90 also gives the user the opportunity of starting from where the prior session ended, and the opportunity to review the session, including the chance to change prior evidence which was input during the session before it was interrupted.
The interrupted session routine at block 90 then proceeds to a symptom select routine in block 92. If this is not an interrupted session, function 92 displays a menu of elevator malfunction symptoms for the user to make a selection. An expansion of the user selection, through appropriate sub-menus, may also be made after the initial selection, if more specific information is required by the expert system.
Function 94 then performs an interactive ~ession with the user, in which the expert system asks the user for ~pecific information or evidence, as required by the evidence-hypothesis format of the knowledge based rules, until a possible cause of the malfunction symptom is identified. The expert system will display the possible cause, the confidence factor in the belief that this is the cause, as well as a suggested corrective action. If the information provided by the expert system does not solve the problem, the session continues until either the problem i ~olved or the user decides to terminate the session. If tho u~er decides to terminate the session, a session close routino, shown in blocX 96, is performed. During the functlon of block 96, information is provided by the user to the central computer on the success of the session and this function gives the user the opportunity to input information relative to the actual cause of the problem, and the trouble-shooting steps utilized to solve the ; problem, when the session was not successful. This infor-mation is then used by a knowledge engineer to update the system menu and rule base.
~' , ~
' ,~ -12 52,553 Step 98 then clears the current session from memory, since, upon reaching this point, the session has been completed. The entry into the interrupted session table for this particular user will also be purged.
step 100 checks to see if the session which has just been completed had been previously interrupted, such as by checking a flag "interrupted session". Such a flag may be set when the session is the completion of an inter-rupted session. If the interrupted session flag is set, then there may be other interrupted sessions that this same user may which to resume, so the program returns to func-tion 90. If the interrupted service flag is not set, the program returns to step 92 to give the user the opportunity to input a symptom of still another problem, or to give the user the opportunity to terminate the session. The program continues as hereinbefore described, until the user selects "exit", which is included with the list of symptoms in the symptom menu of function 92.
Figure 5 is a flow chart which may be used to implement the session initiate function 82 shown in Figure 4. Routine 82 is entered at input 80, the same as shown in Figure 4, and step 102 merely requires that the user insert the application disc into the terminal 60 and turn on the electrical power. Step 104, which is performed by the terminal 60, automatically dials the central computer 31.
Step 106, performed by terminal 60, checks to see if a connection has been made with the central computer. If not, the program continually loops through step 106, until either a user initiated communication link is established with the central computer, or the user desires to terminate the attempt to establish the communication link.
If step 106 finds that a connection has been made with the central computer, step 108 performs an automatic log-in function, which includes the terminal sending an account name and a password. The account name identifies that the user wishes to access the expert system for elevator trouble-shooting. The account name is necessary i2S;~983 13 52,553 when a large computer is involved, which may have many different application programs to run. The password is built into the disc, and identifies the disc as an authen-tic disc for establishing a communication link with the central computer.
Step 110 then requires the user to key in a personal code or password, known only to him. For example, the personal password may be the user's Social Security Number. Upon receipt of the personal password, the central compu~er, in step 112, checks to see if this password is associated with an authorized user. If it is not, step 114 records the number entered and increments a counter, such as the software counter shown in the RAM map of Figure 2.
Step 116 checks to see if the count has reached a predeter-mined value, such as three. If it has not reached thepredetermined count value, the program returns to qtep 110 in order to give the user the opportunity of entering a correct personal code. If the count of such attempts reaches the predetermined value, step 116 branches to step 118 which resets the counter and disconnects the communi-cation link. The record of incorrect numbers stored in step 114 is available for use by authorized personnel, should they desire to investigate the unsuccessful attempt to utilize the expert system.
When step 112 finds that the personal code is an authorized code, the central computer then resets the counter and advances to a portion of the program concerned with a code previously assigned to the building. The contral computer asks the user to enter the building code, and step 120 indicates the entering of the building code by the user. Step 121 checks to see if this code is an authorized code. If it is not an authorized code, step 122 records the building code actually entered and the counter shown in the RAM map of Figure 2 is incremented. Step 124 checks to see how many unsuccessful attempts at enteringthe building code have been made, and if the number reaches a predetermined value, such as three, the computer, in step ''" ' .
.
`:
~ .
14 52,553 126, resets the counter and disconnects the communica~ion link with the accessing terminal. If step 124 finds that the maximum number of attempts has not been reached, the program returns to step 120, to enable the user to enter S the proper building code.
If step 121 finds that the authorized building code has been entered, step 128 resets the counter and disconnects the user initiated communication link. The central computer then accesses a look-up table, using the building code, to obtain the telephone number of the machine room associated with the identified building. Step 130 also includes the function of dialing the telephone number found in the look-up table. Step 132 checks to see if a connection has been made, and if it finds that no connection has been made, step 133 checks to see if a predetermined period of time has expired since step 130 dialed the telephone number. Step 130, for example, may start a software timer, such as the timer shown in the RAM
map of Figure 2. The program loops through steps 132 and 133 until step 133 finds that the time has expired, which results in the computer setting the "no-connect" flag, as indicated in 134, or until step 132 finds that a connection has been made. When step 132 finds that a connection has been made, the program advances to step 84 at terminal 136.
As shown in Figure 4, step 8~ checks the "no-connect" 1ag shown in the RAM map o Figure 2, and if this flag was set in step 134 of Figure S, the computer ends the attempted session at 86. If step 84 shown in Figure 4 finds that the "no-connect" f~ag has not been set, step 88 inltlallzes the pointer PTR to the interrupted session table for the specific identified user, and the program advances to function 90.
Figure 6 is a flow chart which may be used to implement function 90, which is entitled "interrupted session routine". This routine is entered at 140 and step 142 checks to see if there are any interrupted sessions for the identified user. This is determined simply by checking , . . .
~ ~ , ,, ::
~:
' -lZ~39~
52,553 the pointer PTR to the user's interrupted session table.
If there is no entry at the initialized position of pointer PTR, there are no interrupted sessions and the program advances to step 166, which resets the interrupted session flag shown in the RAM map of Figure 2, and the routine exits at 168, which proceeds to function 92.
When step 142 finds an entry at the location of the pointer PTR, there is at least one interrupted session and the central computer displays the date and time of the interrupted session on the display of the user terminal 60.
This is indicated in block 144 of Figure 6. The central computer then asks the user, in block 146, if he wishes to resume the interrupted session displayed. If the user wishes to resume this session he indicates the desire by an appropriate entry on the keyboard 62, and the central computer, in block 148 reads the session data of the interrupted session into the current session memory. The central computer then asks the user iX he wants to review what has occurred in the interrupted session, as indicated in block 150. If the user wishes to review this informa-tion, such as to refresh his memory or to give him the opportunity of changing prior entries such as due to errors or due to the age of the data, the user indicates an affirmative answer on the keyboard 62. The central comput-er then set~ a review flag, shown in the RAM map of Figure2, as indicated in step 152. The review flag will be checked in a sensor check routine shown in Figure 10, which will be hereinafter described.
If step 150 finds the user does not wish to review the interrupted session, step 154 resets the review flag and step 156 sets an interrupted session flag, shown in Figure 2, in order to let subsequent routines Xnown that this session is the continuation of an interrupted session.
After the interrupted session flag is set in step 156, the program advances to function 92, as indicated at terminal 168.
:
.
~2S3983 16 52,553 Should step 146 find that the user does not wish to resume the interrupted session displayed, step 158 asks the user if he wishes to save the interrupted session displayed. If the user gives a negative reply, step 160 deletes that specific session from the memory. If step 158 finds the user wishes to save the displayed interrupted session, step 162 increments the pointer PTR to the inter-rupted session table. Step 164 then checks to see if there are any more interrupted sessions. If there are, estab-lished by the pointer PTR pointing to a non-zero entry, the program returns to step 144. If step 164 finds there are no more interrupted sessions, step 166 resets the inter-rupted session flag to indicate that the current session is not the continuation of an interrupted ~ession. The program then advances to function 92, as indicated at terminal 168.
A flow chart which implements the symptom select routine of function 92 is set forth in Figure 7. This routine is entered at terminal 170 and step 172 checks to see if the interrupted session 1ag is set. If it is set, indicating the current session ic the continuation of an interrupted session, step 174 reads the malunction symptom which was previously selected and stored in memory. Step 175 loads the. context of the selected symptom. Step 176 then asks the user if he has a hand held terminal 66. If he does, step 178 sets flag HHT, shown in the RAM map of Eigure 2, to indicate that the user has a hand held termi-nal, and the program advances to function 94 from exit terminal 180. If step 176 finds that the user does not hav- a hand-held terminal, step 178 is bypassed, with the routine exiting at terminal 180.
If step 172 finds that the interrupted session flag is not set, indicating that the current session is not the continuation of an interrupted session, ~tep 182 retrieves the main malfunction symptom menu from memory, and step 184 displays the symptom menu for the user on display 64. Table I sets forth an exemplary main menu.
.
. ~ :
~ .
~2S3983 17 52,553 The user makes a selection, indicated at step 186, and the central computer checks the selection to see if a sub-menu is required, in step 188. Some symptoms displayed in the main menu may be broad cateqories of malfunction symptoms, requiring a more detailed selection. When a sub-menu is required, step 190 obtains the appropriate sub-menu, and returns to step 184 to display the menu just obtained.
TABLE I
SYMPTOMS
1. Hand held terminal will not log on 2, Car will not run and car is at floor level 3. Car will not run and car i8 not at floor level 4. Car dynamic~
5. Car calls 6. Corridor calls 7. System processor not runni.ng 8. Car on block operation 9. Other message
10. Log of last ses~ion
11. Exit When step 188 finds that all menu requirements have been sati3fied, step 192 checks to see if the user selected "EXIT" from the menu. As will be hereinafter described, this is the normal way for the user to terminate a session. If the user had ~elected "EXIT" from the menu, the central computer disconnects the communication link, indicated at 194.
If step 192 finds that the user does not wish to terminate the session, step 196 checks to see if the user selected "log display". If the user selected "log dis-!
"
' ' .
~253983 18 52,553 play", the log of the last completed session is scrolled on the user's dispiay 64, as indicated in block 198. Block 198 then returns to step 182.
If step 196 finds that the user did not select "log display", step 200 checks to see if the user selected "other". The user selects "other", when the malfunction symptom he has identified in the elevator system is not shown in the menu. When "other" is selected by the user, step 202 calls a text entry sub-routine shown in Figure 9.
The text entry sub-routine provides the user with the opportunity of inputting a malfunction symptom, a descrip-tion of the symptom, the cause of the symptom and the trouble-shooting steps which the user utilized in order to solve the problem. This subroutine will be described in detail when Figure 9 is described. When the text entry subroutine returns to step 202, the program returns to step 182.
When step 200 finds that the ~lser has not select-ed "other", the program advances to step 175, previously deccribed, to load the context of the selected symptom.
The symptom select routine 92 then checks for the hand-held terminal in steps 176 and 178 and terminates at terminal 180, advancing to function 94.
A flow chart implementing function 94, which is Z5 entitled "interactive session routine", is set forth in Figures 8A and 8B. This routine is entered at terminal 204, and step 205 checks the interrupted session flag to dotermine if the present session is the continuation of an interrupted session. If it is not an interrupted session, step 206 initializes the inference engine 30 shown in Figure l. If the interrupted session flag is found to be set in step 205, step 207 determines if the session was interrupted during the entry of text by the user. If the session was interrupted at the text entry stage, it is not necessary to run the interactive session routine, and the program exits at 208. If the session was not interrupted during text entry, step 207 proceeds to step 206, which ~ 12S398~
19 52,553 initializes the inference engine. Step 209 then runs the inference engine 30 shown in Figure 1, in order to select a rule from the domain dependent rule base 28. Step 210 checks to see if the inference engine is able to suggest a cause of the symptom selected from the symptom menu in the symptom select routine. If the inference engine is not able to suggest a cause, the program, in step 214, makes sure it has not reached a point where it has run out of rules to fire. If there are rules to fire, a subroutine "sensor check" shown in Figure lO is called. This sub-routine provides the answer for step 216 which checks the results of the subroutine to see if sensor information is required from the user. For example, when the inference engine selects a rule, the rule will be in evidence-hypothesis form, and it probably will not have the evidence required by the rule. Thus, step 210 will usually advance to ~tep 216 in the initial stages of the interactive session with "yes" as the answer. If step 214 finds there are no more rules to fire, it proceeds to exit 208.
Referring to Figure 10, the subroutine "sensor check" starts at terminal 218 and step 219 checks to see if the reading or sensor information required is already in the memory of the central computer. If it is not, informa-tion is required from the user, and the program proceeds to step 227. If step 219 finds that the reading is already in memory, step 220 checks to see that this information was read in from an interrupted session memory. If it was read in from an interrupted ~ession memory, step 221 checks to see if the review flag ha~ been ~et. It will ~e recalled that tho review flag is set in step 152 of Figure 6, when the user wishes to review an interrupted session. If step 221 finds that the review flag is not set, the program advances to ~lock 226 which prepares a "no" answer to the ~question "is sensor information required from the user,"
and the subroutine returns to step 216 in Figure 8A from exit 231. If step 221 finds that the review flag is set, step 221 advances to block 230 which prepares a "yes"
;
lZS3983 52,553 answer to the question posed in step 216, and the subrou-tine returns to step 216 at 231.
If step 220 finds that the information was not read in from an interrupted session memory, step 222 checks to see if the information is from a buffered sensor. It will be recalled that information provided by the hand-held terminal is referred to as information from a buffered sensor. If the information is not from a buffered sensor, the program goes to the "no" block 226. If the information is from a buffered sensor, step 223 computes the time since the reading was entered. When a reading from the buffered sensor is stored, the date and time of day is also stored, so that step 223 can compute the elapsed tim~ since the reading was entered. Step 224 compares the age of the reading with a predetermined value T-MAX. A typical value i~ 30 minute8, for example. If the reading is not older than T-MAX the program returns to the "no" block 226. If the information is older than T-MAX, step 225 asks the user if he wishec to update the reading. If the reply is in the affirmative, the program goes to step 227, and if he replies in the negative, the program goes to the "no" block 226.
Step 227 checks the HHT flag to determine the terms which should be used to describe the required sensor.
If flag HHT i~ set, step 228 obtains the code which when input to the hand-held terminal 66 will provide the re-quired data. If flag HHT is not set, step 229 obtains the de~cription of the single sensor involved. Step 228 and 229 both proceed to the "yes" block 230.
Returning to Figure 8A, when step 216 finds that sensor information is required from the user, step 246 in Figure 8B displays the description of the required sensor information, which was obtained in step 228 or step 229 of Figure 10. Steps 247 and 248 cooperate to display the previous answer as a default, when step 247 finds the "review" flag set. If step 228 obtained the description, step 246 displays the code which the user should enter into ~2S3983 , 21 52,553 the hand-held terminal 66 in order to obtain the proper signal or sensor information. The user then enters this code into the hand-held terminal 66, and upon obtaining the two-digit hex number, the user enters the two-digit hex 5 nurnber into the keyboard 62, as indicated at 249. The central computer stores the time of day that this informa-tion was input into the system, and step 249 advances to a step 250.
If step 229 of Figure 10 obtained the sensor 10 description, the central computer provides a detailed description of the required sensor information in step 246, and it will also list a default value, if one is available, as determined by steps 247 and 248. The user either actuates "return", i the deault value is correct, or he 15 enters the reguired sensor reading, as indicated in step 249. Step 249 then advances to step 250.
In step 250, the computer checks to see if the user wishes to correct an error in the entry of the infor-mation. When the user makes a mista~ee in the entry, he 20 actuates a control input "E", and step 252 cal}s an error correction sub-routine shown in Figure 11. If step 250 inds that control "E" has not been entered by the user, step 254 checks the sensor reading which has been entered to see i it is in an allowable range for this sensor. I
25 it is, the program has the inormation it requires and it returns to step 207 to run the inerence engine. Should stop 254 flnd that the reading i8 not in an allowed range for tho sensor in question, the computer transmits an error mea~age to the user, indicated in step 256, and the program 30 returns to step 238. The user now has an opportunity to enter another reading, in an attempt to obtain correct information.
Figure 11 is a flow chart of an error correction sub-routine which may be used to implement block 252 shown 35 in Figure 8B. The error correction sub-routine is entered at terminal 258 and the central computer steps back through the reguested sensor information and the input data, - . :
' ' ::
_ lZS3983 22 52,553 starting with the most recent question and associated data received. Thus, step 260 describes the next previous sensor information requested, and step 260 displays the requested sensor reading provided by the user. If the reading is correct, the user hits the return key and the original value, which is the default value, is retained.
If the value shown in step 262 is not correct, instead of hitting return, the user enters the correct value. Step 264 then checks to see if the user has again actuated control "E". Actuating key "E" while in the error correc-tion subroutine, will break the program out of the correc-tion loop, and step 268 reinitializes the inference engine.
If step 264 finds that the control key "E" has not been actuated, step 266 determines if all of the sensors have been rechecked. If they have not, step 266 returns to 260 to display the next previous sensor information. When step 266 finds that all sensors have been rechecked, the program advances to step 268 which reinitializes the inference engine, The error correction subroutine then returns to step 252, at terminal 270.
The interactive session routine shown in Figures 8A and 8B then continues, with the inference engine select-ing rule after rule in order to traverse the rule network to propagate belief until a suggested cause of the mal-function is isolated. Each time a suggested cause is set forth in step 210, the user checks to see if this solves the problem, and he indicates whether or not he wishes to continue in step 212. If the problem has not been solved, step 212 will return to step 209. When the problem is solved, the user indicates that he does not wish to con-tinue in step 212, and the interactive session routine advances to function 96 in Figure 4, as indicated at terminal 20~.
Function 96, entitled "Session Close Routine", is set forth in detail in a flowchart in Fig. 9. This routine is entered at terminal 272, and step 274 asks the user if the session was successful. If the user indicates an --- i2S~983 23 52,553 affirmative answer, step 276 asks the user to enter com-ments on the session. Step 278 indicates the entry of the user's comments, and when the user completes his comments, a control key is actuated, to indicate completion of the ments, and the program advances to step 98 in Fig. 4, as indicated at exit terminal 280.
When step 274 is answered in the negative, the subroutine "text entry" is entered. This subroutine was mentioned in connection with step 202 of Figure 7. The first step of the subroutir.e, indicated at 282, asks the user to describe the symptom. Steps 283 and 284 indicate that the original inp ~a is also displayed as a default value when the review - ~ is set. Step 286 indicates the text entry of the symptom, and the user actuates a control key when the description has been completed. The program then asks the user the cause of the symptom, displaying the original input as a default value when the review flat is set, as indicated at steps 288, 289 and 290. The user then types in the cause o the problem, indicated at 292, and actuate~ a control key when the cause of the problem has been completely entered. The computer then asks the user, in step 294, to describe the trouble-shooting steps which he utilized to solve the problem. Steps 295 and 296 indicate that the original inputs are displayed when the review flag is set. The user then enters the trouble-shooting steps taken, indicated at 298, and actuates the appropriate control key to signal the end of the text entry. The subroutine ends after step 298, and returns to step 202 of Figure 7, i the subroutine was called by the symptom select routine of Figure 7. Otherwise, step 298 goes to step 276, hereinbefore described. When the session close routine terminates at exit terminal 280, the program advances to step 98 shown in Figure 4, which clears the current session from the interrupted session memory, since ~; 35~ this session has been completed, and step 100 returns the ~program to step 90 or step 92, according to the condition of the interrupted session flag, as hereinbefore described.
.
~, , . ~ '.
24 52,553 When the program of Figure 4 reaches the symptom select routine of Figure 7, and the user selects "EXIT" from the symptom menu, the session is ended at the disconnect indicated at 194 in Figure 7.
In summary, there has been disclosed new and improved methods of integrating an expert system having a knowledge base of elevator trouble-shooting rules, into the working environment of the average elevator service techni-cian. The method enables any number of previously author-ized elevator service technicians to directly access the expert system from the location of the elevator system being serviced, and the expert system will provide a guided path for the technician which is easily followed without extensive prior training of the technician. Further, such direct access of the expert system is only permitted after a review procedure which screens unauthorized users from the system. Finally, the methods provide information for a knowledge engineer which enables the expert system to be constantly improved, by more accurately diagnosing malfunction symptoms, and by adding new symptoms to the menu, along with appropriate new rules, as new symptoms are encountered.
.
- :
If step 192 finds that the user does not wish to terminate the session, step 196 checks to see if the user selected "log display". If the user selected "log dis-!
"
' ' .
~253983 18 52,553 play", the log of the last completed session is scrolled on the user's dispiay 64, as indicated in block 198. Block 198 then returns to step 182.
If step 196 finds that the user did not select "log display", step 200 checks to see if the user selected "other". The user selects "other", when the malfunction symptom he has identified in the elevator system is not shown in the menu. When "other" is selected by the user, step 202 calls a text entry sub-routine shown in Figure 9.
The text entry sub-routine provides the user with the opportunity of inputting a malfunction symptom, a descrip-tion of the symptom, the cause of the symptom and the trouble-shooting steps which the user utilized in order to solve the problem. This subroutine will be described in detail when Figure 9 is described. When the text entry subroutine returns to step 202, the program returns to step 182.
When step 200 finds that the ~lser has not select-ed "other", the program advances to step 175, previously deccribed, to load the context of the selected symptom.
The symptom select routine 92 then checks for the hand-held terminal in steps 176 and 178 and terminates at terminal 180, advancing to function 94.
A flow chart implementing function 94, which is Z5 entitled "interactive session routine", is set forth in Figures 8A and 8B. This routine is entered at terminal 204, and step 205 checks the interrupted session flag to dotermine if the present session is the continuation of an interrupted session. If it is not an interrupted session, step 206 initializes the inference engine 30 shown in Figure l. If the interrupted session flag is found to be set in step 205, step 207 determines if the session was interrupted during the entry of text by the user. If the session was interrupted at the text entry stage, it is not necessary to run the interactive session routine, and the program exits at 208. If the session was not interrupted during text entry, step 207 proceeds to step 206, which ~ 12S398~
19 52,553 initializes the inference engine. Step 209 then runs the inference engine 30 shown in Figure 1, in order to select a rule from the domain dependent rule base 28. Step 210 checks to see if the inference engine is able to suggest a cause of the symptom selected from the symptom menu in the symptom select routine. If the inference engine is not able to suggest a cause, the program, in step 214, makes sure it has not reached a point where it has run out of rules to fire. If there are rules to fire, a subroutine "sensor check" shown in Figure lO is called. This sub-routine provides the answer for step 216 which checks the results of the subroutine to see if sensor information is required from the user. For example, when the inference engine selects a rule, the rule will be in evidence-hypothesis form, and it probably will not have the evidence required by the rule. Thus, step 210 will usually advance to ~tep 216 in the initial stages of the interactive session with "yes" as the answer. If step 214 finds there are no more rules to fire, it proceeds to exit 208.
Referring to Figure 10, the subroutine "sensor check" starts at terminal 218 and step 219 checks to see if the reading or sensor information required is already in the memory of the central computer. If it is not, informa-tion is required from the user, and the program proceeds to step 227. If step 219 finds that the reading is already in memory, step 220 checks to see that this information was read in from an interrupted session memory. If it was read in from an interrupted ~ession memory, step 221 checks to see if the review flag ha~ been ~et. It will ~e recalled that tho review flag is set in step 152 of Figure 6, when the user wishes to review an interrupted session. If step 221 finds that the review flag is not set, the program advances to ~lock 226 which prepares a "no" answer to the ~question "is sensor information required from the user,"
and the subroutine returns to step 216 in Figure 8A from exit 231. If step 221 finds that the review flag is set, step 221 advances to block 230 which prepares a "yes"
;
lZS3983 52,553 answer to the question posed in step 216, and the subrou-tine returns to step 216 at 231.
If step 220 finds that the information was not read in from an interrupted session memory, step 222 checks to see if the information is from a buffered sensor. It will be recalled that information provided by the hand-held terminal is referred to as information from a buffered sensor. If the information is not from a buffered sensor, the program goes to the "no" block 226. If the information is from a buffered sensor, step 223 computes the time since the reading was entered. When a reading from the buffered sensor is stored, the date and time of day is also stored, so that step 223 can compute the elapsed tim~ since the reading was entered. Step 224 compares the age of the reading with a predetermined value T-MAX. A typical value i~ 30 minute8, for example. If the reading is not older than T-MAX the program returns to the "no" block 226. If the information is older than T-MAX, step 225 asks the user if he wishec to update the reading. If the reply is in the affirmative, the program goes to step 227, and if he replies in the negative, the program goes to the "no" block 226.
Step 227 checks the HHT flag to determine the terms which should be used to describe the required sensor.
If flag HHT i~ set, step 228 obtains the code which when input to the hand-held terminal 66 will provide the re-quired data. If flag HHT is not set, step 229 obtains the de~cription of the single sensor involved. Step 228 and 229 both proceed to the "yes" block 230.
Returning to Figure 8A, when step 216 finds that sensor information is required from the user, step 246 in Figure 8B displays the description of the required sensor information, which was obtained in step 228 or step 229 of Figure 10. Steps 247 and 248 cooperate to display the previous answer as a default, when step 247 finds the "review" flag set. If step 228 obtained the description, step 246 displays the code which the user should enter into ~2S3983 , 21 52,553 the hand-held terminal 66 in order to obtain the proper signal or sensor information. The user then enters this code into the hand-held terminal 66, and upon obtaining the two-digit hex number, the user enters the two-digit hex 5 nurnber into the keyboard 62, as indicated at 249. The central computer stores the time of day that this informa-tion was input into the system, and step 249 advances to a step 250.
If step 229 of Figure 10 obtained the sensor 10 description, the central computer provides a detailed description of the required sensor information in step 246, and it will also list a default value, if one is available, as determined by steps 247 and 248. The user either actuates "return", i the deault value is correct, or he 15 enters the reguired sensor reading, as indicated in step 249. Step 249 then advances to step 250.
In step 250, the computer checks to see if the user wishes to correct an error in the entry of the infor-mation. When the user makes a mista~ee in the entry, he 20 actuates a control input "E", and step 252 cal}s an error correction sub-routine shown in Figure 11. If step 250 inds that control "E" has not been entered by the user, step 254 checks the sensor reading which has been entered to see i it is in an allowable range for this sensor. I
25 it is, the program has the inormation it requires and it returns to step 207 to run the inerence engine. Should stop 254 flnd that the reading i8 not in an allowed range for tho sensor in question, the computer transmits an error mea~age to the user, indicated in step 256, and the program 30 returns to step 238. The user now has an opportunity to enter another reading, in an attempt to obtain correct information.
Figure 11 is a flow chart of an error correction sub-routine which may be used to implement block 252 shown 35 in Figure 8B. The error correction sub-routine is entered at terminal 258 and the central computer steps back through the reguested sensor information and the input data, - . :
' ' ::
_ lZS3983 22 52,553 starting with the most recent question and associated data received. Thus, step 260 describes the next previous sensor information requested, and step 260 displays the requested sensor reading provided by the user. If the reading is correct, the user hits the return key and the original value, which is the default value, is retained.
If the value shown in step 262 is not correct, instead of hitting return, the user enters the correct value. Step 264 then checks to see if the user has again actuated control "E". Actuating key "E" while in the error correc-tion subroutine, will break the program out of the correc-tion loop, and step 268 reinitializes the inference engine.
If step 264 finds that the control key "E" has not been actuated, step 266 determines if all of the sensors have been rechecked. If they have not, step 266 returns to 260 to display the next previous sensor information. When step 266 finds that all sensors have been rechecked, the program advances to step 268 which reinitializes the inference engine, The error correction subroutine then returns to step 252, at terminal 270.
The interactive session routine shown in Figures 8A and 8B then continues, with the inference engine select-ing rule after rule in order to traverse the rule network to propagate belief until a suggested cause of the mal-function is isolated. Each time a suggested cause is set forth in step 210, the user checks to see if this solves the problem, and he indicates whether or not he wishes to continue in step 212. If the problem has not been solved, step 212 will return to step 209. When the problem is solved, the user indicates that he does not wish to con-tinue in step 212, and the interactive session routine advances to function 96 in Figure 4, as indicated at terminal 20~.
Function 96, entitled "Session Close Routine", is set forth in detail in a flowchart in Fig. 9. This routine is entered at terminal 272, and step 274 asks the user if the session was successful. If the user indicates an --- i2S~983 23 52,553 affirmative answer, step 276 asks the user to enter com-ments on the session. Step 278 indicates the entry of the user's comments, and when the user completes his comments, a control key is actuated, to indicate completion of the ments, and the program advances to step 98 in Fig. 4, as indicated at exit terminal 280.
When step 274 is answered in the negative, the subroutine "text entry" is entered. This subroutine was mentioned in connection with step 202 of Figure 7. The first step of the subroutir.e, indicated at 282, asks the user to describe the symptom. Steps 283 and 284 indicate that the original inp ~a is also displayed as a default value when the review - ~ is set. Step 286 indicates the text entry of the symptom, and the user actuates a control key when the description has been completed. The program then asks the user the cause of the symptom, displaying the original input as a default value when the review flat is set, as indicated at steps 288, 289 and 290. The user then types in the cause o the problem, indicated at 292, and actuate~ a control key when the cause of the problem has been completely entered. The computer then asks the user, in step 294, to describe the trouble-shooting steps which he utilized to solve the problem. Steps 295 and 296 indicate that the original inputs are displayed when the review flag is set. The user then enters the trouble-shooting steps taken, indicated at 298, and actuates the appropriate control key to signal the end of the text entry. The subroutine ends after step 298, and returns to step 202 of Figure 7, i the subroutine was called by the symptom select routine of Figure 7. Otherwise, step 298 goes to step 276, hereinbefore described. When the session close routine terminates at exit terminal 280, the program advances to step 98 shown in Figure 4, which clears the current session from the interrupted session memory, since ~; 35~ this session has been completed, and step 100 returns the ~program to step 90 or step 92, according to the condition of the interrupted session flag, as hereinbefore described.
.
~, , . ~ '.
24 52,553 When the program of Figure 4 reaches the symptom select routine of Figure 7, and the user selects "EXIT" from the symptom menu, the session is ended at the disconnect indicated at 194 in Figure 7.
In summary, there has been disclosed new and improved methods of integrating an expert system having a knowledge base of elevator trouble-shooting rules, into the working environment of the average elevator service techni-cian. The method enables any number of previously author-ized elevator service technicians to directly access the expert system from the location of the elevator system being serviced, and the expert system will provide a guided path for the technician which is easily followed without extensive prior training of the technician. Further, such direct access of the expert system is only permitted after a review procedure which screens unauthorized users from the system. Finally, the methods provide information for a knowledge engineer which enables the expert system to be constantly improved, by more accurately diagnosing malfunction symptoms, and by adding new symptoms to the menu, along with appropriate new rules, as new symptoms are encountered.
.
- :
Claims (7)
1. A method in which an expert system having a knowledge base of elevator trouble-shooting information may be used interactively, as a consultant, by any number of remotely located elevator service personnel without requiring special training in the use of expert systems, and without compromising the security of the knowledge base, comprising the steps of:
providing a knowledge base of elevator trouble-shooting information, including a rule network having rules in evidence-hypothesis format, enabling contact to be made with said knowledge base from any number of remote elevator system locations via communication means, limiting access to said knowledge base to authorized users, establishing a communication link between an author-ized user located at a remote elevator system and the knowledge base via the communication means, initiating an interactive exchange session between the user and knowledge base via the communication link, said interactive session including the steps of:
displaying an elevator system malfunction menu, selecting a symptom from the menu, and running an inference engine using the selected symptom to traverse the rule net-work, asking the user to provide evidence unavailable to the knowledge base which is required to propagate belief through the rule network in an effort to determine a probable cause of the selected symptom, said asking step including the step of providing the user with a specific code related to the evidence required by the knowledge base, accessing the elevator system for evidence via a programmable terminal, said accessing step including the step of entering the specific code provided to the user by the knowledge base, said accessing step further including the step of obtaining a plurality of evidence bits from the elevator system in response to the coded entry, some of which may be immediately utilized by the knowledge base to propagate belief through the rule network and some of which may be subsequently utilized during subsequent belief propagations through the rule network, computing the age of each of such bit of evidence before it is used by the knowledge base, comparing the computed age with a predetermined value, and asking the user if the evidence should be up-dated when the age exceeds the predetermined value.
providing a knowledge base of elevator trouble-shooting information, including a rule network having rules in evidence-hypothesis format, enabling contact to be made with said knowledge base from any number of remote elevator system locations via communication means, limiting access to said knowledge base to authorized users, establishing a communication link between an author-ized user located at a remote elevator system and the knowledge base via the communication means, initiating an interactive exchange session between the user and knowledge base via the communication link, said interactive session including the steps of:
displaying an elevator system malfunction menu, selecting a symptom from the menu, and running an inference engine using the selected symptom to traverse the rule net-work, asking the user to provide evidence unavailable to the knowledge base which is required to propagate belief through the rule network in an effort to determine a probable cause of the selected symptom, said asking step including the step of providing the user with a specific code related to the evidence required by the knowledge base, accessing the elevator system for evidence via a programmable terminal, said accessing step including the step of entering the specific code provided to the user by the knowledge base, said accessing step further including the step of obtaining a plurality of evidence bits from the elevator system in response to the coded entry, some of which may be immediately utilized by the knowledge base to propagate belief through the rule network and some of which may be subsequently utilized during subsequent belief propagations through the rule network, computing the age of each of such bit of evidence before it is used by the knowledge base, comparing the computed age with a predetermined value, and asking the user if the evidence should be up-dated when the age exceeds the predetermined value.
2. The method of claim 1 including the step of outputting a probable cause of the selected symptom, the confidence level of the diagnosis, and suggested corrective action.
3. The method of claim 1 including the step of keeping a record of the interactive exchange session between the user and knowledge baser notwithstanding interrupted communications between the user and the knowledge base, en-abling the session to be reinitiated without the necessity of repeating prior steps associated with entry of evidence.
4. The method of claim 3 including the step of displaying the stored record for user review upon command by the user.
5. The method of claim 4 including the step of providing an opportunity for the user to change previously input evidence in the stored record.
6. The method of claim 3 including the step of keeping a record of interrupted sessions for each authorized user, stepping through the interrupted sessions for an identified user, when there is more than one, and providing an opportunity for the user to select an interrupted session to be resumed.
7. The method of claim 1 including the step of keeping a record of the interactive exchange session, initi-ating an error mode when the user wishes to change evidence previously input, stepping back through the previously input evidence in response to the user initiated user error mode, and enabling the user to change previously input evidence.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US06/758,984 US4697243A (en) | 1985-07-25 | 1985-07-25 | Methods of servicing an elevator system |
| US758,984 | 1996-12-02 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1253983A true CA1253983A (en) | 1989-05-09 |
Family
ID=25053926
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000514022A Expired CA1253983A (en) | 1985-07-25 | 1986-07-17 | Methods of servicing an elevator system |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US4697243A (en) |
| CA (1) | CA1253983A (en) |
Families Citing this family (93)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4852165A (en) * | 1987-06-12 | 1989-07-25 | National Computer Print, Inc. | Secure system and method for providing personal identifier |
| CA1331811C (en) * | 1987-10-13 | 1994-08-30 | Loren Stuart Minkus | Electronic display system |
| US5309174A (en) * | 1987-10-13 | 1994-05-03 | Motorola, Inc. | Electronic display system |
| US5006998A (en) * | 1987-11-05 | 1991-04-09 | Hitachi, Ltd. | Computer system with easy input means for consultation |
| JPH01226678A (en) * | 1988-03-04 | 1989-09-11 | Hitachi Ltd | Elevator controller |
| US5251285A (en) * | 1988-03-25 | 1993-10-05 | Hitachi, Ltd. | Method and system for process control with complex inference mechanism using qualitative and quantitative reasoning |
| JP2635087B2 (en) * | 1988-03-25 | 1997-07-30 | 株式会社日立製作所 | Process control method |
| GB8808446D0 (en) * | 1988-04-11 | 1988-05-11 | Macmillan Intek Ltd | Training/servicing kit |
| US4985857A (en) * | 1988-08-19 | 1991-01-15 | General Motors Corporation | Method and apparatus for diagnosing machines |
| US5014220A (en) * | 1988-09-06 | 1991-05-07 | The Boeing Company | Reliability model generator |
| US4967337A (en) * | 1988-10-11 | 1990-10-30 | Texas Instruments Incorporated | Automated diagnostic system |
| FI89580C (en) * | 1988-10-25 | 1993-10-25 | Kone Oy | Method and apparatus for measuring and tuning a lift system |
| US4972453A (en) * | 1989-02-28 | 1990-11-20 | At&T Bell Laboratories | Autonomous expert system for directly maintaining remote telephone switching systems |
| US6614768B1 (en) | 1989-04-28 | 2003-09-02 | Broadcom Corporation | Enhanced mobility and address resolution in a wireless premises based network |
| JPH0737306B2 (en) * | 1989-05-18 | 1995-04-26 | 三菱電機株式会社 | Elevator remote control method |
| JP3224226B2 (en) * | 1989-09-22 | 2001-10-29 | 株式会社リコー | Fault diagnosis expert system |
| EP0442809B1 (en) * | 1990-02-15 | 1995-09-20 | Digital Equipment Corporation | Model-based reasoning system for network fault diagnosis |
| US5124908A (en) * | 1990-04-23 | 1992-06-23 | Ellis Corporation | User interactive expert machine controller |
| US6359872B1 (en) * | 1997-10-28 | 2002-03-19 | Intermec Ip Corp. | Wireless personal local area network |
| US6006100A (en) * | 1990-05-25 | 1999-12-21 | Norand Corporation | Multi-level, hierarchical radio-frequency communication system |
| US6749122B1 (en) * | 1990-05-25 | 2004-06-15 | Broadcom Corporation | Multi-level hierarchial radio-frequency system communication system |
| US6654378B1 (en) * | 1992-03-18 | 2003-11-25 | Broadcom Corp. | Transaction control system including portable data terminal and mobile customer service station |
| JP2534387B2 (en) * | 1990-09-21 | 1996-09-11 | 三田工業株式会社 | Self-diagnosis system for image forming apparatus |
| US5345046A (en) * | 1991-07-23 | 1994-09-06 | Otis Elevator Company | Voice communication for elevator |
| JPH05134719A (en) * | 1991-11-14 | 1993-06-01 | Nippondenso Co Ltd | Abnormality recovering system |
| JPH05274269A (en) * | 1991-11-18 | 1993-10-22 | Internatl Business Mach Corp <Ibm> | Method and system for verifying validity of access in computer system |
| US5714726A (en) * | 1992-12-22 | 1998-02-03 | Kone Oy | Method for performing an alarm call in an elevator system |
| FI111934B (en) * | 1992-12-22 | 2003-10-15 | Kone Corp | Remote control system in elevator devices |
| US5736694A (en) * | 1992-12-22 | 1998-04-07 | Kone Oy | Method for providing a phone alarm call in an elevator system |
| US5598511A (en) * | 1992-12-28 | 1997-01-28 | Intel Corporation | Method and apparatus for interpreting data and accessing on-line documentation in a computer system |
| US5450478A (en) * | 1992-12-28 | 1995-09-12 | Otis Elevator Company | Remotely programmable equipment monitoring telephone line protocol |
| JP3202396B2 (en) * | 1993-03-26 | 2001-08-27 | 株式会社日立ビルシステム | Elevator abnormality analysis data collection device |
| JPH0772767A (en) * | 1993-06-15 | 1995-03-17 | Xerox Corp | Interactive user support system |
| JP3226400B2 (en) * | 1993-12-06 | 2001-11-05 | 富士通株式会社 | Diagnostic device |
| US7885242B2 (en) | 1993-12-23 | 2011-02-08 | Broadcom Corp. | Enhanced mobility and address resolution in a wireless premises based network |
| US5600726A (en) * | 1995-04-07 | 1997-02-04 | Gemini Systems, L.L.C. | Method for creating specific purpose rule-based n-bit virtual machines |
| US5822743A (en) * | 1997-04-08 | 1998-10-13 | 1215627 Ontario Inc. | Knowledge-based information retrieval system |
| US6215998B1 (en) * | 1997-12-11 | 2001-04-10 | Nortel Networks Limited | Local component-specific console |
| DE19800714A1 (en) * | 1998-01-09 | 1999-07-15 | Kone Oy | Method for maintenance of an elevator installation and elevator installation |
| US6728343B1 (en) | 1998-03-16 | 2004-04-27 | Conair Corporation | User appliance with voice help guide |
| US6026393A (en) * | 1998-03-31 | 2000-02-15 | Casebank Technologies Inc. | Configuration knowledge as an aid to case retrieval |
| US6529893B1 (en) | 1999-02-26 | 2003-03-04 | Mandel Foner | Expert diagnostic system with inference generator |
| US7783507B2 (en) * | 1999-08-23 | 2010-08-24 | General Electric Company | System and method for managing a fleet of remote assets |
| US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
| AU5558401A (en) | 2000-04-20 | 2001-11-07 | General Electric Company | Method and system for graphically identifying replacement parts for generally complex equipment |
| US6330936B1 (en) * | 2000-05-09 | 2001-12-18 | Otis Elevator Company | Elevator behavior reported in occurrence-related groups |
| IL137305A (en) * | 2000-07-13 | 2005-08-31 | Clicksoftware Technologies Ld | Method and system for sharing knowledge |
| US7171372B2 (en) * | 2000-08-07 | 2007-01-30 | General Electric Company | Computerized method and system for guiding service personnel to select a preferred work site for servicing transportation equipment |
| WO2002017273A2 (en) * | 2000-08-23 | 2002-02-28 | General Electric Company | Method for training service personnel to service selected equipment |
| MXPA02008345A (en) | 2000-12-29 | 2002-12-13 | Gen Electric | Method and system for identifying repeatedly malfunctioning equipment. |
| US20020138327A1 (en) * | 2001-03-26 | 2002-09-26 | Mello Celso Luis | System for remotely managing elevator mechanic service routine |
| US20020156692A1 (en) * | 2001-04-20 | 2002-10-24 | Squeglia Mark R. | Method and system for managing supply of replacement parts of a piece of equipment |
| US7054822B2 (en) * | 2001-08-06 | 2006-05-30 | Ecolab, Inc. | Notification of time-critical situations occurring at destination facilities |
| US7505914B2 (en) * | 2001-08-06 | 2009-03-17 | Ecolab Inc. | Method and system for providing advisory information to a field service provider |
| US7274932B1 (en) * | 2001-09-19 | 2007-09-25 | At&T Bls Intellectual Property, Inc. | Expert system for troubleshooting cellular site problems |
| US6715586B1 (en) | 2002-04-22 | 2004-04-06 | William A. Shubin | Upgraded elevator control circuit and method dealing with fire danger |
| ZA200307740B (en) * | 2002-10-29 | 2004-07-02 | Inventio Ag | Device and method for remote maintenance of a lift. |
| US6959263B2 (en) * | 2002-12-14 | 2005-10-25 | Perspicuous Insights Llc | Interactive diagnostic system and method driven by expert system |
| US20040236706A1 (en) * | 2003-04-30 | 2004-11-25 | Fitch James Chester | Automated machinery lubrication service and maintenance planning system |
| US7201290B2 (en) | 2003-05-12 | 2007-04-10 | Ecolab Inc. | Method and apparatus for mass based dispensing |
| US20040226959A1 (en) | 2003-05-12 | 2004-11-18 | Mehus Richard J. | Methods of dispensing |
| US20040230339A1 (en) * | 2003-05-12 | 2004-11-18 | Bryan Maser | Methods of managing based on measurements of actual use of product |
| CA2524772C (en) * | 2003-05-28 | 2012-03-06 | Inventio Ag | Method and device for the maintenance of a lift or escalator installation |
| US7004289B2 (en) * | 2003-09-30 | 2006-02-28 | Shrum Iii William M | Elevator performance measuring device and method |
| CN100475679C (en) * | 2004-03-01 | 2009-04-08 | 三菱电机株式会社 | Terminal for elevator surveillance and elevator monitoring device |
| EP1759170B2 (en) | 2004-06-23 | 2019-11-06 | Ecolab Inc. | Method for multiple dosage of liquid products, dosing appartus and dosing system |
| US7350626B2 (en) * | 2004-10-20 | 2008-04-01 | Otis Elevator Company | Power-on-reset of elevator controllers |
| ES2432370T3 (en) * | 2004-11-09 | 2013-12-03 | Inventio Ag | Procedure and device for maintaining an elevator installation or escalator installation |
| JP4980923B2 (en) * | 2004-11-30 | 2012-07-18 | オーチス エレベータ カンパニー | Multi-function destination entry passenger interface |
| US7803321B2 (en) | 2005-03-18 | 2010-09-28 | Ecolab Inc. | Formulating chemical solutions based on volumetric and weight based control measurements |
| US8069958B2 (en) * | 2005-07-18 | 2011-12-06 | Otis Elevator Company | Elevator system and method including a controller and remote elevator monitor for remotely performed and/or assisted restoration of elevator service |
| CN100575231C (en) * | 2006-01-24 | 2009-12-30 | 三菱电机株式会社 | The remote alarming system of elevator |
| CN101137166B (en) * | 2007-01-04 | 2010-12-08 | 中兴通讯股份有限公司 | On-site maintenance system of wireless network |
| US8277745B2 (en) | 2007-05-02 | 2012-10-02 | Ecolab Inc. | Interchangeable load cell assemblies |
| US7694589B2 (en) | 2007-12-12 | 2010-04-13 | Ecolab Inc. | Low and empty product detection using load cell and load cell bracket |
| JP2011516365A (en) * | 2008-04-08 | 2011-05-26 | オーチス エレベータ カンパニー | Remote observation analysis for elevator equipment |
| WO2010031426A1 (en) | 2008-09-16 | 2010-03-25 | Inventio Ag | Method for modernizing an elevator system |
| USRE48951E1 (en) | 2015-08-05 | 2022-03-01 | Ecolab Usa Inc. | Hand hygiene compliance monitoring |
| US9102509B2 (en) | 2009-09-25 | 2015-08-11 | Ecolab Inc. | Make-up dispense in a mass based dispensing system |
| US9051163B2 (en) | 2009-10-06 | 2015-06-09 | Ecolab Inc. | Automatic calibration of chemical product dispense systems |
| US8511512B2 (en) | 2010-01-07 | 2013-08-20 | Ecolab Usa Inc. | Impact load protection for mass-based product dispensers |
| FI122366B (en) * | 2010-11-09 | 2011-12-30 | Kone Corp | Equipment and system for servicing the lift |
| BR112013027228A2 (en) * | 2011-05-10 | 2017-08-08 | Otis Elevator Co | method for manipulating the remote control of an elevator system, and, elevator system |
| US9580276B2 (en) * | 2011-10-14 | 2017-02-28 | Otis Elevator Company | Elevator system with messaging for automated maintenance |
| US8944286B2 (en) | 2012-11-27 | 2015-02-03 | Ecolab Usa Inc. | Mass-based dispensing using optical displacement measurement |
| WO2015018741A1 (en) * | 2013-08-09 | 2015-02-12 | Inventio Ag | Communication method for a lift system |
| US10112801B2 (en) | 2014-08-05 | 2018-10-30 | Richard Laszlo Madarasz | Elevator inspection apparatus with separate computing device and sensors |
| US20180150806A1 (en) * | 2014-10-14 | 2018-05-31 | Xicore Inc. | Systems for Actively Monitoring Lift Devices and Maintaining Lift Devices, and Related Methods |
| EP3573915B1 (en) * | 2017-01-30 | 2021-12-15 | Inventio AG | Electronic elevator guard device and method for monitoring a set of integrity states of a plurality of elevator features |
| CN110383355B (en) | 2017-03-07 | 2021-08-27 | 埃科莱布美国股份有限公司 | Monitoring module for hand hygiene dispenser |
| US10547917B2 (en) | 2017-05-12 | 2020-01-28 | Otis Elevator Company | Ride quality mobile terminal device application |
| US10529219B2 (en) | 2017-11-10 | 2020-01-07 | Ecolab Usa Inc. | Hand hygiene compliance monitoring |
| EP3900307A1 (en) | 2018-12-20 | 2021-10-27 | Ecolab USA, Inc. | Adaptive route, bi-directional network communication |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3984637A (en) * | 1974-11-29 | 1976-10-05 | The Singer Company | Computer terminal security system |
| US3976840A (en) * | 1975-07-14 | 1976-08-24 | Spencer Cleveland | Portable securities selector system |
| US4106593A (en) * | 1977-03-17 | 1978-08-15 | Westinghouse Electric Corp. | Methods and tools for servicing an elevator system |
| US4154988A (en) * | 1977-10-21 | 1979-05-15 | Wescom Switching, Inc. | Method and means for accessing program memory of a common control telecommunications switching system |
| US4310720A (en) * | 1978-03-31 | 1982-01-12 | Pitney Bowes Inc. | Computer accessing system |
| JPS5511418A (en) * | 1978-07-07 | 1980-01-26 | Hitachi Ltd | Test operating apparatus of elevator |
| US4430728A (en) * | 1981-12-29 | 1984-02-07 | Marathon Oil Company | Computer terminal security system |
| US4520233A (en) * | 1982-04-16 | 1985-05-28 | Omnicom Engineering | Telephone line security apparatus |
| US4531023A (en) * | 1982-08-13 | 1985-07-23 | Hlf Corporation | Computer security system for a time shared computer accessed over telephone lines |
| US4561093A (en) * | 1983-02-22 | 1985-12-24 | Otis Elevator Company | Servicing a software-controlled elevator |
| US4568909A (en) * | 1983-12-19 | 1986-02-04 | United Technologies Corporation | Remote elevator monitoring system |
| US4593367A (en) * | 1984-01-16 | 1986-06-03 | Itt Corporation | Probabilistic learning element |
| US4512442A (en) * | 1984-03-30 | 1985-04-23 | Westinghouse Electric Corp. | Method and apparatus for improving the servicing of an elevator system |
| US4649515A (en) * | 1984-04-30 | 1987-03-10 | Westinghouse Electric Corp. | Methods and apparatus for system fault diagnosis and control |
| US4591983A (en) * | 1984-07-09 | 1986-05-27 | Teknowledge, Inc. | Hierarchical knowledge system |
-
1985
- 1985-07-25 US US06/758,984 patent/US4697243A/en not_active Expired - Fee Related
-
1986
- 1986-07-17 CA CA000514022A patent/CA1253983A/en not_active Expired
Also Published As
| Publication number | Publication date |
|---|---|
| US4697243A (en) | 1987-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1253983A (en) | Methods of servicing an elevator system | |
| US4284847A (en) | Audiometric testing, analyzing, and recording apparatus and method | |
| US4707804A (en) | Computer security system | |
| US4656319A (en) | Alarm system tester | |
| US7002468B2 (en) | Controlling access to a medical monitoring system | |
| US4425625A (en) | Diagnostic display terminal system | |
| EP0051861B1 (en) | Unmanned diagnostic communications system for computer controlled machine tools | |
| EP1484683A1 (en) | System for providing support for an electronic device | |
| JP2002060152A (en) | Remote control system for elevator, content server, and remote control method for elevator | |
| US4672574A (en) | Data communication system with terminal for displaying the coded stream of data being transmitted | |
| JPH04241563A (en) | Electric appliance fault diagnostic system | |
| JP2002132134A (en) | Learning method, learning system, learning management apparatus and recording medium | |
| RU2155374C2 (en) | Compatible user interface device | |
| CA1232968A (en) | Apparatus for interfacing with x21 equipment | |
| KR0165081B1 (en) | Management method of concentration working for remote exchanger | |
| JPH04299015A (en) | Device for detecting and locating fault of electric power system | |
| JPS6184936A (en) | Remote supervisory control system | |
| JPS58176742A (en) | Processing system of adjusted data for center transmission system | |
| JP2003137098A (en) | Field apparatus diagnosing device, field apparatus diagnosing system, and interlocking device | |
| DE19913573A1 (en) | Home security connection system for controlling multiple buildings has monitoring circuit and server connected via public telephone network to management system | |
| JPH05244230A (en) | Data transmission test equipment | |
| JPH11177704A (en) | Communication testing method of automatic meter inspecting device | |
| JPH02189616A (en) | Keyboard device | |
| CN116664061A (en) | System and method for managing equipment health under data loss | |
| JPS639707B2 (en) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKEX | Expiry |