WO1993018952A1

WO1993018952A1 - Real-time remote signal monitoring system

Info

Publication number: WO1993018952A1
Application number: PCT/US1993/002503
Authority: WO
Inventors: Henry J. Wesling; Michael R. Novakovich; Richard D. Roberts
Original assignee: Aeg Transportation Systems, Inc.
Priority date: 1992-03-18
Filing date: 1993-03-18
Publication date: 1993-09-30
Also published as: EP0631549A1

Abstract

In a multi-car train having a train-wide communications network for communication between a master vehicle processing system on a master car and slave vehicle processing systems on slave cars in the train, each car having a vehicle communications network connected to subsystems of the car, an arrangement for collecting real-time data pertaining to operation of the subsystems. The master vehicle processing system of the master car forms and transmits a subsystem variable request message to slave vehicle processing systems in one or more slave cars in the train over the trainwide communications network requesting data on the operation of at least one subsystem. The slave vehicle processing systems of the one or more slave cars in the train respond to the subsystem variable request message by forming and transmitting a subsystem variable response message containing the requested data on the operation of the at least one subsystem. A display device is operatively connected to the master vehicle processing system of the master car for displaying the requested subsystem operating variable status data.

Description

REAL-TIME REMOTE SIGNAL MONITORING SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following copending applications assigned to the same assignee as the present application which are hereby incorporated by reference: U.S. Patent application S.N. 07/686,927, entitled

"PROPULSION CONTROL SYSTEM CENTRAL PROCESSING UNIT BOARD" filed April 18th, 1991, by William F. Molyneaux;

S.N. 07/853,250, Attorney Docket No. AWA-0376, by

Michael R. Novakovich and Joseph S. Majewski, entitled "A METHOD AND APPARATUS FOR MONITORING AND SWITCHING OVER TO

A BACK-UP BUS IN A REDUNDANT TRAINLINE MONITOR SYSTEM" filed March 18th, 1992;

S.N. 07/853,420, Attorney Docket No. AWA-0377, by

Joseph S. Majewski, entitled "COLLISION HANDLING SYSTEM" filed March 18th, 1992;

S.N. 07/853,796, Attorney Docket No. AWA-0378, by

Michael R. Novakovich and Joseph S. Majewski, entitled "A

METHOD AND APPARATUS FOR CHRISTENING A TRAINLINE MONITOR

SYSTEM" filed March 18th, 1992; S.N. 07/853,540, Attorney Docket No. AWA-0379, by

Michael R. Novakovich and Richard D. Roberts, entitled "A

METHOD AND APPARATUS FOR LOAD SHEDDING USING A TRAINLINE

MONITOR SYSTEM" filed March.18th, 1992;

S.N. 07/853,960, Attorney Docket No. AWA-0380, by Michael R..Novakovich and Joseph S. Majewski, entitled

"MULTI-MASTER RESOLUTION OF A SERIAL BUS" filed March

18th, 1992;

S.N. 07/853,251, Attorney Docket No. AWA-0382, by

Michael R. Novakovich and Richard D. Roberts, entitled "A METHOD AND APPARATUS FOR PLACING A TRAINLINE MONITOR

SYSTEM IN A LAYUP MODE" filed March 18th, 1992; S.N. 07/853,205, Attorney Docket No. AWA-0385, by . Michael R. Novakovich, Richard D. Roberts and Henry J. Wesling, entitled "TRAIN DIAGNOSTIC AND STATUS .DISPLAY SYSTEM" filed March 18th, 1992; S.N. 07/853,402, Attorney Docket No. AWA-0391, by William F. Molyneaux, entitled "COMMUNICATIONS CONTROLLER CENTRAL PROCESSING UNIT BOARD" filed March 18th, 1992; S.N. 07/853.204. Attorney Docket No. AWA 0394, by Henry J.- Wesling, Michael R. Novakovich and Richard D. Roberts, entitled "DISTRIBUTED PTU INTERFACE" filed March 18th, 1992; and

S.N. 07/853,659, Attorney Docket No. AWA-0397, by Michael R. Novakovich and Joseph S. Majewski, entitled "A METHOD AND APPARATUS FOR TRANSMITTING PROPULSION AND BRAKING COMMANDS FOR A TRAIN" filed March 18th, 1992.

BACKGROUND OF THE INVENTION

1. Field of The Invention

The present invention relates to the field of real- time testing and in particular to strip chart recording of train test data during acceptance testing.

2. Background Information

In the past during acceptance testing of a train, signals from various subsystems on various vehicles of the train had to be hard wired to a strip chart recorder to monitor the subsystems performance. This was- very time-consuming and difficult to do. A need existed for a way to allow a person to obtain performance data from any subsystem on the train for any vehicle in the train from a single location.

With the advent of sophisticated trainwide data com¬ munications capabilities, a solution to the above problems has now become feasible.

SUMMARY OF THE INVENTION

The present invention solves the above mentioned problems by providing an interface^"which permits test equipment to be attached at one location on the train and obtain test data from any subsystem on any car of the train.

In particular, according to one embodiment of the invention, an interface is provided which permits a Portable Test Unit (PTU) and strip chart recorder, or other testing and recording devices, to be connected to a trainwide data communications system allowing the display of real-time data about any subsystem on any car in the train from a single location. The trainwide data communications system, in particular, is a trainline monitor (TLM) system such as that developed by the assignee of the present application and described briefly herein. The TLM, developed in tandem with the present invention, is based in part on the draft DIN 43322 GERMAN STANDARD specification dated July 1988, which is hereby incorporated by reference. The TLM is primarily used to control and monitor the vehicles in a train. Communica- tion is handled by a two-tiered data communication network. Two TLM data links, or tiers, include a first tier providing communication between vehicles and a second tier providing communication within a vehicle, i.e., with vehicle subsystems. In this way, the various systems and sub-systems of the multi-car (vehicle) train are monitored and controlled over the network.

According to an embodiment of the invention, each vehicle in the train is connected to the trainwide communications system over at least one train bus having a system master and one or more slave devices connected as nodes on the bus. The system master has a default table stored in memory which indicates to an operator the variables which can be displayed on, for example, a strip chart recorder. When test equipment, e.g., the PTU, is connected to the master node (system master) on the trainwide data communications system, the PTU can request data from any subsystem on any vehicle in the train indicated in the table.

According to an embodiment of the invention, any of the vehicles of the train may be designated as the system master node. Each other vehicle is designated as a slave station or node on the train bus interconnecting the train vehicles. Each vehicle node communicates with subsystems on the vehicle over another master-slave data link called a vehicle bus. A node on the train bus, either system master or slave, includes a vehicle bus master. The subsystems on the vehicle bus act as slaves to the vehicle bus master. In this way, a two-tiered communication network is established over which test equipment, e.g. , the PTU, may obtain test data about any subsystem in the train.

According to an embodiment of the invention, during testing, an operator of the PTU selects variables from selected subsystems on selected vehicles that are to be displayed on the strip chart recorder. Status messages requesting the data are sent over the trainwide data com¬ munications system (train bus) to the appropriate slave node using a master-slave type transaction protocol. A slave vehicle responds to a message requesting status by sending the requested data when available. A slave vehicle may constantly monitor and update the status of its subsystems, storing the status data in local memory until receiving a request to transmit it from the PTU. Alternately, it may poll selected subsystem or subsystems in response to the status request to obtain the necessary data on demand.

In an embodiment of the invention, in addition to the above features, if the trainwide communications system (TLM) includes a fault monitoring and logging functionality, the PTU may interrogate the "fault log and selectively display data stored therein. Therefore, according to the invention, testing, of a multi-vehicle train is simplified and may be accomplished more efficiently.

Further features and advantages will become apparent from the following description of a preferred embodiment taken with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a trainwide communications system including the remote signal monitoring system according to the invention;

Figure 2 is a flow diagram showing the processes in the master and a slave for requesting, receiving and displaying requested variables; Figure 3 is a block diagram of a trainline monitor system (TLM) in which the present invention is particularly useful;

Figure 4a shows a representative Vehicle Subsystem Status Request Message; Figure 4b shows a representative Vehicle Subsystem Status Response Message; and

Figure 5 shows an embodiment of the invention wherein the embodiment of a remote signal monitoring system shown in Figure 1 is integrated into the TLM of Figure 3.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The invention will now be described in more detail by example with reference to the embodiments shown in the Figures. It should be kept in mind that the following described embodiments are only presented by way of example and should not be construed as limiting the inventive concept to any particular physical configuration. Referring now to Figure 1, master vehicle processing system 101 communicates with slave vehicle processing systems 102 over system bus 130. The master processing system 101 includes at least one processing unit, CPU. 110, memory 126, a vehicle bus 123 interconnecting various subsystems 120a-n, and a digital to analog convertor (D/A) 112. The master vehicle processing system 101 may also include other functional blocks which are omitted from the figure for the purposes of simplifying the following description. Attached to the master CPU 110 are input select block 108 and, via digital to analog convertor block 112, display block 114. Input select block 108 is used by an operator to input commands to the CPU 110, in particular, subsystem status request commands. Display block 114 may represent a. chart recorder or any other analog driven display device used in performing tests. D/A Convertor 112 converts digital data from CPU 110 into analog data and thereby provides the analog signals necessary to drive display 114.

Upon request by an operator, the master CPU 110 forms and outputs a subsystem variable request (SVREQ) message 106 over bus 130 directed to a particular slave vehicle subsystem. Each slave includes at least one processing unit, slave CPU 122, memory 124, and a plurality of subsystems 120a-n connected to CPU 122 over local bus 123 as shown. Again, as with the system master, details not essential to understanding the invention have been omitted.

The SVREQ message 106 is received by the slave CPU 122 to which it is addressed over bus 130. The message 106 is processed in slave CPU 122 and a response message, SVRESP 107 is issued to the master CPU 110 over bus 130. The CPU's 122 in the slave vehicle processing systems 102 may periodically poll the subsystems 120a-n and maintain in the respective memories 124 status information regarding each of the respective subsystem in the slave vehicle. Additionally, where a subsystem 120a-n is

"intelligent," the subsystem itself may output status . information to the slave CPU 122 and/or memory 124 upon detection of an abnormal condition. Alternately, the slave CPU 122 may only interrogate one or more subsystems 120 in response to an SVREQ message 106 from the system master 101. Messages 106 and 107 may be formed as data packets in an advantageous fashion, which include destination address information, etc. Further details about the messages 106 and 107 will be described later.

Referring now to Figure 2, shown in block form is a flow diagram of the process for implementing the present invention. The functions for the master vehicle processing system 101 and a slave vehicle processing system 102 are shown side by side in Figure 2.

Starting with the master 101, at block 202 the operator inputs a request for subsystem status, i.e., a subsystem variable request. At block 204, an SVREQ message 106 is generated and at block 206 the SVREQ message is transmitted over the bus 130 destined for one or more of the slaves 102. Meanwhile, slave 102 has been monitoring subsystem status variables at block 220. At block 222, the SVREQ message 106 is received, at block 224, a response, i.e., SVRESP 107 is formed, and at block 226, the SVRESP 107 is transmitted to the master 101 over the bus 130. The slave then returns to monitoring the subsystems as represented by block 228.

This would of course be a slightly different procedure if the slave 102 were configured to only poll subsystems 120 upon receipt of an SVREQ message 106. Block 220 would be omitted and between blocks 222 and 224, a block for interrogating the selected subsystems would be inserted, as would be readily apparent to one of ordinary skill in the art.

The master 101 receives the SVRESP message 107 at block 208, processes it at block 210, which would include D/A conversion by D/A convertor 112 of digital information from CPU 110, and the requested information is displayed on the analog display device 114 as indicated at block 212.

Referring now to Figure 3, shown is a Trainline Monitor (TLM) System in which the invention finds particular use. Figure 3 shows a representative train 312 with a head car 314, a tail car 316, and middle cars 318. Only one middle car 318 is shown, however a typical commuter train may have from one to ten middle cars 318 having essentially the same equipment on board. Head car 314 has redundant train bus masters including primary train bus master 330A and backup train bus master 33OB as shown. Primary train bus master 330A serves as a master node for primary train bus 332A and backup train master bus 33OB serves as a master node for backup train bus 332B. Primary train bus 332A and backup train bus 332B make up redundant train buses 332. In addition, middle cars 318 and tail car 316 each have redundant train bus slaves including primary train bus slave 331A and backup train bus slave 33IB. Each car 314, 316 and 318 has a vehicle bus master 340 and a vehicle bus 342 which are used in the TLM system 320 as means for communicating with the various subsystems. Examples of subsystems which may be found on head car 314 include first propulsion truck 350, second propulsion truck 352> friction brake unit 354, and passenger communication unit 356 as shown. Other subsystems, not shown for ease of illustration, may include a doors control unit, a heating, ventilation and air conditioning unit (HVAC) , a lighting unit, etc. Operational data, including waveforms and test point signals, about the vehicle subsystems is requested, furnished and displayed according to the present invention.

Redundant train bus masters 330A, 330B or redundant train bus slaves 331A, 33IB, together with their respective vehicle bus master 340, can be embodied in three separate CPUs or a single CPU with a multitasking operating system and 3 separate I/O ports. Each of the train buses 332A and 332B, with its master and slave devices, are preferably configured as an HDLC packet com¬ munications network according to a modified ISO 4335 INTERNATIONAL STANDARD for data communications in the third edition dated 1987, which is hereby incorporated by reference.

Middle cars 318 can have the same subsystems as head car 314 but they typically would not have a second propulsion truck 352 but would have a convertor unit 353 and an intermediate voltage power supply (IVPS) 355. Tail car 316 has the same subsystems as head car 314. The following discussion regarding train bus master 330A applies to train bus master 330B as well. Head car 314 has, in addition to redundant train bus masters 330A and 330B, a console display 370, operator command input unit 372, radio link unit 374, console 376 and auxiliary control panel 378, which facilitate control and communications by a train operator. Referring to head car 314, vehicle bus master 340 communicates with one of redundant train bus masters 330A and 33OB which in turn communicate with the rest of TLM system 320 via one of the primary train bus 332A and backup train bus 332B, respectively. Vehicle bus 342 has predetermined nodes and therefore does not have to deal with such considerations as geographic addressing or car orientation. Vehicle bus 342 can be, for example, an Intel BITBUS in which case the subsystems would have BITBUS interfaces. Vehicle bus master 340 and the various subsystems 350-356, etc., operate under standard master-slave communications protocols, such as Synchronous Data Link Control (SDLC) , using a multidrop RS-485 serial link. Vehicle bus master 340, vehicle bus 342 and the various vehicle subsystems comprise a master-slave communication subsystem 321. Communications on the TLM system will- be described below, in particular, communications which provide information about particular subsystems 350-356 on one or more representative vehicles 318 of the train 312 over 5 the TLM communications network, with reference to Figure 3.

The TLM system 320 is connected to first and second propulsion trucks 350 and 352 by vehicle bus 342. The TLM system 320 can transmit test commands, propulsion

10 commands, real-time clock synchronization information, etc. , to the first and second propulsion trucks 350 and 352. First and second propulsion trucks 350 and 352 respond by transmitting back test results and status information over the TLM system 320.

15 In a like manner, the TLM system 320 is connected to convertor unit 353 by the vehicle bus 342. The TLM system 320 can transmit test commands and convertor control commands such as convertor on/off, load shedding commands and real-time clock synchronization information,

20 etc., to the convertor unit 353. The convertor unit 353 responds by transmitting back test results and status information to TLM system 320.

The TLM system 320 is connected to a friction brake unit 354 by the vehicle bus 342. The TLM system 320

25 transmits test commands, braking commands and real-time clock synchronization information, etc. , to the friction brake unit 354. The friction brake unit 354 responds by transmitting back test results and status information to TLM system 320. , 30 The TLM system 320 is also connected to an intermediate voltage power supply (IVPS) 355 and passenger communication unit 356 by the vehicle bus 342. The IVPS converts 600 volt power into 300 volts which is necessary since some of the subsystems, such as the

35 friction brake unit 354, use 300 volt power. The TLM system 320 transmits test commands, IVPS control com¬ mands, such as IVPS on/off commands, and real-time clock synchronization information, etc., to IVPS 355 and the IVPS 355 responds by transmitting back test results and status information to TLM system 320. The TLM system 320 transmits test commands, real-time clock synchronization information, car serial number, relative car position, car orientation information, zero speed commands, door open and close commands, and odometer or speed signals, etc., to passenger communication unit 356. The passenger communication unit 356 responds by transmitting back test results and status information to TLM system 320. The TLM system 320 is also connected to other subsystems (not shown) , such as a door control unit, a heating, ventilation and air conditioning (HVAC) unit, and a lighting unit, by the vehicle bus 342. TLM system 320 transmits test commands, status requests, real-time clock synchronization information, car orientation information, etc., .to the units. The units respond by transmitting back test results and status information.

The operator command input unit 372 of head car 314 may be a waterproof piezo keyboard having piezo keys in¬ tegrated into a 5 mm aluminum plate and operated through a 0.8 mm aluminum cover plate. Console display 370 may be an electro-luminescent self-illuminated screen. Console 376 is a state driven device having a "power-up" state and a "operating" state.

If a car in train 312 is keyed-up, then operator console 376 is enabled and this car becomes the head car with redundant train bus masters 330A, 330B. At start-up, console display 370 displays results of power- up self-test. Then, TLM system 320 enters an "operating state." Console display 370 then displays a simple status message (OK, Warning, Failed or Non-existent) for each subsystem 350-364 on each car of train 312. The operator can use operator command input 372'to access diagnostic information on any of the subsystems 321 on any of the cars of train 312. Information can also be transmitted or received by a wayside station using radio link 374 thereby reporting diagnostic alarms and acting as a diagnostic data dump at a specific point along the wayside. Portable Test equipment (PT Unit) advantageously interfaces with the TLM 320 via the system master 330A (101) in the head car 314, as was shown in Figure l and previously described.

In the TLM 320 shown in Figure 3 in which the invention has particular usefulness, the train bus 332 is based on the draft DIN 43322 GERMAN STANDARD specific¬ ation dated July 1988 developed especially for the railroad environment, which is hereby incorporated by reference. It is configured as a master-slave communica- tion system that uses a multi-drop RS-485 serial link. The serial data is Manchester encoded for higher reliability. This also allows it to pass through the galvanic isolation between cars. Train bus messages between vehicles are encoded into standard high level data link control (HDLC) data packets. During operation, the HDLC-encoded messages and protocol ensure data integrity and provide a way to request data retransmission if necessary.

Each vehicle bus 342 is based on the well known industry standard Intel BITBUS, the subject matter of which is hereby incorporated by reference. BITBUS is a master-slave communication system that uses a multidrop RS-485 serial link. This provides a simple, expandable system to which all systems on the vehicle can easily interface.- BITBUS messages are transmitted as synchronous data link control (SDLC) data packets.

During operation, the SDLC-encoded messages and protocol ensure data integrity and provide a way to request data retransmission if necessary. In conjunction with the present invention, examples of SDLC-encoded messages, i.e., Master-Slave Transac- tions, in particular, Status Polling Messages, are described below with reference to Figures 4a and 4b. These messages define a protocol for gathering vehicle subsystem status information over vehicle buses 342. The vehicle bus master 340 issues a status request message, such as that shown in Figure 4a, to the slave and the slave responds with a slave response message, such as that shown in Figure 4b. Note that the slave response message packet will have a fixed number of bytes with which to report back its subsystem status.

In the fields containing the values "00" in Figures 4a and 4b, the "00" values have very specific meanings. In the overall train-wide communication system a layered communication system is implemented. The "00" values in the second and third bytes of Figures 4a and 4b are used by the transport layer for control purposes. The use of a layered communication system in the present invention is not a strict OSI (ISO) implementation, but rather a compromise of OSI features and high performance for a time critical system. This explains two of the three sets of "00" fields in the figures, the other "00" field is due to the message structure used in the system. All end application messages consist of a one byte command field and a one to 32,768 byte data field. All messages must have at least one byte of data. If the data is not used, the field is filled with "00." This is why the last byte of Figure 4a is "00."

Referring now to Figure 5, the system described with respect to Figure 1 is shown integrated into the TLM system of Figure 3. Portable Test Unit (PTU) 502 is shown attached to the trainline monitor (TLM) system fault log 501a of head car 314 via an RS-232 line. Chart recorder 514 is likewise attached to the TLM system via its own analog line 513. As indicated, the PTU 502 has a small display 504 and keypad 506 by which test personnel may enter test commands for testing various systems and subsystems, obtaining data from subsystems on other cars in the train, or interrogate the TLM fault logs 501a and other fault logs, e.g., propulsion logic fault log 550a- c, associated with particular subsystems, among other things. The PTU 502 is advantageously configured as a lap-top IBM compatible computer. The propulsion logic fault log 550a receives fault messages regarding various subsystem components in real-time, such as motor current 505a, as shown. Each subsystem may be equipped with such a fault log, each fault log being embodied by a block of memory locations associated with the vehicle bus master (slave CPU 122) , for example, memory 124 as shown in Figure 1. Fault log memory should be non-volatile memory and may include information on the fault type, date, time of day, odometer reading, speed, and other specific information on the fault type.

The operator console 376 is capable of requesting and displaying a variety of operator messages on console display 370. The PTU 502 may be capable of requesting all the messages available to the operator and can additionally perform detailed diagnostics and observations of virtually all of the equipment on train 312. The PTU 502 therefore provides comprehensive testing and monitoring abilities. Additionally, the PTU 502 controls what is sent to chart recorder 514 and can down-load any fault log of any vehicle for further analysis.

Chart recorder 514 may be configured as an eight- channel recorder for displaying signals from the system or subsystem under test. The signals displayed may be real-time- displays of system performance variables or specific troubleshooting information on the TLM.

It will be understood that the above description of the preferred embodiment of the present invention is susceptible to various modifications, changes, and adaptations, and the same are intended to be comprehended within the meaning and range of equivalents of the appended claims.

Claims

WE CLAIM :

1. In a multi-car train having a train-wide com¬ munications network for communication between a master vehicle processing system on a master car and. slave vehicle processing systems on slave cars in the train, each car having a vehicle communications network connected to subsystems of the car, an arrangement for collecting real-time data pertaining to operation of the subsystems comprising: requesting means in the master vehicle processing system of the master car for forming and transmitting a subsystem variable request message to slave vehicle processing systems in one or more slave cars in the train over the trainwide communications network requesting data on the operation of at least one subsystem; responding means in the slave vehicle processing systems of the one or more slave cars in the train for responding to the subsystem variable request message by forming and transmitting a subsystem variable response message containing the requested data on the operation of the at least one subsystem; and displaying means operatively connected to the master vehicle processing system of the master car for displaying the requested subsystem operating variable status data.

2. The arrangement according to claim 1, wherein the request and response messages are formed as data packets.

3. The arrangement according to claim 1, wherein the display means comprises a strip chart recorder.

4. The arrangement according to claim 1, wherein each responding means comprises: monitoring means for monitoring subsystems operation; and logging means for storing operating variable data associated with subsystems operation and for periodically updating the operating variable data associated with subsystems operation.

5. The arrangement according to claim 1, wherein the requesting means comprises: menuing means for selectively presenting to an operator one of a plurality of tables, each table showing a menu of subsystem operating variables which can be displayed for a respective subsystem; and selecting means for selecting at least one particular subsystem and at .least one particular operating variable to be displayed; wherein the requesting means forms a subsystem variable request message based on the at least one subsystem and at least one operating variable presented on the menuing means and selected with the selecting means.

6. The arrangement according to claim 1, wherein the displaying means comprises extracting means for extracting the operating variable status data from the subsystem variable response message and converting means for converting the extracted data into a displayable form.

7. ^•The arrangement according to claim 6, wherein the converting means comprises a digital to analog convertor and the displaying means comprises a strip chart recorder.

8. In a multi-car train having a train-wide com¬ munications network for communication between a master vehicle processing system on a master car and slave vehicle processing systems on slave cars in the train, each car having a vehicle communications network connected to subsystems of the car, a method for collecting real-time data pertaining to operation of the subsystems comprising: requesting data on the operation of at least one subsystem, including forming and transmitting a subsystem variable request message to slave vehicle processing systems in one or moire slave cars in the train over the trainwide communications network; responding to the subsystem variable request message with the requested data on the operation of the at least one subsystem, including forming and transmitt¬ ing a subsystem variable response message; and displaying the requested subsystem operating variable status data.

9. The method of claim 8, wherein the requesting and responding steps comprise forming messages as data packets.

10. The method of claim 8, wherein the displaying step comprises graphing the data on a strip chart recor¬ der.

11. The method of claim 8, wherein the step of responding comprises: monitoring subsystems operation; and logging operating variable data associated with subsystems operation and periodically updating the operating variable data associated with subsystems operation.

12. The method of claim 8, wherein the requesting step comprises: selectively presenting to an operator one of a plurality of tables, each table showing a menu of subsyε- tern operating variables which can be displayed for a respective subsystem; and selecting at least one particular subsystem and at least one particular operating variable to be displayed; wherein the subsystem variable request message is formed based on the at least one subsystem and at least one operating variable presented in the menuing step and selected in the selecting step.

13; The method of claim 8, wherein the displaying step comprises extracting the operating variable status data from the subsystem variable response message and converting the extracted data into a displayable form.