US 6,938,258 B1Grant

Message processor for a passenger entertainment system, method and article of manufacture

Issue Date:2005-08-30

•20 Claims

•25 Drawing Sheets

Abstract

A computer is used to manage communication over a network between one or more network addressable units and a plurality of physical devices of a passenger entertainment system. The system is configured and operated using software to provide passenger entertainment services including audio and video on-demand, information dissemination, product and service order processing, video teleconferencing and data communication services. The system includes a system server and a network supporting multiple computer processors. The processors and the server comprise application software that control telephony applications and network services. The server is coupled by way of the network to physical devices of the system. The server comprises software for instantiating a dispatch object to open a framework for one or more network addressable unit objects, for instantiating one or more virtual line replaceable unit objects to manage communication between a network address unit and one or more physical devices, and for instantiating a message processor for moving messages to the one or more network addressable unit objects for delivery to the one or more physical devices. The message processor receives messages containing network routing address from one or more device drivers. The message processor utilizes the network routing address to and a physical device type to access a table and determine the ultimate destination for the message. The message processor has at least one input named pipe and one output named pipe, and utilizes the named pipes to translate messages from a first format to a second format. The message processor logs invalid destination addresses in a storage medium. The message processor instantiates each device driver from a device handler class member.

Metadata

Assignee

Rockwell Collins

Inventors

Alan J. Weinberger
Joseph J. Renton
Rick Neugaubauer

Application Information

Application Number:US 09/085,246

Filing Date:1998-05-26

Priority Date:1998-05-26

Art Unit:2126

Patent Drawings (25 sheets)

Description

Copyright Notification

[0001] Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office.

Field of the Invention

[0002] The present invention relates to providing entertainment to passengers in a vehicle, and more specifically, to systems, methods and articles of manufacture that provide for a networked passenger entertainment system that integrates audio, video, passenger information, product ordering and service processing, communications, and maintainability features, and permits passengers to selectively order or request products and services, receive video, audio and game data for entertainment purposes, and communicate with other passengers and computers on- and off-board the aircraft, and which thereby provides for passenger selected delivery of content over a communication network.

Background of the Invention

[0003] The assignee of the present invention manufactures in-flight aircraft passenger entertainment systems. Such systems distribute audio and video material to passengers derived from a variety of sources. For example, such systems provide passengers with audio generated from audio tape players, movies derived from video tape players, and interactive services such as games, shopping and telecommunications. A variety of inventions have been patented by the assignee of the present invention and others relating to in-flight aircraft entertainment systems and their components. Certain of these prior art systems and components are summarized below.

[0004] U.S. Pat. No. 3,795,771 entitled “Passenger Entertainment/Passenger Service and Self-Test System” discloses a time multiplexed passenger entertainment and service combined system suitable for distribution throughout compartments of super aircraft. Common power supplies, cabling, and boxes, and hybrid microelectronics and/or medium or large scale MOSFET integrated circuit chips are employed. A main multiplexer receives passenger address or tape deck analog signals and converts them to a pulse code modulated digital bit stream which is time shared between channels. A coaxial cable transmits the bit stream to compartment submultiplexers. Each submultiplexer receives the digital bit stream, optionally inserts into the bit stream bits representing analog-to-digital converted movie audio or compartment introduced passenger address and distributes the data stream along four columns of seat group units on individual column coaxial cables. At each seat group unit a demultiplexer of a seat group demultiplexer/encoder converts the bit stream into the original analog signals, amplifiers the analog signals and drives individual seat transducers for passenger listening.

[0005] A passenger control unit provides channel and volume level selection. The passenger service system provides control functions comprising reading light, stewardess call (aisle and control panel lights and chimes). The service system comprises a section timer/decoder to generate binary logic pulses which are transmitted by cable sequentially down and up the seat columns from seat group unit to seat group unit. A similar cable connects the corresponding overhead unit containing the reading lights, etc. to the section timer/decoder. The seat encoder of each seat group demultiplexer/encoder receives digital interrogating signals, processes them relative to switch positions determined by the passenger and sends out results to the section timer/decoder. The overhead decoder of each seat group receives the retransmitted digital signals from the section timer/decoder and performs switching functions conforming to seat encoder commands. The system incorporates a self-test subsystem comprising a test signal generator and circuits operating in conjunction with the entertainment and service system circuits.

[0006] U.S. Pat. No. 5,289,272 entitled “Combined Data, Audio and Video Distribution System in Passenger Aircraft” discloses a passenger aircraft video distribution system that distributes modulated RF carrier signals from a central signal source to be used at each passenger seat. The carriers are modulated to contain audio, video also other digital data, such as graphics, and slide shows and the like. Analog video signals from the video source are modulated on individually discrete carriers in the range of 54 to 300 megahertz. Audio information, including audio sound channels and the video audio, are digitized and combined with digital data in a combined serial bit stream that is multiplexed, and then modulated on an RF carrier having a frequency sufficiently above the frequency band of the video signals so that the resulting spectrum of the modulated audio RF carrier does not interfere with the modulated video carriers. The RF carrier signals are combined and distributed to individual seats. The modulated audio carrier is separated from the video carriers at each seat or each group of seats and then demodulated and demultiplexed for selection at each individual seat of a chosen audio channel.

[0007] U.S. Pat. No. 4,866,515 entitled “Passenger Service and Entertainment System for Supplying Frequency-Multiplexed Video, Audio, and Television Game Software Signals to Passenger Seat Terminals” discloses a service and entertainment system for transmitting video signals, audio signals and television game software signals from a central transmitting apparatus to each of a plurality of terminals mounted at respective passenger seats in an aircraft, or at respective seats in a stadium, or theater, or the like. The video signals, audio signals and television game software signals are frequency-multiplexed and then transmitted to the terminals, so that desired ones of the frequency-multiplexed signals can be selected at each terminal unit.

[0008] U.S. Pat. No. 4,647,980 entitled “Aircraft Passenger Television System” discloses a television system that provides for individualized program selection and viewing by aircraft passengers. The system comprises a plurality of compact television receivers mounted in front of each airline passenger in a rearwardly facing position within the passenger seat immediately in front of each passenger. Each television receiver is provided as a lightweight module adapted for rapid, removable installation into a mounting bracket opening rearwardly on the rear side of a passenger seat, with a viewing screen set at a tilt angle accommodating an average reclined position of the seat. Exposed controls permit channel and volume selection by the individual passenger, and an audio headset is provided for plug-in connection to the module. A broadcast station on the aircraft provides prerecorded and/or locally received programs on different channels to each television module for individual passenger selection.

[0009] U.S. Pat. No. 4,630,821 entitled “Video Game Apparatus Integral with Aircraft Passenger Seat Tray” discloses a video game apparatus employed by a passenger of an aircraft. The apparatus includes a tray that is mounted on the rear of an aircraft seat. The tray has an internal hollow with a rectangular aperture on a top surface which surface faces the passenger when the tray is placed in a usable position. Located in the rectangular aperture is a TV display screen. Located in the internal hollow of the tray is a video game apparatus that operates to provide a video game display on the surface of said TV display screen. The surface of the tray containing the TV display screen also includes a plurality of control elements that are coupled to the video game apparatus to enable the passenger to operate the game. To energize the game, the tray contains a cable coupling assembly whereby when a cable is inserted into the assembly, the video game is energized to provide a display of a game selected by means of a selector switch also mounted on the top surface of the tray.

[0010] U.S. Pat. No. 4,352,200 entitled “Wireless Aircraft Passenger Audio Entertainment System” discloses that audio information in several audio channels is supplied via head sets to passengers seated aboard an aircraft in rows of seats including armrests and being distributed along an elongate passenger section inside a metallic fuselage. An antenna is run along the elongate passenger section of the aircraft for radio transmission inside such elongate passenger section. Individual antennas are provided for the passenger seats for receiving the latter radio transmission. These receiving antennas are distributed among predetermined armrests of the passenger seats. The audio information to be transmitted is provided in radio frequency channels in a band between 72 and 73 MHz. The distributed receiving antennas are coupled via seated passengers to the transmitting antenna. The radio frequency channels are transmitted in the mentioned band via the transmitting antenna, seated passengers and distributed receiving antennas to the predetermined armrests. Audio information is derived in the audio channels from the transmitted radio frequency channels also in the predetermined armrests. Passengers are individually enabled to select audio information from among the derived audio information in the audio channels. The selected audio information is applied individually to the headsets.

[0011] U.S. Pat. Nos. 5,965,647 and 5,617,331 entitled “Integrated Video and Audio Signal Distribution System and Method for use on Commercial Aircraft and Other Vehicles” disclose passenger entertainment systems employing an improved digital audio signal distribution system and method for use on commercial aircraft and other vehicles. A plurality of digital audio signal sources are provided for generating a plurality of compressed digital audio signals. The compressed digital audio signals are provided to a multiplexer that domain multiplexes the signals to produce a single composite digital audio data signal. The composite digital audio data signal is provided to a demultiplexer which is capable of selecting a desired channel from the composite digital audio data signal. The selected channel is provided to a decompression circuit, where it is expanded to produce a decompressed digital output signal. The decompressed digital output signal is then provided to a digital-to-analog converter and converted to an analog audio signal. The analog audio signal is provided to an audio transducer.

[0012] While the above patents disclose various aspects of passenger entertainment systems and components used therein, none of these prior art references disclose a fully integrated networked passenger entertainment system that integrates audio, video, product ordering and service processing, networked communications, and maintainability features. Accordingly, it is an objective of the present invention to provide for systems and methods that implement an integrated networked passenger entertainment and communication system that provides for passenger selected delivery of content over a communication network. It is a further objective of the present invention to provide for systems and methods that permit passengers to selectively order or request products or services, receive audio, video and game data, that permits communication of information to passengers from aircraft personnel, and that permits passengers to communicate with other passengers and computers located on- and off-board an aircraft.

Summary of the Invention

[0013] The foregoing problems are overcome in an illustrative embodiment of the invention in which a computer manages communication over a network between one or more network addressable units and a plurality of physical devices of a passenger entertainment system on a vehicle. The passenger entertainment system is configured and operated using software to provide passenger entertainment services including audio and video on-demand, information dissemination, product and service order processing, video teleconferencing and data communication services between passengers on-board the vehicle using a local networks, and between passengers and people and computers off-board the vehicle using a communications link.

[0014] The passenger entertainment system includes a system server and a network for supporting a plurality of computer processors that are each coupled to a video camera, a microphone, a video display, an audio reproducing device, and an input device located proximal to a plurality of seats. The computer processors and the system server comprise application software that selectively controls telephony applications and network services. The system server has a plurality of interfaces that interface to components (physical devices) of the passenger entertainment system.

[0015] In carrying out the present invention, the system server is coupled by way of the network to a plurality of physical devices. The system server comprises software that instantiates a dispatch object to open a framework for one or more network addressable unit objects. The system server comprises software that instantiates one or more virtual line replaceable unit objects to manage communication between a network address unit and one or more physical devices. The system server comprises software that instantiates a message processor for moving messages to the one or more network addressable unit objects for delivery to the one or more physical devices.

[0016] The message processor receives messages containing network routing address from one or more device drivers. The message processor utilizes the network routing address to and a physical device type to access a table and determine the ultimate destination for the message. The message processor has at least one input named pipe and one output named pipe, and utilizes the named pipes to translate messages from a first format to a second format. The message processor logs invalid destination addresses in a storage medium. The message processor instantiates each device driver from a device handler class member.

Brief Description of the Drawings

[0017] The various features and advantages of the present invention may be more readily understood with reference to the following detailed description taken in conjunction with the accompanying drawings, and in which:

[0018] FIG. 1 illustrates an operational environment depicting a total entertainment system in accordance with a preferred embodiment;

[0019] FIG. 2 is an exemplary block diagram of an embodiment of the total entertainment system;

[0020] FIG. 3 shows a detailed block diagram of the total entertainment system of FIG. 2;

[0021] FIG. 4 shows a diagram illustrating a typical hardware configuration of a workstation employed in accordance with a preferred embodiment;

[0022] FIG. 5 is a diagram illustrating head end equipment in accordance with a preferred embodiment;

[0023] FIG. 5a is a diagram illustrating distribution of QAM digital audio in accordance with in accordance with a preferred embodiment;

[0024] FIG. 6 is a block diagram of area distribution equipment in accordance with a preferred embodiment;

[0025] FIG. 7 is a block diagram of seat group equipment in accordance with a preferred embodiment;

[0026] FIG. 7a is a block diagram of the seat controller card of the seat group equipment in accordance with a preferred embodiment;

[0027] FIG. 7b illustrates a typical fixed passenger control unit;

[0028] FIG. 8 is a block diagram of overhead equipment in accordance with a preferred embodiment;

[0029] FIG. 9 is a block diagram of an Airplane Configuration System (ACS) tool used in accordance with a preferred embodiment;

[0030] FIG. 10 is a block diagram of the software architecture in accordance with a preferred embodiment;

[0031] FIG. 11 illustrates message processor function and data paths;

[0032] FIG. 12 illustrates operational flow of an ARCNET driver;

[0033] FIG. 13 illustrates primary access terminal network addressable unit function and data paths;

[0034] FIG. 14 illustrates transaction dispatcher function and data paths;

[0035] FIG. 15 illustrates system monitor function and data paths;

[0036] FIG. 16 illustrates primary access terminal RPC client.DLL function and data paths

[0037] FIG. 17 illustrates backbone network addressable unit function and data paths;

[0038] FIG. 18 illustrates seat network addressable unit function and data paths;

[0039] FIG. 19 illustrates VCP network addressable unit function and data paths;

[0040] FIG. 20 illustrates Test Port network addressable unit function and data paths; and

[0041] FIG. 21 illustrates Services function and data paths.

Detailed Description

System Overview

[0042] FIG. 1 illustrates an operational environment depicting an exemplary total entertainment system 100 in accordance with a preferred embodiment. The operational environment shown in FIG. 1 depicts a flight of an aircraft 111 employing the total entertainment system 100. The total entertainment system 100 comprises an integrated networked passenger entertainment and communication system 100 that provides for in-flight passenger entertainment and information dissemination, service and product order processing, video teleconferencing and data communication between passengers on-board the aircraft 111, and video teleconferencing, voice and data communication between passengers 117 on-board the aircraft 111 and people and computers on the ground using local networks and the Internet 113. The present invention thus provides for a level of capabilities and services heretofore unavailable in any airborne passenger entertainment system.

[0043] The system 100 is comprised of four main functional areas including head end equipment 200, area distribution equipment 210, seat group equipment 220, and overhead equipment 230. The head end equipment 200 provides an interface to external hardware and operators. The area distribution equipment 210 routes signals to and/or from the head end equipment 200, the seat group equipment 220, and the overhead equipment 230, depending upon the type of service provided to or requested by the passengers. The seat group equipment 220 contains passenger control units (PCU) 121 and screen displays 122 for use by the passengers 117. The overhead equipment 230 includes video monitors and/or projectors and bulkhead screens or displays for displaying movies and other information. The system 100 thus routes or otherwise displays information to the passengers either under control of the flight attendants or passengers 117.

[0044] Video conferencing data and computer data derived from ground based computers 112 connected to the Internet 113 are transferred over the Internet 113 to a satellite ground station 114 and are uplinked to a communications satellite 115 orbiting the Earth. The communications satellite 115 downlinks the video conferencing and/or computer data to the aircraft 111 which is received by way of an antenna 116 that is part of a satellite communications system employed in the head end equipment 200 of the system 100. In a similar manner, video conferencing data and/or computer data derived from passengers 117 on-board the aircraft 111 is uplinked to the satellite 115 by way of the satellite communications system arid antenna 116 to the satellite 115, and from there is downlinked by way of the satellite ground station 114 and Internet 113 to the ground based computer 112.

[0045] One or more satellites 115, which may be the same as or different from the satellites 115 used for Internet communication, transmit television signals to the aircraft 111. One currently deployed satellite television broadcast system is the DIRECTV system that has orbiting satellites 115 that may be used to transmit television programs to the aircraft 111, in a manner similar to ground-based systems used in homes and businesses. In the present system 100, however, a steerable antenna 116 is used to track the position of the satellite 115 that transmits the signals so that the antenna 116 remains locked onto the transmitted signal.

[0046] Handheld or fixed passenger control units 121 and seatback screen displays 122 (seat displays 122) are provided at each passenger seat 123 that permit the passengers 117 to interface to the system 100. The passenger control units 121 are used to control downloading of movies for viewing, select audio channels for listening, initiate service calls to flight attendants, order products and services, and control lighting. The passenger control units 121 are also used to control game programs that are downloaded and played at the passenger seat 123. In addition, the passenger control units 121 are also used to initiate video conferencing and computer data transfer sessions either within the aircraft or with ground based computers 112.

[0047] The present system 100 thus provides for an integrated and networked passenger entertainment and communication system 100 that in essence functions as an airborne intranet that provides a level of passenger selected and controlled entertainment and communications services, passenger services and product ordering services that has heretofore not been provided to aircraft passengers.

[0048] FIG. 2 is an exemplary block diagram of an embodiment of a total entertainment system 100 that is employed on the aircraft 111, and illustrates inputs, outputs and interfaces of the system 100. The system 100 comprises the head end equipment 200, the area distribution equipment 210, the seat group equipment 220, and the overhead equipment 230. The head end equipment 200 and the seat group equipment 220 include a variety of computer processors and operating software that communicate over various networks to control and distribute data throughout the aircraft 111 and send data to and receive data from sources external to the aircraft 111. A detailed embodiment of the total entertainment system 100 is shown in FIG. 3, which will be described after discussing a representative hardware environment that is useful in understanding the system 100 and its operation that is presented in FIG. 4.

[0049] An embodiment of the system 100 is practiced in the context of a personal computer such as the IBM PS/2, APPLE MACINTOSH computer or UNIX based workstation. A representative hardware environment is depicted in FIG. 4, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 310, such as a microprocessor, and a number of other units interconnected via a system bus 312. The workstation shown in FIG. 4 includes a random access memory (RAM) 314, read only memory (ROM) 316, an I/O adapter 318 for connecting peripheral devices such as disk storage units 320 to the bus 312, a user interface adapter 322 for connecting a keyboard 324, a mouse 326, a speaker 328, a microphone 332, and/or other user interface devices such as a touch screen (not shown) to the bus 312, communication adapter 334 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 336 for connecting the bus 312 to a display device 338. The workstation typically has resident thereon an operating system such as the MICROSOFT WINDOWS NT or WINDOWS/95 operating system (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

Detailed System Description

[0050] The in-flight entertainment system 100 in accordance with a preferred embodiment is a complex system with many components and that forms a total entertainment system (TES) 100. To assist the reader in making and utilizing the invention without undue experimentation, the following is a detailed description that discusses some of the components and a typical system configuration. The system 100 in accordance with a preferred embodiment is a configurable and scaleable in-flight entertainment system 100 that provides a wide range of passenger entertainment, communications, passenger service, and cabin management services. A fully capable system 100 provides passengers with audio entertainment, video entertainment, video games, and other interactive and communications services.

[0051] The system 100 shown in FIG. 1 and 2 has four main functional areas comprising: 1) head end equipment 200, 2) area distribution equipment 210, 3) seat group equipment 220, and 4) overhead equipment 230. FIG. 3 shows the four functional areas and the line replaceable units (LRU) that comprise a typical passenger entertainment system 100. An overview of the LRUs in each of the functional areas is described in the following paragraphs.

[0052] The head end equipment 200 is the prime interface between external hardware and operators (purser and flight attendants). The head end equipment 200 includes an operator interface, an aircraft interface, a maintenance interface, and an interface for downloading configuration data to the system 100 and for downloading reports from the system.

[0053] The head end equipment 200 shown in FIG. 3 comprises a primary access terminal (PAT) 225 and a cabin file server (CFS) 268 that are used to control the system 100. The cabin file server 268 is a system controller that controls many of the system functions, such as interactive functions, and stores the system configuration database and the application software. The cabin file server 268 communicates with other components within the head end equipment 200 via an ARCNET interface 216. The cabin file server may be a computer terminal as shown in FIG. 4 that includes a hard disk drive and a database that stores the system 100 configuration and other system 100 information.

[0054] The cabin file server 268 is coupled to the primary access terminal 225 and to a printer 226 by way of an Ethernet network 228, such as a 100 Base-T Ethernet network, for example. Flight attendant workstations 225a are also coupled to the cabin file server 268 by way of the Ethernet network 228. A media file server 211 is controlled from the cabin file server 268 by way of an ARINC 485 (RS-485) network 229 coupled therebetween. The cabin file server 268 is optionally coupled to a BIT/BITE tester 221 that is used to perform built in testing operations on the system 100.

[0055] The cabin file server 268 provides the following functions: processes and stores transaction information from passengers; stores passenger usage statistics for movies, games, and shopping; stores passenger survey responses; stores flight attendant usage statistics for login/logout; provides flight attendant access control; controls the video reproducers; controls the landscape camera; controls the PVIS line replaceable unit; stores seat application software and game software; distributes seat application and game software via the RF distribution system; provides power backup sufficient to allow orderly automatic shutdown of the cabin file server 268 operating system when primary power is removed; provides indicators representing power, operational status, and communication status; downloads databases via the RF distribution system; provides the ability to print reports; and provides connectors for a keyboard, monitor, and mouse.

[0056] The primary access terminal 225 shown in FIG. 3 provides an operator interface to the system 100, enabling an operator to centrally control a video reproducer 227 and the media server 211, start BITE, control the landscape cameras 213, and other functions provided in the system 100. The primary access terminal 225 may also be a computer terminal as shown in FIG. 2 that may include a hard disk drive and a display 338 for graphical user interface (GUI) by a flight attendant to the system 100. The display may be a touch screen display to access the system 100. A keyboard (not shown) may also be provided to access the system 100. The primary access terminal 225 is used to configure the system 100 to set up the entertainment options that are available to passengers 117. The flight attendant workstations 225a are distributed throughout the aircraft 111 and allow flight attendants to respond to passenger service requests and to process orders and monetary transactions.

[0057] The primary access terminal 225 provides the following functions: a flight attendant interface to the cabin sales capability, a flight attendant interface to the video entertainment capability, a flight attendant interface to the report and receipt printing capability, monitoring of video and audio output from the video reproducer, maintenance personnel interface to system diagnostics and status reports, power backup sufficient to allow an orderly shutdown of the primary access terminal operating system when primary power is removed, indicators representing power, operational status, and communication status, single and dual plug stereo audio jack, magnetic card reader, and floppy disk drive.

[0058] The head end equipment 200 comprises the media server 211 that is coupled to a first video modulator 212a. The media server 211 may be one manufactured by Formation, for example. The media server 211 supplies 30 independent streams of video, and stores about 54 hour of video. The first video modulator 212a may be one manufactured by Olsen Technologies, for example. The video reproducer 227 (or video cassette player 227), such as a triple deck player manufactured by TEAC, for example, is also coupled to the first video modulator 212a. The video cassette player 227 may be three 8-mm Hi-8 video cassette players that output three video programs on three video channels under control of a flight attendant.

[0059] The video reproducer 227 (or video cassette player 227) outputs an NTSC video (and audio) streams corresponding to a first plurality of prerecorded video channels. The media server 211 stores and outputs a plurality of quadrature amplitude modulated MPEG-compressed video transport streams corresponding to a second plurality of prerecorded video channels. The first video modulator 212a modulates both the NTSC video streams from the video reproducer 227 and the quadrature amplitude modulated MPEG-compressed video streams from the media server 211 to produce modulated RF signals that are distributed to passenger seats 123 of the aircraft 111.

[0060] The head end equipment 200 also comprises one or more landscape cameras 213 and a passenger video information system (PVIS) 214 that are coupled to a second video modulator 212b. The landscape cameras 213 may be cameras manufactured by Sexton, or Puritan Bennett, for example. The second video modulator 212b may also be one manufactured by Olsen Technologies, for example. The passenger video information system 214 may be a unit manufactured by AIRSHOW, for example.

[0061] The head end equipment 200 comprises first and second passenger entertainment system controllers (PESC-A, PESC-V) 224a, 224b, that comprise video, audio and telephone processors. Although only one unit is shown in FIG. 3, in certain configurations, primary and secondary PESC-A controllers 224a may be used. The second video modulator 212b routes RF signals through the first video modulator 212a, and the outputs of both video modulators 212a, 212b are routed through the second passenger entertainment system controller (PESC-V) 224b to the first passenger entertainment system controller (PESC-A) 224a. The first passenger entertainment system controller (PESC-A) 224a is used to distribute video and data by way of an RF cable 215 and an ARCNET network 216, to area distribution equipment 210 that routes the video and data to the passenger seats 123. The ARCNET network 216 is used to send control signals between components of the head end equipment and the components of the seat group equipment 220. The PESC-A 224a also provides an interface to the overhead equipment 230.

[0062] The first passenger entertainment system controller (PESC-A) 224a is coupled to the cabin file server 268 by way of the ARCNET network 216, and is coupled to the primary access terminal (PAT) 225 and the second passenger entertainment system controller (PESC-V) 224b by way of the ARCNET network 216. The first passenger entertainment system controller (PESC-A) 224a is also coupled to a public address (PA) system 222, to an audio tape reproducer (ATR) 223, and to a cabin telephone system (CTS) 239. The audio tape reproducer 223 may be one manufactured by Sony or Matsushita, for example. The cabin telephone system 239 may be systems manufactured by AT&T or GTE, for example. Signals associated with the cabin telephone system 239 are routed through the system 100 by means of a CEPT-E1 network 219.

[0063] The passenger entertainment system audio controller (PESC-A) 224a and the passenger entertainment system video controller (PESC-V) 224b are similarly designed and have similar capabilities. However, some features are implemented only in the PESC-A 224a or only in the PESC-V 224b. The passenger entertainment system controller software implements specific features particular to the PESC-A 224a or PESC-V 224b.

[0064] The passenger entertainment system controller performs the following functions: digitizes up to 32 audio inputs from entertainment and video audio sources, RF modulates the digital data, mixes the RF digital audio data with the RF input from a VMOD or another passenger entertainment system controller, outputs the combined RF video carrier and RF digital audio information to the RF distribution system, inputs up to five analog inputs, and multiplex in any combination to a maximum of five analog outputs, provides programmable volume control of the five analog outputs, provides RS-232, RS-485, ARINC-429, and ARCNET communications interfaces, provides input discretes for the control and distribution of PA audio to the seats, provides input and output discretes for the control and distribution of video announcement audio to the overhead PA system of the aircraft 111, provides input discretes for passenger entertainment system controller type and address information, provides input discrete for aircraft status (in air/on ground), amplifies output RF, software monitorable and controllable, provides an external test/diagnostic communication port, provides indicators representing power, operation status, and communication status, provides telephone control and distribution (PESC-A 224a only), and provides a fault depository for BIT data (PESC-A primary 224a only).

[0065] Referring now to FIG. 5, it shows a simplified diagram of the system 100 and illustrates distribution of video signals from the video cassette player 227 and media server 211 to the seat displays 122. To implement video on demand in accordance with a preferred embodiment, the media server 211 outputs 30 digital MPEG-compressed video transport streams on three video channels (ten streams each), while the video cassette player 227 outputs three video streams on three video channels.

[0066] To gain extra throughput, the 30 digital MPEG compressed video streams output by the media server 211 are 64-value quadrature amplitude modulated (QAM). However, it is to be understood, however, that by using 256-value QAM encoding, for example, the number of video programs delivered in each video channel may be further increased. Consequently, the present system 100 is not limited to any specific QAM encoding value.

[0067] The video streams from the video cassette player 227 and the quadrature amplitude modulated MPEG compressed video transport streams from the media server 211 are then modulated by the first video modulator 212a for transmission over the RF cable 215 to an audio-video distribution unit 231 at each of the passenger seats 123. To provide first class passengers 117, for example, with true video on demand, the streams are controlled by the passengers 117, with one stream assigned to each passenger that requests video services.

[0068] The simultaneous transfer of video streams derived from both the video cassette player 227 and the media server 211 in an aircraft entertainment system is considered unique. In particular, conventional systems either process analog (NTSC) video signals or digital video signals, but do not process both simultaneously. However, in the present system 100, NTSC and quadrature amplitude modulated MPEG-compressed digital video signals are processed simultaneously through the first video modulator 212a and distributed to passenger seats 123 for display.

[0069] The first passenger entertainment system controller (PESC-A) 224a is coupled to a plurality of area distribution boxes 217 by way of the RF cable 215 and the ARCNET network 216. The area distribution boxes 217 are used to distribute digital and analog video streams to the audio-video distribution units 231 at the passenger seats 123.

[0070] FIG. 5a is a diagram illustrating the passenger entertainment system controller (PESC-A) 224a and a cooperative audio-video unit 231 that provide for distribution of quadrature amplitude modulated (QAM) digital audio signals to passenger seats 123 throughout the aircraft 111. The passenger entertainment system controller 224a comprises a plurality of analog to digital converters (A/D) 351 that digitize audio input signals from input sources, such as one or more audio tape reproducers 223, the public address system 222 and a passenger service system 275. The digitized signals from these sources are multiplexed in a multiplexer (MUX) 352 that is controlled by a controller 353 and microprocessor (μP) 355 having a programmable memory 354. The programmable memory 354 stores code for use by the microprocessor 355 in multiplexing the signals.

[0071] The output of the multiplexer 352 is input to a first-in first-out (FIFO) buffer 356 and output signals therefrom are quadrature amplitude modulated using a quadrature amplitude modulator (QAM) 357. The format of the output signals from the FIFO buffer 356 is shown and includes a start frame set of bits (header) followed by each of the respective audio channels (CH1 . . . CHn). The output of the quadrature amplitude modulator 357 is modulated onto a carrier by an RF modulator 358 that transmits the QAM and RF modulated signal over the RF cable 215 to the audio-video units 231 at each of the passenger seats 123.

[0072] The audio-video units 231 each comprise a RF tuner 235 that demodulates the RF modulated signal transmitted over the RF cable 215 that is coupled to a QAM demodulator 237 that demodulates the quadrature amplitude modulated signals. The output of the QAM demodulator 237 is converted to an analog signal by a digital to analog converter (D/A) 363 and sent to the headphones 132. Selection of a particular channel to be listened to by a passenger 117 is made using the tuner 235 that demodulates the signal associated with the selected channel.

[0073] The improved quadrature amplitude modulated (QAM) digital audio distribution provided by this aspect of the present invention provides for a greater number of audio channels to be communicated over the RF cable 215. This is similar to the quadrature amplitude modulation of the video streams discussed above with reference to FIG. 5. The quadrature amplitude modulation provides for a plurality of states (not compression) that increases the usage of the bandwidth of the RF cable 215. Any type of analog input signal may be processed, including signals from the audio tape reproducers 223, passenger address system 222, passenger service system 275 or other analog audio source.

[0074] The area distribution equipment 210 distributes information from the head end equipment 200 to the seat group equipment 220. The area distribution equipment 210 also provides power to the seat group equipment 220. FIG. 6 is a block diagram showing the area distribution equipment 210 in accordance with a preferred embodiment.

[0075] The area distribution equipment 210 distributes data throughout the communications network formed between the head end equipment 200 and the seat group equipment 220. The area distribution equipment 210 comprises the plurality of area distribution boxes 217 that are each coupled to a plurality of floor junction boxes 232 that are individually coupled to respective audio-video seat distribution units 231 in the seat group equipment 220 of respective columns of passenger seats 123.

[0076] In a basic system, the area distribution box (ADB) 217 provides for interfacing the first passenger entertainment system controller (PESC-A) 224a to audio-video units 231 either directly or via floor unction boxes 232. The area distribution boxes 217 interface to the audio-video seat distribution units 231 by way of the junction boxes 232 using full-duplex RS-485 interfaces 218 and RF cables 215. The RS-485 interfaces 218 provide control and data links between the seat group equipment 220 and the head end equipment 200. The RF cables 215 couple audio and video data to headphones 132 and seat displays 122 for listening and viewing by the passengers 117. The area distribution box 217 acts as a connection box to facilitate the distribution of system power, combined audio/video signals and service data for up to five columns of audio-video units 231, and relay of service data and combined audio/video signals to the next area distribution box 217. The area distribution box 217 has an RS-232 serial diagnostic port to allow verification of functionality.

[0077] The area distribution box 217 removes power from a seat column in which either a short circuit or ground fault condition is identified. The area distribution box 217 restores power to a seat column from which power had been removed without requiring physical access to the area distribution box 217. When power is reapplied to such a column, the short circuit protection circuit functions normally and removes power from the column if the short circuit condition persists. An area distribution box 217 processor monitors the status of the AC power output to each individual AVU column for BIT/BITE purposes.

[0078] The area distribution box 217 provides the means to adjust the RF level in order to ensure that the proper RF levels for the video and modulated audio signals are supplied to the AVU tuners and demodulators in the presence of changing system configurations and operational conditions. This RF leveling is accomplished by the local processor/s in the area distribution box 217 by controlling a variable attenuator.

[0079] The area distribution box 217 provides for interfacing voice data, originating at passenger telephones 121c, to the first passenger entertainment system controller 224a. The telephone interface provides for input data from each AVU column to be combined with input data from another area distribution box 217 and retransmitted to the first passenger entertainment system controller 224a or the next area distribution box 217.

[0080] FIG. 7 is a block diagram of exemplary seat group equipment 220 in accordance with a preferred embodiment. The seat group equipment 220 allows individual passengers 117 to interact with the system 100 to view movies, listen to audio, select languages, play games, video conference with others on and off the aircraft 111, and interface with other interactive services.

[0081] The seat group equipment 220 includes a passenger control unit 121, a seat display 122, headphones 132, interface 128a for a personal video player 128 (in certain zones), an audio-video unit 231 with a plurality of seat controller cards (SCC) 269 one for each seat 123 in a row to interface with the area distribution equipment 210, a video camera 267 and a microphone 268 for use in video conferencing, and a telephone card 271 that interfaces to the passenger control unit 121 when it includes the telephone 121c and/or credit card reader 121d. One audio-video unit 231 is provided for each seat 123 and controls distribution of video, audio and data to the headset or headphones 132, the seat display 122, and the passenger control unit 121.

[0082] Referring to FIG. 3, in certain zones of the aircraft 111, a personal computer interface 129a is provided which allows the passenger 117 to power a personal computer (not shown) and to interface to the system 100 through the audio-video unit 231. Alternatively, a keyboard 129b may be provided that allows the passenger 117 to interface to the system 100. The use of the personal computer 129a or keyboard 129b provides a means for uploading and downloading data by way of the satellite communications system 241 and the Internet.

[0083] The major functional requirements of the audio-video unit 231 are that it drives one to three seat display units 122 with or without touch screens, provides touch screen and display controls, provides two audio jacks per seat, provides two passenger control unit interfaces per seat 123, interfaces to a parallel telephone system, provides discrete signal interface, a parallel laptop power supply system, demodulates and tunes NTSC and QAM from the RF signal, provides PC type video games, provides an RS-485 interface for ADB-AVU or AVU-AVU communications, provides an interface for personal video players, and provides a PSS interface to an external parallel passenger service system (PSS), provides hardware and software interfaces that provide for video teleconferencing and Internet communications.

[0084] Referring to FIG. 7, one seat controller card 269 is dedicated to a passenger seat. Therefore, three seat controller cards 269 are required for a three-wide audio-video unit. Two seat controller cards 269 are required for a two-wide audio-video unit 231. A power supply module (PSM) 233 supplies power for the three seat controller cards 269, an audio card 234, the displays 122, and PCUs 121. The audio card 234 electrical circuits comprise RF demodulators to supply audio outputs. An interconnect card (not shown) connects the three seat controller cards 269, the audio card 234, the power supply module 233, and external connectors within the AVU 231.

[0085] The seat controller card (SCC) 269 provides many functions for a single passenger 117. Some of the functions that the seat controller card 269 provides include analog video and audio demodulation, graphics overlay capability, and Motion Picture Experts Group (MPEG) video and audio decompression. The seat controller card 269 provides the ability to demodulate the existing analog video signals as well as MPEG encoded signals delivered by the media server 211 that comprises a video-on-demand (VOD) server.

[0086] The seat controller cards 269 in FIG. 7 and 7a in each audio-video seat distribution unit 231 contain a tuner 235 that downconverts the modulated RF signals to produce intermediate frequency signals containing the NTSC video streams and the quadrature amplitude modulated (QAM) MPEG compressed video streams. A QAM demodulator 237 and an MPEG decoder 238 are used to demodulate and decompress the quadrature amplitude modulated and compressed MPEG compressed video streams to produce MPEG NTSC video and audio signals for display.

[0087] An analog (video) demodulator 236 demodulates the NTSC video signals that are then passed to a video multiplexer 235a where an external NTSC video signal may be added. The NTSC signals are then digitized in a video A/D converter 235b and are passed to the MPEG decoder 238. The format of the digital channels after QAM demodulation is MPEG-2 transport streams. The MPEG-2 transport streams may contain many streams of video, audio and data information. The MPEG decoder 238 (demultiplexer) may also receive data information to be sent to the SCC processor group 272. In the MPEG transport group, the capability exists to add text overlay with the digital video data. The digital data is converted to analog NTSC format using an NTSC encoder 238a for the display 122.

[0088] Each of the seat controller cards 269 includes a microprocessor (mP) 272 that controls the tuner. The microprocessor 272 is used to address the seat controller card 269 as a node on the network. A database is set up in the cabin file server 268 that includes entries for each of the microprocessors (i.e., each seat 123). The addressability feature permits programming of each seat to receive certain types of data. Thus, each audio-video unit 231 may be programmed to selectively receive certain videos or groups of video selections, or audio selections from selected audio reproducers. The addressability aspect of the present system 100 allows the airline to put together entertainment “packages” for distribution to different zones or groups of seats. Also, each seat (or seats in different zones) may be programmed to be able to play games, use the telephones 121c and credit card reader 121d, use a personal video player or computer, have the ability to engage in video teleconferencing and computer data interchange, or gain access to the Internet. Furthermore, the addressability associated with each seat permits order processing and tracking, and control over menus that are available to passengers at respective seats, for example. The addressability feature also permits dynamic reconfiguration of the total entertainment system 100.

[0089] To provide control from passenger seats 123, the microprocessor 272 in the audio-video unit 231 includes software that performs substantially the same functions as those in the primary access terminal 225. This may be achieved by selectively downloading a software module to the microprocessor 269 in the audio-video unit 231 when the passenger 117 requests this service. The downloaded software module operates in the same manner as the software on the primary access terminal 225. However, the RS-485 interface is used to send commands to the cabin file server 268 that control the ARINC-485 driver. Alternatively, and preferably, use of an Ethernet network 228 to interconnect the audio-video units 231 provides a readily implemented control path directly to the primary access terminal 225 and cabin file server 268, since they are normally connected by way of the Ethernet network 228.

[0090] The audio card 234 in FIG. 7 provides several functions. It demodulates the RF signal to provide audio. It has a multiplexer with audio inputs from the seat controller card 269, demodulated RF signal audio, and external audio. It routes the 115 VAC power to the power supply module and routes the DC power from the power supply module 233 to the interconnect card.

[0091] FIG. 7b illustrates a typical fixed passenger control unit 121. The passenger control unit (PCU) 121 interfaces with the system 100 via the audio-video unit (AVU) 231 and provides a passenger interface having input controls 381 and indicators 382. The passenger control unit 121 communicates with the audio-video unit 231 for PCU/AVU data, AVU/PCU data, and power.

[0092] The passenger control unit 121 may be either side mounted or top mounted onto a seat 123 arm rest. The passenger control unit 121 has a four character alphanumeric display 389. Brightness of the LED display 389 is controllable, as a minimum, to two levels of brightness. The passenger control unit display 389 is controlled by the audio-video unit 231 to inform the passenger of current mode status and video functions.

[0093] The passenger control unit 121 also comprises depressible buttons that permit selection of items displayed on the seat display 122 and turn on call lights and overhead lights, and electronics. In designated sections or seats, the passengers also control selection of movies and games that are to be played, control the landscape cameras, and activate video conferencing and data communications. In selected sections (business and first class) of the aircraft 111, the telephone 121c and credit card reader 121d are integrated into the passenger control unit 121, while in other sections (such as coach class) these components are not provided.

[0094] A reading light on/off function key 382a turns on/off an overhead reading light. Call light on and call cancel function keys 382b, 382c permit calling a flight attendant. A volume control (increase/decrease volume) key 383 is provided. A select function key 384 allows the passenger to make a selection. Screen navigation function keys 385 provide a means for a passenger 117 to navigate through menus displayed on the display 122 or seat display unit (SDU) 122a. A channel up/down function key 386 provides for channel control (increase/decrease channel selection). A TV/OFF function key 387 turns the seat display unit backlight on. Pressing a mode function key 388 allows the passenger to have picture adjustment control of the seat video display through menus displayed on the seat display unit 122a.

[0095] The passenger control unit 121 interfaces to the credit card reader 121d. The credit card reader 121d reads three magnetically encoded tracks from credit cards that are encoded in accordance with ISO standards 7810 and 7811. Data content is read in accordance with the VisaNet Standards Manual and contain at least: major industry identifier, issuer identifier, primary account number, surname, first name, middle initial, expiration date, service code, and PIN verification data.

[0096] FIG. 8 is a block diagram of exemplary overhead equipment 230 in accordance with a preferred embodiment. The overhead equipment 230 comprises a plurality of tapping units 261 coupled to the overhead and bulkhead displays 263 and video projectors 262. The overhead equipment 230 uses RF video distribution, wherein the RF signal is distributed from the head end equipment 200 to the overhead equipment 230 via the plurality of tapping units 261 which are connected in series. The tapping units 261 contain tuners 235 to select and demodulate the RF signal providing video for the monitors 263 and projectors 262 coupled thereto. Control is provided to the overhead equipment 230 using an RS-485 interface 264 coupled to the first passenger entertainment system controller (PESC-A) 224a. The information on the RS-485 interface 218 between the first passenger entertainment system controller (PESC-A) 224a and the tapping units 261 is controlled via operator input and protocol software running on the cabin file server 268.

[0097] In order to efficiently implement video teleconferencing, the use of a higher speed, larger bandwidth communication network may be provided to permit many simultaneous uses. This is achieved using a high speed network, such as the 100 Base-T Ethernet network 228 that is currently employed in the head end equipment 200. Interconnection of each of the audio-video seat distribution units 231 by way of a 100 Base-T Ethernet network 228 in addition to, or which replaces the lower bandwidth RS-485 network 218, provides substantial bandwidth to implement video teleconferencing.

[0098] Interconnection of the audio-video seat distribution units 231 using the 100 Base-T Ethernet network 228 also permits data communications between personal computers located at the seats 123 and remote computers 112. This is achieved by interfacing the 100 Base-T Ethernet network 228 to the satellite communications system 241. Intercomputer telecommunications may be readily achieved using a Web browser running on portable computers connected to the audio-video seat distribution units 231, or by integrating a Web browser into the audio-video seat distribution units 231. This is readily achieved by running the Web browser on the microprocessor 272 used in each audio-video seat distribution unit 231. Messages may be drafted using a keyboard 129b connected to the audio-video seat distribution units 231. Touchscreen seat displays 122 may be also readily programmed to initiate actions necessary to initiate videoconferencing, initiate communications, transfer messages, and other required actions.

[0099] Certain line replaceable unit types require the assignment of a unique address within the system 100. This is referred to as line replaceable unit addressing. Line replaceable units that require unique addresses are the PESC-A primary/secondary 224a, PESC-V 224b, video reproducers 227, area distribution box 217, tapping unit. 261, and primary access terminal 225. Each of these line replaceable unit types is assigned a unique address during system installation.

[0100] Referring again to FIG. 2, it depicts the architecture of the system 100, and its operation will now be described with reference to this figure. The architecture of the system 100 is centered on RF signal distribution of video, audio, and data from the head end equipment 200 to the seat group equipment 220. Video and audio information is modulated onto an RF carrier in the head end equipment 200 via the video modulator 212a and passenger entertainment system controllers 224a, 224b respectively prior to distribution throughout the aircraft 111. Referring again to FIG. 5, it shows a functional block diagram of the signal flow to and from the head end equipment 200.

[0101] The source of video may be from video cassette players 227, landscape cameras 213, and the TV video output by the media server 211, or the passenger video information system 214. The source of audio information may be from audio reproducers 223, audio from video cassette players 227, or audio from the passenger address system 222.

[0102] The system 100 uses the RF network 215 to distribute all audio and video programming from the head end equipment 200 to the seats 123. The RF network 215 is also used to support downloading of video games and other applications to the seats 123.

[0103] The RF network 215 operates over a nominal frequency range from 44 to 550 MHz. The system 100 provides up to 48 6-MHz wide channels for distribution of video information. One of these channels may be used for the distribution of video games and other application software to the seats 123. The video channels are allocated to a bandwidth from 61.25 through 242.6 MHz (nominal). The frequency range from 108 to 137 MHz (nominal) remains unused.

[0104] The frequency range from 300 to 550 MHz is used for distribution of audio information to the seats 123. One embodiment of the system 100 uses pulse code modulation to transmit the audio data over the allocated frequency range. This supports a maximum of 88 mono audio channels (83 entertainment and five PA). The allocation of these channels to audio reproducers 223 (entertainment audio), video reproducers 227 (movie audio tracks) and to passenger address lines (PA audio) is database configurable and may be defined by the user. It is also possible to read and set RF levels for the passenger entertainment system controllers 224a, 224b and area distribution box 217 by means of an off-line maintenance program.

[0105] The system 100 uses the ARCNET network 216 as the major data communications path between major components. The ARCNET network 216 interconnects the following components: cabin file server 268, primary access terminal 225, PESC-A (primary) 224a, PESC-A (secondary) 224a, PESC-V 224b, and all the area distribution boxes 217.

[0106] The ARCNET network 216 is implemented as two physical networks, with the primary PESC-A 224a serving as a bridge/router between the two. Any device on ARCNET 1 216 is addressable by any device on ARCNET 2 216 and vice versa. In addition to the primary PESC-A 224a, ARCNET 1 216 connects the following components: cabin file server 268, and a maximum of eight area distribution boxes 217. In addition to the primary PESC-A 224a, ARCNET 2 224b connects the following components: a maximum of one PESC-V 224b, primary access terminal 225, and the secondary PESC-A 224a. Both ARCNET subnetworks (ARCNET 1, ARCNET 2) 216 operate at a data transmission speed of 1.25 Mbps.

System Operation

[0107] A preferred embodiment of the in-flight entertainment system 100 operates in three possible states. These states include 1) a configuration state, 2) a ground maintenance state, and 3) an entertainment state. In the configuration state, aircraft-installation-unique parameters are initialized and modified. The configuration state is initiated by an operator. The configuration state is entered and exited without the use of additional or modified system hardware. In the ground maintenance state, the system 100 performs self-diagnostics to determine system failures. The ground maintenance state is initiated by an operator. The ground maintenance state is entered and exited without the use of additional or modified system hardware. The entertainment state is the primary state of the system 100 and is initiated by the operator. The system 100 provides several entertainment modes as defined below. The system 100 is modular in design so any one or all modes may exist simultaneously depending on the configuration of the system 100. The system 100 is configurable so that each zone (first class, business class, coach class, for example) of the aircraft 111 can operate in a different entertainment mode. In the entertainment state, the passenger address functions and passenger service functions are independent of the mode of operation.

[0108] The entertainment modes include an overhead video mode, a distributed video mode, and an interactive video mode. In the overhead video mode, video is displayed in the aircraft 111 on the overhead monitors 263. Different video entertainment is possible for different sections of the aircraft. In the distributed video mode, multiple video programs are distributed to the individual passengers of the aircraft at their seat. The passenger selects the video program to view. The quantity of programs available depends upon system configuration. In the interactive video mode, the system 100 provides a selection of features in a graphical user interface (GUI) presentation to the passenger. Depending on the system configuration, the features may include language selection, audio selection, movie selection, video game selection, surveys, and display settings.

[0109] The system 100 provides audio programming to the passengers. When in the interactive audio mode of operation, the system 100 displays a list of audio programs available to the passenger on the seat display 122. This list is configurable via an off-line database. The system 100 may be configured to allow selection of an audio program using either the seat display 122 or controls on the passenger control unit 121 depending on the system 100 requirements. The selected audio program is routed to the corresponding passenger headphone 132.

[0110] The system 100 provides video programming to all passengers 117. When in the interactive video mode of operation, the system 100 displays a list of video programs available to the passenger on the screen of the seat display unit 122a. This list is specified via an off-line database. The system 100 may be configured to allow selection of a video program using either the seat display 122 or controls on the passenger control unit 121 depending on the system requirements. The selected video program is routed to the corresponding seat display unit 122.

[0111] When in the interactive mode of operation, the system 100 provides video games to the passengers 117. The system 100 displays a list of up to 10 video games available to the passenger on the seat display 122. This list is specified via an off-line database. The system 100 may be configured to allow selection of a video game using either the seat display unit 122a or controls on the passenger control unit 121 depending on the system requirements. The selected video game is downloaded to the corresponding passenger seat 123 for viewing on the seat display 122.

[0112] The system 100 supports entertainment packaging. An entertainment package is a predetermined set of one or more movie titles and/or game titles with a predetermined amount of game play time. The content of each entertainment package is specified via an off-line database. The system 100 requires payment for entertainment packages according to a unit price and a price policy. The system 100 displays a list of available packages on the screen the seat display unit 122a. Each package in this list must have an associated date range that specifies when the package is available. Up to four packages per date range are specified via an off-line database. The displayed list only contains those packages where the date of the current flight falls within the date range specified for that particular package.

[0113] As is shown in FIG. 7, for example, if configured with a personal video player 128 that interfaces to the audio-video unit 231 by way of a personal video player interface 128a, the system 100 controls the personal video player 128 via controls at the seat display 122. The system 100 provides commands to the personal video player 128 to play, rewind, fast forward, pause, stop and eject a tape.

[0114] The system 100 provides the ability to place telephone calls from each passenger seat 123. In certain configurations, the telephone handset is integrated into the passenger control unit 121. The handset includes a telephone button pad, a microphone, and a speaker. The system 100 prompts for payment when using the telephone service. Payment must be made via a credit card. The system 100 provides the capability to enter the phone number via controls on the passenger control unit 121. The system 100 also displays phone call status on the screen of the seat display 122.

[0115] The system 100 provides the ability for passengers 117 to select items from an electronic catalog displayed on the screen of the seat display 122. The catalog may be divided into categories. The system 100 provides the capability to configure the categories and the items via an off-line database tool.

[0116] The system 100 provides the capability to display on the screen of the seat display 122 a running tabulation of all expenses, excluding telephone charges, incurred at a seat during the current flight.

[0117] The system 100 is configured to allow the flight attendants to display flight information at the primary access terminal 225 from the off-line database or retrieved from other equipment on-board the aircraft 111. If this information is not available, the system 100 is configured to allow information to be entered manually at the operator console as detailed below. Flight information may include the following: aircraft registration number, flight number, departure airport, arrival airport, flight duration, and route type.

System Software

[0118] The system 100 employs a software architecture that integrates processing performed by each of the subsystems. The software and firmware comprising the software architecture controls the system, manages the flow of analog and digital audio and video data to passenger consoles and displays, manages the flow of communications data, and manages service and order processing. Various subsystems also have their own software architectures that are integrated into the overall system software architecture.

[0119] The system software is designed in a layered fashion, and an application programming interface (API) layer is defined and documented for the primary access terminal 225 and seat display 122. These application programming interfaces are used as the foundation upon which to implement the graphical user interfaces (GUIs). The GUIs are thus implemented in a manner that facilitates rapid prototyping and GUI modification within the constraints of the services provided by the application programming interfaces. The system 100 has a flight attendant GUI at the primary access terminal 225 and passenger GUIs at the seat 123 (seat display unit 122a). Each of these GUIs have the following properties: graphic orientation, clear and directly selectable functions (no “hidden” functions), consistency in screen layout and flow (look and feel), and “lexical” feedback (i.e., visible change on the display) for every user action.

[0120] Many of the line replaceable units in the system 100 are software loadable in that the contents of the line replaceable unit's memory can be overwritten from a source external to the line replaceable unit. The system 100 provides a facility for loading software into all line replaceable units. The software loading facility ensures that any attempt to load software into a line replaceable unit is appropriate for that type of line replaceable unit. The software loading function indicates when a line replaceable unit can and can not be loaded, the status of software load attempts as either successful or unsuccessful, and an estimate of the time required to load the software into the line replaceable unit. The software load facility employs a high speed download link to the line replaceable units, when appropriate, in order to minimize the time required to load software into a line replaceable unit. The software loading facility precludes load attempts when the aircraft 111 is in flight.

[0121] Software and firmware employed in the present invention permits credit card processing, data collection processing, Internet processing for each passenger, gambling for each passenger, duty free ordering, intra-cabin audio communication between passengers, and display of flight information. The system software includes parallel telephone system software, landscape camera management software, PESC system software, passenger address override software, passenger address emergency software, monetary transaction processing software, language support software, built-in-test software, user request processing software, database management software using a distributed configuration database, software for implementing interactive access, software for processing passenger orders, software for updating inventories, application software, media file encryption software, area distribution box software, audio-video unit programming software, telephone operation software, gatelink node and software, product service pricing software, passenger survey software, transaction reporting software, automatic seat availability reporting software, and video conferencing and data communications software.

[0122] Object oriented programming (OOP) is employed in the software and firmware used in the system 100. A preferred embodiment of the software used in the system 100 is written using JAVA, C, or the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a passenger entertainment system such that a set of OOP classes and objects for the messaging interface can be provided.

[0123] The system 100 is constructed in a modular framework, and is designed to expand to support various aircraft 111 configurations. System configuration information is defined in an off-line configurable database. System configuration support tools provide the capability to generate database information, which is downloaded to the appropriate system line replaceable units. The line replaceable units store database information in non-volatile memory, and revert to default database information when they detect newly downloaded data inconsistent with the physical aircraft configuration, or when a database download is unsuccessful.

[0124] Aircraft configuration data requires modification only when the aircraft configuration changes, or when the line replaceable unit in which it resides has been replaced or corrupted. Aircraft configuration data at a minimum includes the following fields: Aircraft type, ACS database configuration ID, Overhead system type, Seat configuration, tapping unit and Overhead monitor assignments, Reading/Call light assignment, Master call lamps/attendant chimes data, RF level gain values, Internal ARCNET termination, PA/VA headphone, APAX-140-to-TES interface assignments, PESC audio channel assignments, VMOD video channel assignments, ADB phone capability, ADB discretes, PA zone, display controller, configuration of passenger entertainment system controllers 224, interactive/distributed video only (DVO), PAT/CFS options, and movie preview.

[0125] The entertainment system data define specific parameters for the available system features. It is necessary to reload the database whenever it is determined the associated features are to be changed. Entertainment system data, at a minimum, includes the following fields: Entertainment system data configuration ID, Video games, Movies, Pay/Free entertainment per zone, Passenger surveys per zone, General service/Duty free zones, seat display unit entertainment titles per route type, Currency exchange rates, primary access terminal display currency, Airline name, flight number, arrival/departure city, flight duration, and route type, Movie cycle attributes, Video announcements, video reproducer entertainment assignments, Product data, Credit card data, and Entertainment package details.

[0126] FIG. 9 is a block diagram of the ACS tool and shows its functionality. The ACS tool provides hardware, user, software, and database interfaces as described below. The ACS tool supports the following hardware interfaces. The ACS tool supports a standard 101 key PC keyboard for the PC application and the primary access terminal standard keyboard. The ACS tool supports a standard MICROSOFT mouse, or equivalent, for the PC application. The off-line configuration database tools support generation of all downloadable configuration data. Airplane Configuration System (ACS) tools are used to generate aircraft configuration system data. The ACS tool is executable on an IBM-compatible 486 PC running MICROSOFT WINDOWS 3.1 or a later version. The ACS tool produces downloadable data file on media that may be directly input via the primary access terminal 225 or a maintenance PC connected to a test port.

[0127] The ACS tool provides the following user interfaces. In general, the graphical user interface includes a series of screens with buttons and other controls and indicators. Screens, buttons, other controls, and indicators follow the general conventions for WINDOWS screens as described in The Windows Interface Guidelines for Software Design. The GUI provides user access to the ACS tool's functions via keyboard and mouse inputs.

[0128] The ACS tool provides the functionality to maintain multiple configurations for all the aircraft types the TES 100 and APAX-150 systems support. The ACS tool is a single executable, regardless of aircraft type. This single executable utilizes a configuration file for pre-initialization of aircraft configuration data (.CFG). It also utilizes a WINDOWS.INI file for ACS tool-specific parameter definition.

[0129] The ACS tool generates configuration data files that can be distributed to the TES line replaceable units. The applicable data files may be downloaded upon operator request via the MAINT Utility.

[0130] The ACS tool provides the ability to create and change an aircraft configuration by the use of menus, list boxes, data entry screens, utilities, error messages and help functions. An aircraft configuration defines what TES devices are installed on the aircraft, where those devices are located and what functions those devices perform.

[0131] The PESC-A 224a, PESC-V 224b, area distribution box 217, ADB local area controller (ALAC) (not shown), AVU/SEB 231, and overhead electronic box (not shown) line replaceable units, as well as the primary access terminal 225 and cabin file server 268, the MAINT and Config/Status utilities all require knowledge of the aircraft configuration. The database created by the ACS tool that can be downloaded into the PESC-A 224a and contains the configuration data needed by the PESC-A 224a, PESC-V 224b, area distribution boxes 217, ALACs, AVUs/SEBs 231, tapping units 261, and overhead electronics boxes. The ACS tool has the capability to create separate configuration data files for the primary access terminal 225 and cabin file server 268 and the MAINT and Config/Status Utilities.

[0132] The ACS tool also has the capability to create downloadable data files that can be loaded directly into the area distribution boxes 217. The data files that the ACS tool creates for the primary access terminal 225 and cabin file server 268 are able to be imported by the primary access terminal 225 and cabin file server 268 into its database. These files provide information about the aircraft 111 so that interactive services can be provided to the passengers.

[0133] The ACS tool creates a downloadable data file (.INT File) that is able to be used by the MAINT and Config/Status Utilities to determine system-wide LRU status, software configuration, and diagnostic information. These utilities require system configuration definition data.

[0134] The ACS tool provides a configuration editor function that allows the user to modify an existing aircraft configuration or generate a new aircraft configuration by entering values into displayed data fields or by selecting values from drop-down menus, if applicable. The configuration editor allows the user to import, or copy, selected aircraft configuration data from one configuration to another. “cut” and “paste” operations are provided so that similar or identical configuration entries may be copied from one configuration to another. The configuration editor validates the value entered for each data field. The ACS tool generates error messages when the user enters invalid data in dialog boxes. The configuration editor provides the capability to save a configuration to disk. The ACS tool provides the capability to initiate a configuration validation test. If the validation test finds errors with the data, a detailed error report is displayed. The ACS tool allows a configuration that is INVALID to be saved to disk (.CFG), but the ACS tool does not allow a downloadable database to be built from a configuration that is INVALID.

[0135] A configuration data builder function of the ACS tool System provides the capability to generate downloadable configuration data files for use with the system 100 and peripherals. When the user attempts to create the downloadable data files, the ACS tool performs a validation check and tests for limits.

[0136] A reports generator function of the ACS tool provides the capability to generate, for a specified configuration, a validation report and a configuration report. A validation report contains information defining the validity of a specified configuration, including appropriate messages for entries in the configuration which are currently invalid. A validation report may be generated upon user request or upon request to generate download files. The configuration report provides a detailed report which describes the current configuration. The configuration report is generated only when a request to generate download files is made and the current configuration is determined to be valid.

[0137] A create floppy disk function of the ACS tool provides the capability to generate a disk that contains all files generated by the ACS tool. These downloadable configuration files are loaded to the various line replaceable units in the system. The diskette also contains a setup utility that can be run from the primary access terminal 225 to reinitialize the database on the cabin file server 268 with a new configuration.

[0138] Each line replaceable unit that uses the database contains electrically erasable programmable read-only memory (EEPROM) which are “downloaded” with the database. This means that the database which contains information about the airplane configuration can be passed to each controller (i.e., downloaded). These controllers include the PESC-A 224a, PESC-V 224b, area distribution boxes 217, ALACs, SEBs (AVUs) and overhead electronic boxes.

[0139] Many different configurations can be stored for an aircraft 111. Each contains slightly different options, such as the seating configuration. The ACS tool enables the different configurations, after established, to be recalled season after season by allowing the user to select an existing configuration to edit when a change is made to the aircraft 111 during re-configuration. The ACS tool allows the user to create a new configuration that can subsequently be saved.

[0140] Presented below is software design information for a set of programs common to the cabin file server 268 and primary access terminal 225 LRUs of the system 100. The software forms the fundamental mechanism of moving application information through the system 100. The following description will be readily understood to those familiar with C++ and the WINDOWS NT development environment. Reference is made to FIG. 10, which illustrates a block diagram of the software architecture in accordance with a preferred embodiment. The architecture facilitates a control center runtime that is implemented in C++ for the primary access terminal 225 and the cabin file server 268 of an in-flight entertainment system 100.

[0141] As for the primary access terminal 225, an uninterruptable power supply 400 is used to provide power to the primary access terminal 225 and is in communication with the programs in the software architecture using a serial NT driver 401. A PI board 402 provides a communication port for the magnetic card reader and video tuner and interfaces to the serial NT driver 401. The tuner 235 in the audio-video unit 231 also interfaces to the serial NT driver 401. The video camera 267 coupled to the audio-video unit 231 is also coupled to the serial NT driver 401. The serial NT driver 401 also interfaces with the PESC-V 224b. An ARCNET driver 408 interfaces to the ARCNET network 216.

[0142] The serial NT driver 401 and ARCNET driver 408 interface to an I/O handler 403 to provide selective communications between a message processor 404 and the various communications devices (400, 402, 235, and 267). The message processor 404 is responsible for processing messages and putting them into a common format for use by a transaction dispatcher 421. A pipe processor 405 is utilized to move common format messages from the message processor 404 through a primary access terminal network addressing unit (NAU) program 409 and through another pipe processor 420 into the transaction dispatcher 421. The message processor 404 also interfaces to a system monitor 412 that is coupled to a watch dog driver 410 that is used to automatically reset the primary access terminal 225 if no activity is detected in a given time interval, and a power down module 414 that performs graceful power down of the primary access terminal 225. The transaction dispatcher 421 interfaces with a cabin application programming interface (CAPI) library DLL 427 by means of a CAPI message service handler 422.

[0143] A touch panel NT driver 424 interfaces with runtime utilities 425 and a graphical user interface (GUI) 426 to provide operator control over the software. The runtime utilities 425 and graphical user interface 426 interface to the CAPI library DLL 427, a Reports DLL 429 and a video driver DLL and system (SYS) 430.

[0144] The Ethernet network 228 is used for messaging between the primary access terminal 225 and the cabin file server 268. The Ethernet network 228 interfaces to the primary access terminal network addressing unit 409, the transaction dispatcher 421, the CAPI Library DLL 427, and the Reports DLL 429.

[0145] As for the cabin file server 268, an uninterruptible power supply 440 is used to provide power to the cabin file server 268 and is in communication with the programs in the software architecture using a serial NT driver 447. The serial NT driver 447 is also coupled to an auxiliary port 441 and the video reproducers 227. An ARINC-429 NT driver 448 is coupled to the satellite broadcast receiver 240 and the satellite communication system 241. An ARCNET driver 450 interfaces to the ARCNET network 216. A high-speed data link (HSDL) NT driver 449 interfaces to the video modulator 212a.

[0146] The serial NT driver 447, ARCNET driver 450 and ARINC-429 NT driver 448 interface to an I/O handler 451 to provide selective communications between a message processor 452 and the various communications devices (440, 441, 227, 216, 212a). The message processor 452 is responsible for processing messages and putting them into a common format for use by a transaction dispatcher 473. A pipe processor 456 is utilized to move common format messages from the message processor 452 through various network addressing units 461-465 and through another pipe processor 470 into the transaction dispatcher 473. The network addressing units 461-465 include a test port NAU program 461, a VCP NAU program 462, a backbone NAU program 463, an ARINC-485 NAU program 464 and a seat NAU program 465.

[0147] The message processor 452 also interfaces to a system monitor 454 that is coupled to a watch dog driver 446 that is used to automatically reset the cabin file server 268 if no activity is detected in a given time interval, and a power down module 455 that performs graceful power down of the cabin file server 268. Each of the network addressing units 461-465 is coupled to the system monitor 454. The system monitor 454 is also coupled to the transaction dispatcher 473. The transaction dispatcher 473 interfaces with CAPI services 477 that are called from the CAPI message service handler 422 in the primary access terminal 225. The transaction dispatcher 473 also interfaces to the primary access terminal 225 by way of the Ethernet network 228.

[0148] Cabin Application Programming Interface (CAPI) calls 476 are used to communicate information (as shown by arrow 475) between various cabin services 477 and the primary access terminal 225 via the Ethernet network 228 and various service interfaces. The separate communication link for the crystal reports DLL 429 is enabled through object oriented data base calls 434 to the Standard Query Language (SQL) server 492. The cabin services 477 include CAPI calls 476 with predefined formats for various services. The services include in-flight entertainment (IFE) control 478, movie cycle 479,video services 480, video announcement 481, game rental 482, movie sales 483, catalog sales 484, drink sales 485, duty-free sales 486, landscape camera 487, media server 488, Internet 489 and teleconferencing 490. Each of these services are controlled by way of the SQL server 492 which is coupled to a relational database 493 and are configured by means of runtime database utilities 491. The various services 478-490 are routed by way of the pipe processor 474 to the transaction dispatcher 473, through the associated NAU program 461-465, the message processor 452, and the relevant driver 447, 448, 449, 450, to the appropriate device 440, 441, 227, 240, 241, 216, 212b.

[0149] More specifically, the cabin file server 268 and primary access terminal 225 software comprises a control center common executive that includes the message processors 404 and 452, transaction dispatchers 421 and 473, and network addressable unit (NAU) programs 409, 461-465 that together manage communications flow among line replaceable units and applications, and record or log system irregularities for subsequent analysis. The control center common executive efficiently moves information from source to destination with a minimum of system resources, provides real-time expense or over-handling, provides a means to allow communications to originate at any source, including periodic status messages such as those to the primary access terminal 225 from the video players 227, and provides a consistent method of handling existing line replaceable units while allowing for additional line replaceable units. In addition, the common executive stores drivers that are not already part of the operating system. The system monitors 412 and 454 are provided to launch all application programs and shut them down as needed.

[0150] Each line replaceable unit type that communicates with the control center common executive has a corresponding network addressable unit (NAU) program 461-465. For example, any seat 123 that must communicate routes to the seat NAU program 465, any video cassette player 227 routes to the VCP NAU program 461, etc. Each time a line replaceable unit communicates with an NAU program 461-465, a virtual LRU is used to maintain cohesion between the application (service) and the device (driver). The virtual LRU is a state machine, one for each physical device associated to this NAU type. For example, if two seats “001A” and “021J” are communicating with the control center common executive, two virtual seat LRUs exist within the seat NAU program 465. It is within this state machine that the actual conversion between IFE-message and native messages takes place. Status and other information regarding each line replaceable unit are maintained in the VLRU.

[0151] In addition to the device-initiated VLRUs, several VLRUs are provided whose function is to maintain the status of related devices. For example, the primary access terminal 225 must constantly monitor the status of the printer, so a VLRU for the printer is used in primary access terminal NAU program 409. Similarly, the seats must be kept apprised of changes to the states of the system, so a VLRU for broadcasting this information is created in the seat NAU program 465.

Primary Access Terminal

[0152] The primary access terminal executive extension set of routines that, together with the common executive software, form the generic application for the primary access terminal 225.

[0153] The message processor 404 is shown in FIG. 11, which illustrates the message processor function and data paths. The message processor 404 interfaces a plurality of device drivers 531, including an ARCNET driver 531a and a serial NT driver 531b. The device drivers 531 are coupled to a plurality of device handlers 532. The device handlers 532 include MessageFromDrivers( ) 532a and MessageToDrivers( ) 532b. The MessageToDrivers( ) 532b associated with the serial NT driver 531b is coupled to a ToDriverQueue 532c, and the MessageToDrivers( ) 532b associated with the serial NT driver 531a is coupled to an ArcnetHandler FIFO 532d.

[0154] A NAU server 535 is provided that includes two named pipes (or communication lines) having a plurality of InPipeProcessors( ) 535a and OutPipeProcessors( ) 535b. The InPipeProcessors( ) 535a and OutPipeProcessors( ) 535b are coupled by way of a plurality of pipes 537a to NAU clients 533. The respective InPipeProcessors( ) 535a are coupled to a corresponding plurality of NAU out FIFO queues 538.

[0155] A plurality of routers 537 coupled the device handlers 532 to the NAU server 535. The plurality of routers 537 include the AddMessageToPipeProcessor( ) 536, an AddMessageToOutQueue( ) 539a, and a MessageToHander( ) 539b. The MessageFromDrivers( ) 532a of the device handlers 532 are coupled to the MessageToPipeProcessor( ) 536. The InPipeProcessors( ) 535a are coupled to the MessageToHander( ) 539b. The AddMessageToPipeProcessor( ) 536 and the MessageToHander( ) 539b are coupled to the LRU table 534.

[0156] The primary duty of the message processor 404 is to move communications between various I/O devices and their appropriate logical devices, the network addressable unit (NAU) 533. This duty is assigned to the message processor 404 instead of residing with the NAUs 533 because there is no one-to-one correspondence between the NAUs 533 and the device drivers 531. For example, several devices' communications may arrive via an ARCNET driver 531a (i.e., passenger entertainment system controller 224, seat 123, area distribution box 217, and AVU/SEB 231).

[0157] To support this duty, the message processor 404 includes the following sub-functions. Using an I/O handler 532, the message processor 404 receives messages from the device drivers 531. Each message, regardless of original format must contain a destination or network address for routing purposes. Using this network address coupled with the device type (i.e., ARCNET, RS-232, etc.) the network address determines the appropriate NAU via a look-up table 534 and routes the message to that NAU. Since communications from the devices employ a variety of protocols, they are bundled into an IFE-message upon receipt from the physical device, and unbundled after receipt from the application services (via the NAUs). In this way, the message processor 404 acts as a system translator. Using named pipes 535a and 535b, the message processor 464 receives messages from the NAUs. The message processor 404 determines the appropriate device driver 531 and network address and routes the message to the device. As NAUs demand, the message processor 404 creates two named pipes 535a (input) and 535b (output) for each NAU, maintaining the table 534 of pipe names (or handles) and their corresponding NAU IDs. The message processor 404 logs invalid destination address errors. The message processor 404 registers with the system monitor 412 for coordinated system operation.

[0158] The detailed design of the Message Processor 404 will now be discussed. MP.EXE is the Message Processor and comprises the following files:

- [0159] ARCNTCLS.CPP The ARCNET interface Class
- [0160] ARCSMCLS.CPP The ARCNET Simulator Class for testing
- [0161] DVCHNDLR.CPP The Device Handler Class
- [0162] MSSGPRCS.CPP The Message Processor Class and Main( )
- [0163] PPPRCSSR.CPP The Pipe Processor Class
- [0164] SRLCLASS.CPP The Serial Driver Class
- [0165] WNRTTLCL.CPP The WinRTUtil Class
- [0166] ARCNTDRV.RT The ARCNET User-side Driver

[0167] A Main( ) function used in the message processor 404 initializes its processing threads using StartHandlers( ) and PipeProcessorClass::StartNAUThread( ) functions. These threads operate continuously to move data from source to destination. Main( ) also registers its existence with the system monitor 412 program (using MessageProcessorClass:Register( )) and waits for a shutdown signal from the system monitor 412, after which it performs an orderly shutdown of all its threads.

[0168] For each device driver 531, a Device Handler Class member is created. ArcnetClass defines Device Handler routines for the ARCNET driver 531a. The ARCNET driver 531a is a user side driver that performs the actual I/O with the ARCNET hardware. Because it is loaded along with the rest of the message processor 404, its interface is via Queue::Put( ) and Queue::Get( ) functions. SerialIOClass defines the Device Handler routines 532 for a serial device driver 531b. The serial driver 531b is a standard WINDOWS NT Serial Device Driver. ReadFile( ) and WRiteFile( ) are the functions used to communicate with it. All Device Handlers 532 in the Message Processor 404 provide the following capability. Two Input-Driven threads are provided to control I/O. The names vary from handler to handler, but these functions launch the infinitely looping threads that constantly wait for data to move between the device (or queue) and the Message Processor 404.

[0169]


Handler	Launch Function Name	Thread Function

Serial	SerialInputInterface( )	MessageFromDriver( )
Device	SerialOutputInterface( )	MessageToDriver( )
ARCNET	MessageToHandlerThreadProc( )	MessageFromDriver( )
Device
	MessageFromHandlerThreadProc( )	MessageToDriver( )

[0170] To receive data from the device drivers 531, MessageFromDriver( ) 532a reads a message from its associated driver 531a or 531b using Get( ) or ReadFile( ) functions. It converts the input to a valid IFE Message using functions from the IFE_Message Class or ARCNET_Message Classes. It then calls MessageProcessorClass::MessageToPipeProcessor( ) 536 to add the message to the NAU Output Queue 538.

[0171] To put data to an output queue 532c and 532d, PutToHandler( ) puts a valid message at the end of the output queue 532c and 532d of its associated driver. It does not perform any data conversion.

[0172] To output queued data to a device driver 531, MessageToDriver( ) 532b reads the output queue 532c and 532d and issues the appropriate driver output command. It does not perform any data conversion.

[0173] To start the handler to open communications to I/O ports, StartHandler( ) performs the necessary initialization to get queues, pointers and driver connections ready. It then starts-up the two I/O threads (InPipeProcessor( ) 535a and OutPipeProcessor( ) 535b).

[0174] The term NAU Server means the set of routines that comprise a “server” for the Network Addressable Unit processes. They are kept in the PipeProcessorClass. Two threads, NAUInThread( ) and NAUOutThread( ) are used to launch the set of I/O threads (InPipeProcessor( ) 535a and OutPipeProcessor( ) 535b) for an as yet unknown NAU process. The first message received from any NAU registers it to this set of threads, causing NAUInThread( ) and NAUOutThread( ) to launch another set, getting ready for the next NAU to speak. In this way, the Message Processor 404 is dynamic and can support different numbers of NAUs as needed.

[0175] As for incoming messages, NAUInThread( ) launches the InPipeProcessor( ) thread 535a which continuously receives a message from its input pipe 537b. If the message is meant to be routed to a driver 531, it gets sent to MessageToHandler( ) 539b which places it on the appropriate driver's output queue 532c. If the message is meant to be routed back to an NAU, it is sent instead to AddMessageToOutQueue( ) 539a which performs this routing.

[0176] As for outgoing messages, NAUOutThread( ) launches the OutPipeProcessor( ) thread 535b which continuously reads a message from the NAU Out Queue 538 and sends it to its associated NAU process via its named pipe 537a.

[0177] Routers 537 are routines that use the LRU table 534 to determine which processing thread needs to process the message. One router 537 is a From-NAU Router. Upon demand, MessageProcessorClass::MessageToHandler( ) 539b moves the message to the appropriate handler. If necessary, it converts the message to the appropriate ‘native’ syntax using functions from IFE_Message Class or ARCNET_Message Class. It calls appropriate PutToHandler( ) function to move the converted message to the handler's output queue 532c. Another router 537 is a From-Device Router. Upon demand, PipeProcessorClass::AddMessageToOutQueue( ) 539a calls the appropriate PutData( ) function to move the message to the NAU's output queue 538.

[0178] The LRU table 534 is an internal memory structure which contains an entry for each device in the system 100. It contains sufficient information to translate message addresses from NAU-to-Driver and Driver-to-NAU. Specifically, it contains a physical name, which is the name of each device (e.g., 001A for seat 1A); NAU Type, which is the NAU that processes message (e.g., 7 corresponds to SeatNAU); Network Address (e.g., 4F040552 for seat 1A's seat display unit 122); and Device Handler that indicates which device driver 531 to use (e.g., 0 for ARCNET). This information is kept in a SQL database table which is read during the Message Processor Main( ) initialization via CreateLRUTable( ).

[0179] As NAU processes register with the Message Processor 404, their identities are updated in this table via PipeProcessorClass::AddQueueInfoToLookUpTable( ), PipeProcessorClass::AddThreadPointerToLookUpTable( ) and PipeProcessorClass::AddPipeHandleToLookUpTable( ) functions, which include Pipe Handle, Thread Class, Registeree, Queue Class, and Queue Semaphore.

[0180] ARCNET is the token-passing network that provides the primary communication link between the Control Center and the backbone of the system 100. The ARCNET driver 408 and 450 is software that provides the interface between the message processor 404 and 452 and the physical ARCNET device interface in the cabin file server 268 or the primary access terminal 225. The description below is for the primary access terminal 225.

[0181] For development efficiency, the ARCNET driver 408 has been attached to the message processor 404. The ARCNET driver 408 performs the following. The ARCNET driver 408 obtains a network address of this line replaceable unit. The ARCNET driver 408 understands network addresses for up to 8 cabin file servers 268 and up to 8 primary access terminals 225, to provide for future growth. The ARCNET driver 408 initializes the ARCNET device to proper configuration. The ARCNET driver 408 signs-on to the network. The ARCNET driver 408 handles network reconfigurations and builds up network map to obtain information for routing messages across multiple ARCNET networks. The ARCNET driver 408 deals with transmit handshaking exceptions that may occur.

[0182] The ARCNET device is an SMC COM20020 Universal Local Area Network Controller, the same device as used in all backbone line replaceable units. The network speed is 1.25 Mbps. The 256-byte ARCNET packet (short packet format) is employed. A 2 KB internal device RAM is divided into two 256-byte pages: 1 receive buffer and 1 transmit buffer. The rest is currently not used. The line replaceable units are arranged in 2 ARCNET networks 216, one each supported by the primary access terminal 225 and the cabin file servers 268. The ARCNET driver 408 supports this variability.

[0183] FIG. 12 illustrates the operational flow of the ARCNET Driver 408. The ARCNET driver 408 is part of MP.EXE and comprises the following source file: ARCNTDRV.RT the ARCNET Driver Source. This file is pre-processed using WinRT (see the make file) to incorporate the necessary additional functionality.

[0184] To use the ARCNET driver 408, a user first calls ArcnetDriverClass::StartDriver( ) 601 to initialize this driver and its device and establish queues 607, 606 to be used to transmit and receive data.

[0185] FIG. 12 illustrates the operational flow of the ARCNET Driver 408, where StartDriver( ) 601 launches I/O (receive, transmit) threads 604, 605 and an interrupt handler 603, and StopDriver( ) 602 shuts them all down.

[0186] A discussion follows regarding the Network Addressable Units (NAU) that reside on the primary access terminal 225. The primary access terminal 225 Network Addressable Unit program 409 function and data paths are shown in FIG. 13. The primary access terminal NAU 409 provides the interface between the PAT GUI 426 or the Application Services and the unique devices attached to the Primary Access Terminal 225. Each of these devices is controlled via its own Virtual LRU (VLRU) set of functions. In addition, most of these devices communicate via the same I/O channel, the PI Mux 402. The VLRUs are listed below.

[0187]


Audio Tuner	The Audio Tuner VLRU allows control of audio channel
VLRU	selections for flight attendant previewing via the PAT GUI.
Card Reader	The Card Reader VLRU collects and forwards data from
VLRU	the card reader, to be used by the Access Functions and
	Sales Services' Functions.
GUI Monitor	No LRU is actually associated with this VLRU. The GUI
VLRU	Monitor VLRU's duty is to start the GUI and end the GUI
	as appropriate.
PAT VLRU	The PAT VLRU responds to loopback messages from the
	CFS TestPort NAU via Ethernet for BIT functionality. It
	logs communication failures between the PAT and the CFS.
	It controls the BITE and COMM LEDs on the front of the
	PAT, lighting them to indicate failures.
Printer	The Printer VLRU periodically queries the Control Center
VLRU	Printer for its status and provide this status as an
	unsolicited message to the PAT GUI.

[0188] PAT.EXE contains the primary access terminal NAU program 409. In general, a network addressable unit program must first construct a NAUDispatch object and then construct one or more NAU objects, one for each virtual LRU (VLRU) that it supports. Certain VLRU-specific functions (such as NAU::StartItUp( )) must be created for each VLRU type. The primary access terminal NAU program 409 includes the following primary components:

- [0189] PAT. CPP The Main( ) Program
- [0190] PDSPATCH.CPP The NAU Dispatcher
- [0191] GUMNITOR.CPP The GUI Monitor VLRU Class
- [0192] CRDRDRVL.CPP The Card Reader VLRU Class
- [0193] TUNRVLRU.CPP The Audio Tuner VLRU Class
- [0194] PATVLRU.CPP The PAT main VLRU Class
- [0195] PRNTRVLR.CPP The Printer VLRU Class
- [0196] PRNTRSTT.CPP The Printer VLRU's Status Sub-Class
- [0197] PIMUX.CPP The PI MUX VLRU Class
- [0198] PINTRFCE.CPP The base class for the Tuner VLRU, Card Reader VLRU and PAT VLRUs

[0199] Main( ) registers with the System Monitor 412 and launches a PIDispatch object to open up communications between the message processor 404 and the transaction dispatcher 421. It calls PIDispatch::startItUp( ) 518 to initialize the VLRUs, one each. It also launches the Session( ) threads 507. Main( ) waits to die, either by receiving a ProcessStop command from System Monitor 412, or else it sleeps forever until interrupted. It calls shutItDown( ) 518a to close all the VLRUs down with a SubProcessStop command and exit gracefully.

[0200] Referring to FIG. 13, the message processor (MP) 404 and the transaction dispatcher (TD) 421 communicate by way of a Network Addressable Unit (NAU) dispatcher 500 that comprises NAUDispatch. NAUDispatch is a base class that contains the code necessary to open a framework for a new Network Addressable Unit. It contains the following global objects:

[0201]


Qpair MP_Fifos	Qpair MP_Fifos keep track of traffic between the
	NAU and the Message Processor. The NAU Ob-
	ject Ids are stored in these two queues.
Qpair TD_Fifos	Qpair TD_Fifos keep track of traffic between the
	NAU and the Transaction Dispatcher. The NAU
	Object Ids are stored in these two queues.
Queue	The Queue RunImmediateFifo keeps track of
RunImmediateFifo	NAUs which require immediate attention,
	regardless of outside messages.
Queue TimedOutFifo	The Queue TimedOutFifo allows an NAU VLRU
	to time out, thus giving processing over to others
	until the time out occurs.
Queue DestructFifo	The Queue DestructFifo is used by shutItDown( )
	to cause each VLRU to shut down.
Queue AuxFifo	The Queue AuxFifo is used in Session.cpp of
	Seat.exe only.

[0202] Only the first constructor call per program uses InitNAUDispatch( ) to start all session threads 507 (one for each VLRU plus 2 up to a maximum of 14) for the NAU. It opens Named Pipes 519a and 519b between the message processor 404 and the transaction dispatcher 421 Fifos 501, 502 and the session threads 507 to manage I/O between them. It then initiates threads 511-514 that manage input and output between the message processor 404 and the transaction dispatcher 421 (MPLeft( ) 511, MPRight( ) 512, TDLeft( ) 513 and TDRight( ) 514). Once these initialization steps have been accomplished, the main program constructs NAU state machine objects 510 (also called VLRUs).

[0203] In addition, this class contains the following utility functions:

[0204]


AddNAU( )	This routine adds a VLRU object ID to an
	array for later lookup (to send it a message
	or shut it down, for example).
AddNAUMap( )	This routine adds a VLRU object ID and its
	text name to an array for later lookup.
FindNAU( )	Returns the VLRU object ID based on the
	text name passed to it.
GetNthNAU( )	Returns the VLRU object ID in the ‘nth’
	position in the array.
GetNumberOfNAUs( )	Returns the number of VLRU object Ids in
	the array.
RemoveNAUFromMap( )	This routine removes a VLRU object ID and
	its text name from the array.
SendToAllVLRUs( )	This routine sends the same message to all
	VLRUs via their MPRight.queue, as if it
	was sent via the MP. It uses MP logic as a
	short-cut, rather than developing more
	routines for intra-process communication.
SendToOneVLRU( )	This routine sends a message to a single
	VLRU via its MPRight.queue, as if it was
	sent via the MP. It uses MP logic as a short-
	cut, rather than developing more routines
	for intra-process communication.
shutItDown( )	This routine is used to turn off all VLRUs,
	typically called because a message was sent
	by the System Monitor to the main( ) routine
	to do so.
startItUp( )	The startItUp( ) routine is used to start up all
	VLRUs.

[0205] The MPRight( )Thread routine 512 continuously waits for incoming messages from the Message Processor 404 via the Named Pipe 519a. The term ‘right’ indicates that the data moves from left-to-right in FIG. 13.

[0206] The MPRight( ) Thread 512 uses the IFE Message Class routines to deal with the data received. Once a message is received using IFE_Message::GetData( ), it looks up the appropriate VLRU name (IFE_Message::GetAddress( )) and uses it to look up the appropriate NAU object ID (FindNAU( )). Then it stores the incoming message in that NAU's MPQueue.Right queue 516a and places the NAU's ID into the Dispatcher's MP_Fifos.Right queue (MPPutNAU( )) 501. This ID is then used by the Session threads 507 that are constantly running to decide which VLRU needs to be processed.

[0207] A “hook” function pointer is provided with this thread to allow applications to pre-process the message prior to MPRight( )'s storage. If no hook function is defined, this is ignored.

[0208] The MPLeft( ) Thread routine 511 continuously waits for outgoing messages for the Message Processor 404. The term “left” indicates that the data moves from right-to-left in FIG. 13. It uses the IFE Message Class routines to deal with received data.

[0209] Using Queue::Get( ) it reads the NAU ID from the MP_Fifos.Left queue 501 then uses that NAU's MPGetNAU( ) function to read the data from its MPQueue.Left 517a, and uses IFE_message::PutData( ) to output the message via the Named Pipe 519b.

[0210] The TDLeft( ) Thread 513 behaves like MPRight( ) 512, except that the input comes from the transaction dispatcher 421. The TDRight( )Thread 514 behaves like MPLeft( ) 511, except that the output goes to the transaction dispatcher 421.

[0211] It is sometimes impractical for all VLRUs to be running at once (for example, the seat NAU can contain more than 500 VLRUs), so a maximum number of processing threads has been established as 14. These threads 511-514 each execute a Session( ) function 507 which waits for an event such as input from any source (message processor 404, transaction dispatcher 421, TimeOut, etc.), then determines which VLRU state machine needs to be run to process the message and executes it via the VLRU's StartItUp( ) function 518 called by NAU::EntryPt( ). When EntryPt( ) returns, the message is fully processed, and Session( ) 507 loops to get another one.

[0212] The NAU class contains foundation routines and data for any VLRU. It is derived from the timed Callback class and Cobject class (from a C++ Foundation Class Library). The NAU constructor makes an object that has TDQueue and MPQueue, two Qpair objects.

[0213] These queues are used to store the actual data or IFE_Message needed by the VLRU state machine. The NAU constructor also creates three Event Semaphores, including a RunImmediateEvent semaphore, a TimeOutEvent semaphore and an AuxEvent semaphore, which allow it to control processing via the related Queues in the NAU dispatcher 500. Finally, the NAU constructor creates one mutex, DispatchMutex which coordinates which Session thread can access the data for a given VLRU (in case two threads try to handle messages for the same VLRU).

[0214] The StartItUp( ) function 518 (not the same as NAUDispatch::startItUp( )) is called by NAUDispatch::Session( ) when a message is ready to be processed by the VLRU. The StartItUp( ) function 518 typically varies per VLRU, but it's job is to fully process one message received from any source. That may simply mean passing the message on, say from message processor 404 to transaction dispatcher 421 or vice-versa.

[0215] Data Movement Functions will now be discussed. The NAU class contains the following members used to move data to and from the message processor 404 and the transaction dispatcher 421:

- [0216] MPGetNAU( ) Moves data from MPQueue.Left for output to the MP.
- [0217] MPPutNAU( ) Moves data from input from MP to MPQueue.Right.
- [0218] NAUGetMP( ) Moves data from MPQueue.Right into StartItUp( ) for processing.
- [0219] NAUGetTD( ) Moves data from TDQueue.Left into StartItUp( ) for processing.
- [0220] NAUPutMP( ) Moves data from StartItUp( ) into MPQueue.Left for later output.
- [0221] NAUPutTD( ) Moves data from StartItUp( ) into TDQueue.Right for later output.
- [0222] TDGetNAU( ) Moves data from TDQueue.Right for output to the TD.
- [0223] TDPutNAU( ) Moves data from input from the TD to TDQueue.Left.

[0224] Other generic NAU functions include:

[0225]


bOKToRun( )	Reports to NAU Dispatch whether a VLRU
	is ready to run. The base version of this al-
	ways returns TRUE.
EntryPt( )	This launches the VLRU's own StartItUp( )
	function.
get_hTimeOutEvent( )	Returns the value of the Time Out Event
	handle.
get_hVLRUEvents( )	Returns a pointer to all the Event Handles
	used by this session to get Input.
get_NAUState( )	Returns the current state of the VLRU. If
	“Active”, the VLRU is capable of processing
	information. If “Inactive”, it can't take any
	messages. For example, if the system is not
	currently allowing game play, the HSDL
	VLRU would be “Inactive”.
GetBITEStatus( )	This function varies from VLRU to VLRU
	and is only a placeholder in the base class.
GetMPQPair( )	Returns a pointer to the MP Queues - lets the
	user bypass the entire message traffic
	philosophy.
GetName( )	Returns the text name of the current NAU
	VLRU.
GetTDQPair( )	Returns a pointer to the TD Queues - lets
	the user bypass the entire message traffic
	philosophy.
GetUseMessageCounter( )	Retrieves a flag set with
	SetUseMessageCounter( ).
set_NAUState( )	Used to control the state of the VLRU state
	machine. Currently, the two states used are
	“Active” and “Inactive”.
SetUseMessageCounter( )	Sets a flag used by
	NAUDispatch::Session( ).
	If TRUE, Session( )counts messages for the
	VLRU.

[0226] As discussed above, each of the devices (402, 235, 224, 216) attached to the primary access terminal 225 is controlled via its own virtual LRU (VLRU) or NAU state machine objects 510 functions discussed in conjunction with FIG. 13. Most of these devices communicate via the same I/O channel, a PI Mux.

[0227] The tuner VLRU allows control of audio channel selections for flight attendant previewing via the PAT GUI 426. The TunerVLRU class is also a PIIinterface class child. Its StartItUp( ) routine handles the SubProcessStart and SubProcessStop commands the same as the others, and then waits for I/O from either the PI Mux or the transaction dispatcher 421. If a message is received from the PI Mux, it forwards it to the transaction dispatcher 421 using NAU::NAUPutTD( ). If a message is received from the message processor 404, it forwards it to the PI Mux using ToMuxPut( ).

[0228] The card reader VLRU collects and forwards data from the card reader 121d, to be used by the access functions and sales services' functions. Based on the PIInterface class, the CardReaderVLRU class is the first actual VLRU created for this NAU. It creates an event called StartEvent which is used by PIMux to coordinate all the other PIInterface VLRUs. Its StartItUp( ) 518 routine loops forever retaining its Session( ) thread. It looks for a SubProcessStart command from the message processor 404 (which is issued by NAUDispatch::startItUp( )) and then waits for StartEvent to trigger before processing any other messages. Once StartEvent has occurred, it can continue processing. If it receives a SubProcessStop message, it terminates. It reads and ignores all other messages from the message processor 404 and the transaction dispatcher 421. Instead, it looks for input via its FromMux semaphore event, which tells when it has received data from the PI Mux. If the PI Mux sends a CardRead command, this VLRU calls MagCardData( ) to process this message. All other messages are returned to the Mux via the ToMux queue. MagCardData( ) converts the data into ASCII and forwards it to the primary access terminal application via the transaction dispatcher 421. Optionally for testing, the Register can be set with the value “DisplayMagCardData” to cause all the card data to be printed to a window at the primary access terminal 225 via stdout.

[0229] The GUI Monitor VLRU starts the GUI and ends the GUI as appropriate. No LRU is actually associated with this VLRU. When the GUI_Monitor object is created, it creates an extra event called ServiceAlive. This event is set via ServiceMonitor( ) and tested in StartItUp( ) 518 to know whether Cabin Service is communicating to this NAU. The StartItUp( ) routine is called as soon as all the VLRUs are created via the PIDispatch::startItUp( ) it launches another thread called ServiceMonitor( ) which continuously tries to receive messages from the Cabin Services program via a mail slot. It then uses this as a ‘heart beat’ to know if the application is still alive. If this heart beat fails to occur after having been established, the GUI Monitor terminates the GUI process. If this heart beat is never established, ServiceMonitor( ) simulates one, for test purposes. StartItUp( ) 518 continuously loops and waits for the SubProcessStart command from the message processor 404 (from the PIDispatch::startItUp( ) routine), and then it waits for PIDispatch( ) to tell whether it connected to the database successfully by triggering the ConnectedToService event. Then it attempts to start the CGUI.EXE program. If StartItUp( ) detects that the GUI terminated, it attempts to restart it. StartItUp( ) ignores messages from the transaction dispatcher 421, and only processes the SubProcessStart and Stop commands from the message processor 404.

[0230] The Card Reader, Tuner, PI Mux, primary access terminal and Printer VLRUs are all based on the PIInterface class. Essentially, this provides support for one more source of I/O, from the PI Mux (or multiplexed I/O port) via the PIMux VLRU. The PIMux VLRU provides the following member routines:

[0231]


ToMuxPut( )	Converts a PAT_Message into appropri-
	ate syntax for either Audio Tuner or PI
	‘Board’ message and sends the data to the
	ToMux queue.
FromMuxPut( )	Places a message on the FromMux queue.
FromMuxGet( )	Reads a PI_Message from the FromMux
	queue and converts it to a PAT_Message.
ToMuxGet( )	Reads and encodes for transmission a
	PI_Message from the ToMux queue.
FromMuxSemaphoreHandle( )	Returns the handle for this queue
FromMuxSemaphoreHandle( )	Returns the handle for this queue.

[0232] The PIMux class is the VLRU which communicates via the message processor 404 and the transaction dispatcher 421 for all I/O with the PI Board, for card reader, tuning, etc. The PIMux class points to each of these VLRU classes for data transfers through their FromMux and ToMux queues. A StartItUp( ) routine loops forever retaining its Session( ) thread. It looks for a SubProcessStart command from the message processor 404 (which is issued by the NAUDispatch::startItUp( ) routine) and triggers the StartEvent to activate its associated VLRUs (Card Reader, etc.).

[0233] Once StartEvent has occurred, it proceeds to receive I/O from the message processor 404 and the transaction dispatcher 421. It determines which sub-VLRU should process the message and forwards it to their FromMux queue for handling, and then it responds an Ack or Nak to the PI board, as applicable to satisfy its communications protocol needs.

[0234] Messages from the VLRUs intended for the PI Mux are sent to this VLRU as well via their ToMux queues. It encodes the messages as needed, forwards them and handles the Ack/Nak protocol. It has its own version of NAUGetMP( ) in order to use the PI_Message data handling routines.

[0235] The primary access terminal VLRU responds to loopback messages from the CFS TestPort NAU via Ethernet for BIT functionality. It logs communication failures between the primary access terminal (PAT) 225 and the cabin file server (CFS) 268. It controls the BITE and COMM LEDs on the front of the PAT, lighting them to indicate failures. The PatVLRU class is also a PIInterface class child only so it can synchronize operation via the StartEvent trigger. Its constructor reads the registry “VerbosePATVLRU” settings (for test purposes) and the “BITTestInterval” value for BIT testing timeouts. StartItUp( ) launches a thread called BitTestMonitor( ) and then loops continuously to process messages. First, it waits to receive a SubProcessStart message, then it waits for the StartEvent to know that PIMux is alive and ready to go. SubProcessStop causes it to kill the BitTestMonitor( ) thread and then die. All other messages from the message processor 404 are ignored. If an Ethernet Loopback message is received from Test Port NAU via the transaction dispatcher 421, it uses EthernetLoopback( ) to return a message via NAU::NAUPutTD( ), and then tell the BitTestMonitor that the loopback occurred. All messages from the PIMux are returned to it via PIInterface::ToMuxPut( ) and otherwise ignored as an error. The BitTestMonitor( ) turns both BITE and COMM LEDs on at the primary access terminal 225 to show that they are both working. Then it turns off the BITE light and waits. If it receives notification from StartItUp( ) that a loopback occurred, it turns off the BITE LED. If it times out waiting for a loopback, it turns the LED back on. If it gets several successive failures (timeouts) it logs it to the event log. If it gets told to exit by StartItUp( ), it turns the BITE LED on and dies.

[0236] The Printer VLRU periodically queries the control center printer for its status and provides this status as an unsolicited message to the PAT GUI 426. The PrinterVLRU object is a PIInterface class child only so that it can sync up with PI Mux to start processing. Its constructor retrieves “PrinterPollInterval” and “PrinterStatusTimeout”from the Registry and then creates hEventPrinterStatusChange and hEventStop to communicate to the monitor thread that is created in StartItUp( ). This class also has a PrinterStatus class object called Printer which does all the actual communication with the printer over the Ethernet network 228. StartItUp( ) launches the PrinterStatusMonitor( ) thread, and then loops forever. The only message processor messages it processes are:

- [0237] SubProcessStart After receipt it waits for the StartEvent signal to continue
- [0238] SubProcessStop Kills the Monitor thread and dies

[0239] StartItUp( ) ignores all messages from the transaction dispatcher 421. It echoes any messages back to the PI Mux and otherwise ignores them. If StartItUp( ) receives a PrinterStatus event (from the monitor), it calls SendPrinterStatus( ) to build the status message and then sends it to the CAPI Message Service via NAU::NAUPutTD( ).

[0240] PrinterStatusMonitor( ) uses the PrinterStatus object of this VLRU to talk to the printer. If it cannot talk to the printer via PrinterStatus::InitializePrinterSNMP( ), it logs the error to the event log. If changes in the printer status occur, it tells StartItUp( ) via hEventPrinterStatusChange. It logs the following other events to the event log: Out of Paper, Has Paper Again, any other errors, and 1st Status after any error.

[0241] SendPrinterStatus( ) uses PAT_Message routines to convert the PrinterStatus info to ASCII. It then sends it on to the CAPI Message Service via NAU::NAUPutTD( ). The PrinterStatus class constructor connects to the Printer via the Ethernet network 228 using InihalizePrinterSNMP( ), requests the status via RequestRawPrinterStatus( ), Interprets (with StatusDescription( )) and displays the printer status info using DisplayPrinterStatus( ), among other private routines.

Transaction Dispatcher

[0242] The transaction dispatcher 421 will now be discussed with reference to FIG. 14. The transaction dispatcher 421 comprises NAU Clients 551, a NAU Server 552, a Router and Mail Slots 553, a Services Server 554, and Service Clients 555. The NAU Server 552 comprises a plurality of OutPipeProcessors( ) 552a, a plurality of InPipeProcessors( ) 552b, and a plurality of NAU Out FIFO Queues 552c. A plurality of Name Pipes 556 couple the NAU Clients 551 to the InPipeProcessors( ) 552b and OutPipeProcessors of ( ) 552a and InPipeProcessors( ) 552b. The NAU Out FIFO Queues 552c are respectively coupled to the OutPipeProcessors( ) 552a. The Services Server 554 comprises a plurality of OutPipeProcessors( ) 552a, a plurality of InPipeProcessors( ) 552b, and a plurality of Service Out FIFO Queues 552d. The Service Out FIFO Queues 552d are respectively coupled to the to the OutPipeProcessors( ) 552a. A plurality of Name Pipes 556 couple the Service Clients 555 to the OutPipeProcessors( ) 552a and InPipeProcessors( ) 552b.

[0243] The Router and Mail Slots 553 comprises the LRU table 553a, which is coupled to an AddMessageToOutQueue( ) 557. The InPipeProcessors( ) 552b of the NAU Server 552 are coupled to the AddMessageToOutQueue( ) 557. Also, the InPipeProcessors( ) 552b of the Services Server 554 are coupled to the AddMessageToOutQueue( ) 557. The AddMessageToOutQueue( ) 557 is coupled by way of a IntraNodal Output Queue 553b to an IntraNodalOutThreadProcessor( ) 558a. The IntraNodalOutThreadProcessor( ) 558a is coupled to any process on any NT line replaceable unit connected by way of the Ethernet network 228. Similarly any process on any NT line replaceable unit connected by way of the Ethernet network 228 to an IntraNodalInThreadProcessor( ) 558b is coupled to the AddMessageToOutQueue( ) 557.

[0244] The primary duty of the Transaction Dispatcher 421 is to move information between the logical devices (or NAU clients 551) and the Application Services (or service clients 555). By using a Transaction Dispatcher 421, the NAUs and the Services do not have to control I/O traffic. In addition, the number of Named Pipes (or communication lines) between processes is greatly reduced because each Service and NAU need only communicate with one process, rather than each other. This simplifies the software design and efficiently uses a finite number of available Named Pipes.

[0245] To support this, the transaction dispatcher 421 includes the following sub-functions. Upon demand, the transaction dispatcher 421 creates two Named Pipes (input and output) for each NAU and Service, maintaining the lookup table 553a of pipe names (or handles) and their corresponding NAU or Service IDs.

[0246] The transaction dispatcher 421 uses Blocking I/O to await a message from any incoming Named Pipe. Once it receives an IFE-structured Message, it examines only the message destination (NAU or Service ID) portion of the message to identify the appropriate Named Pipe to use by cross-referencing the lookup table 553a. It then routes the complete message to an output queue 552c and 552d for that Named Pipe.

[0247] The transaction dispatcher 421 uses Mail Slots to send and receive messages from processes that are resident on remote WINDOWS NT line replaceable units, routing them to the appropriate destination. Using this technique, any Service or NAU can communicate with any other Service, NAU or program on this line replaceable unit or any line replaceable unit that also runs a transaction dispatcher 421.

[0248] The detailed design of the transaction dispatcher 421 will now be discussed. FIG. 14 illustrates the transaction dispatcher function and data paths. TD.EXE is the transaction dispatcher 421 and is comprised of the following file:

- [0249] TRNSCTND.CPP—the Main Program and TransactionDispatcherClass

[0250] The Main( ) function of the transaction dispatcher 421 is responsible for initializing all its processing threads using CreateMainServiceThreads( ), CreateMainNAUThreads( ) and CreateMainIntraNodalThreads( ) functions. These threads operate continuously to move data from source to destination.

[0251] Main( ) also registers its existence with the system monitor program 412 (using Register( )) and waits for a shutdown signal from the system monitor 412, after which it performs an orderly shutdown of all its threads via its destructor. The relationships of the transaction dispatcher functions are shown in FIG. 14.

[0252] The term NAU Server means a set of routines that comprise a “Server” for the Network Addressable Unit processes. Two threads, NAUInThreadProcessor( ) and NAUOutThreadProcessor( ) are used to launch a set of I/O threads (InPipeProcessor( ) 552b and OutPipeProcessor( ) 552a) for an as yet unknown NAU process. The first message received from any NAU registers it to this set of threads, causing NAUInThreadProcessor( ) and NAUOutThreadProcessor( ) to launch another set, getting ready for the next NAU to speak. In this way, the transaction dispatcher 421 is dynamic and can support different NAUs as needed.

[0253] With regard to Incoming Messages, InPipeProcessor( ) 552b continuously receives an IFE Message from its Input Pipe and sends it to AddMessageToOutQueue( ) 557 which routes it to the appropriate output queue. With regard to Outgoing Messages, OutPipeProcessor( ) 552a continuously reads an IFE Message from the NAU Out Queue 552c and sends it to its associated NAU process via its named pipe 556.

[0254] The term Services Server 554 means the set of routines that comprise a “Server” for Cabin and Sales Services. Two threads, ServiceInThread( ) and ServiceOutThread( ) are used to launch a set of I/O threads (InPipeProcessor( ) 552b and OutPipeProcessor( ) 552a) for an as yet unknown Service process. The first message received from any Service registers it to this set of threads, causing ServiceInThread( ) and ServiceOutThread( ) to launch another set, getting ready for the next Service to speak. In this way, the transaction dispatcher 421 is dynamic and can support different Services as needed.

[0255] With regard to Incoming Messages, InPipeProcessor( ) 552b continuously receives a message from its Input Pipe and sends it to AddMessageToOutQueue( ) 557 which routes it to the desired output queue. As for Outgoing Messages, OutPipeProcessor) 552a continuously reads a message from the Service Out Queue 552d and sends it to its associated Service process via its named pipe.

[0256] The router 553 comprises routines that use the lookup table 553a to determine which processing thread needs to process the message. With regard to the From Any Source Router, upon demand, AddMessageToOutQueue( ) 557 calls the appropriate PutData( ) function to move the message to the NAU or Service output queue.

[0257] The LRU Lookup Table 553a is an internal memory structure that contains an entry for each device in the system 100. It contains sufficient information to translate message addresses for any piped destination. Specifically, it contains: Pipe Handle, Registeree, Queue Pointer, Queue Semaphore, and Thread Pointer. This information is kept in an SQL database table which is read during the Main( ) initialization via CreateLRUTable( ). Then as piped processes register with the transaction dispatcher 421, their identities are updated in this table 553a via AddQueueInfoToLookUpTable( ), AddThreadPointerToLookUpTable( ) and AddPipeHandleToLookUpTable( ) functions.

[0258] The term Intra Nodal Server means the set of routines that permit communications between two WINDOWS NT line replaceable units connected via the Ethernet network 228. This differs from the Named Pipe communications in that a set of communication pipes is not created and maintained for each process. Instead, a single mail slot is maintained for incoming messages, and an appropriate outgoing mail slot is created for each outgoing message as needed.

[0259] With regard to Incoming Messages, IntraNodalInThreadProcessor( ) 558b continuously receives a message from its Mail Slot and sends it to AddMessageToOutQueue( ) 557, which routes the message to the appropriate destination. The destination may be an NAU, a Service or even back out to another process via a mail slot. With regard to Outgoing Messages, IntraNodalOutThreadProcessor( ) 558a continuously reads a message from its Out Queue and sends it to its associated process via the Mail Slot. This mail slot is created for just this message, and then is closed after the message is sent.

[0260] The System Monitor program 412 is automatically invoked by the operating system when the line replaceable unit boots. The system monitor function and data paths are shown in FIG. 15. The System Monitor program 412 comprises a service_main( ) 561 that is coupled to a StopServices( ) 565. The System Monitor program 412 is coupled to console services 562 by way of a ConsoleInput( ) 562a. Other outside testing processes 562b are coupled to a service_cntrl( ) 563. A WatchDogDrive 591 along with the service_cntrl( ) 563 and the ConsoleInput( ) 562a are coupled to a MainQueue 564.

[0261] A Process/Event Lookup table 567 is coupled to a GetSystemFullActionItem( ) 568 that interact with a serv_server_main( ) and server_main( ) 566. The MainQueue 564 is coupled to the server_main( ) 566. The MainQueue 564 is coupled to a ProcessEventList( ) 569. The ProcessEventList( ) 569 is driven by a plurality of Sysmon Class and Process Class State Machine Functions 570a, 570b. Output of the Process Class State Machine Functions 570b are coupled to OutputQueues 571 of various Process and Process I/O functions 572, 572a. The Process and Process I/O functions 572, 572a are coupled by way of OutputLoop( ) 573 and Name Pipes 574 to the transaction dispatcher 421 and message processor 404. The transaction dispatcher 421 and message processor 404 are coupled by way of Name Pipes 574 to respective InputLoop( ) 575. The respective InputLoop( ) 575 are coupled to the MainQueue 564.

[0262] Sorted functions of the Process Class State Machine Functions 570b are coupled by way of a QueueSorted Queue 576 and a StatPutQueueThread( ) 577 to the MainQueue 564. Additional runtime processes 578 are also coupled by way of Name Pipes 574 to SysmonConnectThreads( ) 579. The SysmonConnectThreads( ) 579 are coupled by way of a Register::RegisterInput( ) 580 to the Process functions 572.

[0263] A WatchDogDrive 591 is provided that comprises a WatchStaticThread 592, a DogQueue 593 and a StatQueueThread 594. The WatchStaticThread 592 outputs to the DogQueue 593 and a PExternalKillProcess( ) from the Process Class State Machine Functions 570b are coupled to the DogQueue 593. The DogQueue 593 outputs to the StatQueueThread 594 which in turn drives the WatchDog Driver 410.

[0264] The System Monitor program 412 operates in the background during the life of the control center applications and has the following four basic duties:

[0265]


Start-Up	The Start-up function starts the Executive and Application
	programs after any system boot.
Shutdown	The Shutdown function provides an orderly shutdown,
	flushing working data from memory to hard disk as
	appropriate. Then it terminates the execution of the
	Executive and Application programs.
Power Down	This function works in conjunction with the Uninterruptable
	Power Supply (UPS) 400 which is connected via one of the
	serial ports on each of the Control Center LRUs. The op-
	erating system is notified by the UPS when power has been
	lost, causing it to start this function (POWERDWN.EXE,
	POWERDWN.CPP). The Power Down program notifies the
	System Monitor that power has been lost to invoke an
	orderly shutdown using a ‘ProcessStop’ IFE Message.
	POWERDWN.EXE is listed in the NT Register as the
	program to start when power failure is detected.
Restart	The Restart function scans for failed Executive and Appli-
	cation programs, and restarts them.

[0266] The detailed design of The System Monitor 412 will now be discussed.

[0267] SYSMON.EXE includes the following primary components:

- [0268] SYSMON.CPP The Main( ) Program and Sysmon Class
- [0269] DLYSCHDL.CPP The DelayScheduler Class
- [0270] PROCESS.CPP The Process Class to manage the external programs
- [0271] QUEESORT.CPP The QueueSort Class—Used to manage sorted queues
- [0272] RGSTRBJC.CPP The Register Class used to register external processes
- [0273] SMSCRIPT.CPP The SysmonScript Class to manage the state tables
- [0274] SYSGLOBA.CPP Global routines to map to state-machine functions
- [0275] SYSMNCNN.CPP The SysmonConnect Class used to communicate externally
- [0276] SYSMNSPC.CPP SysmonSpecial Class
- [0277] UTL150.CPP RandomPack and Liner Classes plus other utilities
- [0278] WTCHDGDR.CPP The WatchDogDrive Class

[0279] Referring to FIG. 15, the System Monitor 412 is a Windows NT Service Process, which means it runs in the background and is controlled by the following functions in the Win32 SDK Library: StartServiceCtrlDispatcher( ), ControlService( ), Handler( ), RegisterSreviceCtrlHandler( ), and ServiceMain( ).

[0280] The System Monitor 412 was designed as a state machine, but, it's actual code is more of an in-line design with state flags used to keep track of processing. For example, a single function calls another function which calls yet another function, and all three are only used once. For clarity, these are grouped together herein.

[0281] The main( ) function updates its revision history information in the WINDOWS NT Register, determines where to find the other programs to be started, launches itself as a WINDOWS Service by connecting to the WINDOWS Service Control Manager via StartServiceCtrlDispatcher( ), identifying service_main( ) 561 as the main function for this service. The main( ) function is identified in advance of runtime during software installation, which calls the NT CreateService( ) to set up the System Monitor 412 as a WINDOWS NT Service. Main( ) also alters its behavior depending on whether a console service 562 (i.e., a display monitor) is available for testing. Main( ) uses SetConsoleCtrlHandler( ) to allow someone to abort the programs by pressing Ctrl-C at any time.

[0282] Service_main( ) 561 is the main program that continually runs when the system monitor service is running. It calls RegisterServiceCtrlHandler( ) to identify service_ctrl( ) 563 to NT as the function to execute when other outside programs want to alter the execution of this service. It maintains a combination state-checkpoint to identify to the outside world (i.e., test programs) what it is doing:

[0283]


	Check-	Service Control Code
State	point(s)	to get there

SERVICE_START_PENDING	1,2	(none)
SERVICE_RUNNING	0	Service_Control_Continue
SERVICE_PAUSED	0	Service_Control_Pause
SERVICE_STOP_PENDING	0,1	Service_Control_top
SERVICE_STOPPED	0	(none)

[0284] When service_main( ) 561 starts, it is in SERVICE_START_PENDING state, checkpoint #1. If it successfully creates all its event handles, it moves to checkpoint #2. It then sets up a Security Descriptor and launches a serv_server_main( ) thread, moving its state to SERVICE_RUNNING.

[0285] The outside world can alter its state by calling service_ctrl( ) 563 and providing a Service Control Code. The table above shows which state service_main( ) 561 moves to based on the control code received. If the SERVICE_STOPPED state is reached, a hServDoneEvent is triggered, causing this function to exit, terminating the System Monitor 412.

[0286] The service_ctrl( ) 563 routine is called via an NT Service utility ControlService( ) by any outside program that wishes to control the System Monitor service in some way. Service_ctrl( ) 563 uses a MainQueue 564 to issue commands to various Process Class objects that are running.

[0287] The server_main( ) 566 routine creates the Sysmon object MainSysmon and executes its Sysmon::StartHandler( ) to get the other processes running. If running in test mode, server_main( ) 566 is called directly by main( ). If running in runtime mode, server_main( ) is called by serv_server_main( ) 566 which is a thread launched by service_main( ) 561 (the main program initiated by the WINDOWS NT Service Manager). Finally, server_main( ) 566 calls Sysmon::MainQueueProcessing( ) which loops until it is time to shutdown. Once MainQueueProcessing( ) returns, this thread ends.

[0288] The StopService( ) function 565 can be used by any thread to report an error and stop the Sysmon Service. It logs the reason that it was called via ReportEvent( ), and tells service_main( ) to abort via hServDoneEvent. Derived from Process, the Sysmon Class contains all the software needed to drive all the Process Class state machines. It uses MainQueue 564 as its primary input.

[0289] Sysmon::StartHandler( ) is responsible for launching all the external programs and providing a means to monitor them. First, it compiles the file SYSMON.ASC. Then, it queries the NT Registry to determine which type of line replaceable unit it is running on (PAT, CFS or test unit) to know which processes to initiate. It creates a SmScript object to establish system-level state machine tables using SmScript::InitiateTables( ). It sets up communications with the UPS 400 via a communication port, and determines whether the UPS 400 is working, whether the line replaceable unit has power and whether it should continue processing as a result. Finally, it creates the following objects and runs a starter function for each of them:

[0290]


Object	Class	Starter Function

ConnectTask	SysmonConnects	StartHandlerConn( )
MyWatchDog	WatchDogDriver	StartHandler( )
ProcessItem[i]	Process	Initialize( )
(one for each		(StartHandler( ) is called later,
process		after Process Registration)
for this LRU)
SelfHeartBeatTask	SysmonSpecial	StartHandlerSpecial( )
SelfMonitorTask	SysmonSpecial	StartHandlerSpecial( )
DelayTask	DelayScheduler	StartHandlerDelay( )
QueueSorted	QueueSort	None, used to schedule events (i.
		e., Process::PPost-
		ExternalKillProcess( ))

[0291] It creates an EventOnQueue object with an UpSystem event in it and places it in the MainQueue queue 564 to start the external processes (beginning with the Transaction Dispatcher 421). Finally, it calls Sysmon::MainQueueProcessing( ) which loops forever, using Sysmon::MainProcess( ) to handle all processing requests which get placed on the MainQueue queue by this and the other classes' threads.

[0292] The basic flow of startup events is:

[0293]


UpSystem Event from Sysmon::StartHandler	start Transaction
	Dispatcher
Registration received from Transaction Dispatcher	start Message
	Processor
Registration received from Message Processor	start Service
Registration received from Service	start NAUs

[0294] In this way, the system comes up in a sequential, orderly fashion.

[0295] MainQueueProcessing( ) loops forever waiting for Events to appear on the MainQueue queue. Once found, it calls MainProcess( ) which uses the information from the EventOnQueue object to lookup the ‘real’ action(s) to perform using the SmScnpt::GetSystemFullActionItem( ) and Process::GetTotalMatrix( ) functions. It processes these actions using Sysmon::ProcessEventList( ) 569.

[0296] ProcessEventList( ) 569 is only called by MainProcess( ) to look up and process the desired actions from a table of actions, which are maintained in the SmScript Class.

[0297] The above processes loosely form a state machine. In fact, a series of flags denoting the state of the Sysmon system is used to decide what to do next. The following routines are used to support this state machine. There is only one system level Action List to do: UpSystem[ ] or UpPAT[ ]. They each have several Actions which point to SYSGLOBAL functions. These functions in turn determine whether they should call a Process class function or a Sysmon class function. The Sysmon Class functions are:

[0298]


PSysSoftReboot( )	Calls softboot( ) which uses the ExitwindowsEx( )
	command to reboot the LRU. Called via the global
	PSoftReboot( ) function.
PSysHardReboot( )	Reboot via WatchDogDriver::Watch_Reboot( )
	which causes the hardware to reset. Called via the
	global PHardReboot( ) function.
PSysGetState( )	Retrieves the state of the system state machine.
	Called via the global PGetProcessState( ) function.
	This is not used: The variable ‘selfstate’ is used
	directly.
PSetSysState( )	Sets the state of the system state machine, which is
	used in GetSystemFullActionItem( ) along with the
	current event to know what action to do to the sys-
	tem. Generally called via the global PSetState( )
	function.

[0299] The SysmonConnects class contains code necessary to communicate to the other processes in the line replaceable unit, for example the Transaction Dispatcher 421. It establishes a Named Pipe set to communicate with each of them. It works very closely with the RegisterObject Class to provide pipes to each of the Process Class handlers. This method of creating a generic Named Pipe set and assigning it to the first process to register was taken from the Transaction Dispatcher 421, however, because this program directs which external process is executed, and therefore which one is registered.

[0300] The StartHandlerConn( ) routine simply launches two threads, one for Named Pipe Input and one for Named Pipe Output.

[0301] InputConnectThread( ) is launched by StartHandlerConn( ). It calls DynInput( ) which loops forever, opening a Named Pipe for input, then waiting for an outside process to connect to it. It then creates a temporary RegisterObject class object to tie this Named Pipe to the connecting outside process, and loops to create another named pipe.

[0302] OutputConnectThread( ) is launched by StartHandlerConn( ). It calls DynOutput( ) which loops forever, opening a Named Pipe 574 for output, then waiting for an outside process to connect to it. It then creates a temporary RegisterObject class object to tie this Named Pipe to the connecting outside process, and loops to create another named pipe.

[0303] When the DynInput( ) and DynOutput( ) routines of SysmonConnect receive input from an outside process to claim a Named Pipe, they create a temporary RegisterObject class object to receive Registration information from the calling process and tie the current Named Pipe to the Sysmon Process object associated with that process. In this way, each Process object has its own set of I/O to its corresponding external process.

[0304] This launches RegisterInput( ) as a new thread. It is called by both SysmonConnects::DynInput( ) and DynOutput( ). The RegisterInput( ) code calls DynRegisterInput( ) and kills itself and its SELF (its own object) when DynRegisterInput( ) is done. The DynRegisterInput( ) routine tries to read from the Named Pipe to get a Registration message from the outside process. It attempts this 100 times before it gives up and exits. If successful, it calls Process::StartHandler( ) to get its Input or Output thread started with this Named Pipe.

[0305] The SmScript Class contains the tables of events and actions that are used to move each Process object state machine from one state to the next. FullActionItem arrays read like pseudo code, each entry containing the following set of information: FunctionName, Process ID, Additional Data for the named Function. Thus, for example, “{PHardReboot,systemflag,150}” means to run global function PHardReboot(150), which in turn runs the system function Sysmon::PSysHardReboot(150).

[0306] The InitiateTables( ) routine is called once per power-up to prepare the event/action table SysMatrix as appropriate for the runtime LRU system monitor. It fills this array with a pointer to the UpSystem or UpPAT FullActionList array.

[0307] The InitProcess( ) routine is called by Process::Initialize( ) for each process object created to complete the tables for the Process to use. It moves the appropriate event/actions into this Process object's TotalMatrix array. This permits the use only one System Monitor executable program, even though its specific duties vary from line replaceable unit to line replaceable unit. For example, the primary access terminal LRU does not have the Service process and the File Server LRU does not have the primary access terminal NAU process.

[0308] The GetSystemFullActionItem( ) routine returns the appropriate value from the SysMatrix table. The is used only in Sysmon::MainProcess( ).

[0309] The Process Class Initialize( ) initializes the TotalMatrix table via SmScript::InitProcess( ).

[0310] The Process Class StartHandler( ) is called by RegisterObject::DynRegisterInput( ) after an external process has successfully registered with Sysmon. It calls StartInputThread( ) or StartOutputThread( ) depending on the Named Pipe which was registered.

[0311] StartInputThread( ) is called by StartHandler( ) and simply launches a new thread, InputLoop( ). InputLoop( ) in turn simply calls DynInputLoop( ) for this process. DynInputLoop( ) continuously loops, collecting any IFE Message from its Named Pipe (using the IFE_Message::GetData( ) function), and processing it using ProcessIncoming( ). Errors are reported using ProblemReport( ) and the MainQueue is updated to control either a shutdown or retry, depending on the severity of the error. If it's error is severe enough, it exits the loop and the thread dies.

[0312] StartOutputThread( ) is called by StartHandler( ) and simply launches a new thread, OutputLoop( ). OutputLoop( ) in turn calls DynOutputLoop( ) for this process. DynOutputLoop( ) continuously loops, collecting any IFE Message from its OutputQueue and sending it out its Named Pipe (using the IFE_Message::PutData( ) function). Errors are reported using ProblemReport( ) and the MainQueue is updated to control either a shutdown or retry, depending on the severity of the error. If it's error is severe enough, it exits the loop and the thread dies.

[0313] GetTotalMatrix( )returns the corresponding Action List from TotalMatrix for the current event and state of this process. It is called only by Sysmon::MainProcess( ).

[0314] The following State Machine routines are stored in the SmScript State Machine Tables (called FullActionItems) and are activated as a result of certain event/state combinations via ProcessEventList( ):

[0315]


PExternalKillProcess( )	Kills its associated external process with the
	TerminateProcess( ) function. Called from
	the global PExternalKillProcess( ) function.
PGetPocessState( )	Returns the current state of this state-
	machine. Called from global
	PGetProcessState( ).
PKillProcess( )	Issues IFE message to external process to
	commit suicide. Currently not supported by
	most external processes. Called from global
	PKillProcess( ).
PPostExternalKillProcess( )	Uses the QueueSorted::PutSorted( ) function
	to schedule a Kill command to go into the
	MainQueue later. Called from global
	PPostExternalKillProcess( ).
PSetState( )	Updates the current state of this state-
	machine. Called from global PSetState( ).
PStartProcess( )	Gets the full pathname of the associated
	external process and starts executing it.
	Called from global PStartProcess( ).

[0316] The WatchDogDriver class contains code necessary to manage watchdog driver messages. The watchdog is a hardware component that is responsible for re-starting the line replaceable unit if it fails to receive input in regular intervals. Using this class ensures that the watchdog receives that input from the System Monitor 412 regularly, unless some system or software error prevents it. Commands available for use by Sysmon and Process objects are: Watch_Enable( ), Watch_Disable( ), Watch_Maintain( ) and Watch_Reboot( ). These functions all put the corresponding watchdog action command onto a DogQueue 593 for processing by DynQueueThread( ), which is the only function allowed to actually talk to the driver directly.

[0317] The Watchdog Driver 410 controls a watchdog device supplied by Octagon (called the Octagon PC-450) which, when activated by the System Monitor 412, reboots the system unless it is accessed no less than every 1.6 seconds by the watchdog driver 410. The driver 410 can receive a command to force a reboot of the system, which stops it from updating the watchdog driver 410. The watchdog driver 410 then times-out and a reboot occurs. Use of the watchdog driver 410 helps improve system availability in the event of a software or hardware anomaly that causes unpredictable results in system operation.

[0318] Sysmon::StartHandler( ) creates the WatchDogDriver object and calls its StartHandler( ) routine, which is responsible for launching two threads. One thread manages the I/O with the watchdog hardware, and the other thread maintains the regular output commands to it.

[0319] WatchStaticThread( ) calls WatchDynamicThread( ) which places a request for a ‘strobe’ to the watchdog onto the DogQueue 593 (via Watch_Maintain( )). It then sleeps for 1,000 seconds and loops again.

[0320] StatQueueThread( ) calls DynQueueThread( ) which performs the actual output to the watchdog hardware, “\wdog”. It reads a command request from the DogQueue queue 593 and calls either Watch_Enable_DO( ), Watch_Disable_DO( ), Watch_Maintain_DO( ) or Watch_Reboot_DO( ) to perform the requested command using the WINDOWS DeviceIoControl( ) function.

[0321] The QueueSorted Class coordinates activity in the MainQueue 564. For example, it is sometimes necessary to schedule tasks to occur in the future (such as shutdown due to loss of power). To do this, QueueSorted provides the following functions. The QueueSorted( ) constructor creates its own queue and launches a thread, StatPutQueueThread( ) to monitor the queue periodically. The PutSorted( ) function allows users to add elements to the queue along with a timestamp indicating the time at which this element should be dealt with. The PutSorted( ) function puts them on the queue sorted by the timestamp so that they are dealt with in the proper order.

[0322] StatPutQueueThread( ) calls DynPutQueueThread( ) which loops forever, trying to process the elements on its queue. If the current time is less than or equal to the time of the element's timestamp, the element is moved to the MainQueue for processing by Sysmon::MainQueueProcessing( ). Even though it is scheduled, it is only placed at the end of MainQueue 564, not at the front. Therefore, it does not supercede any existing MainQueue elements.

[0323] The following common software libraries of functions and utilities are used throughout the primary access terminal 225 and cabin file server 268 applications.

[0324] The CAPI (RPC Client) Library 427, or RPCLIENT.DLL 427, provides a means of communication between the graphical user interface 426 and the rest of the system 100 through the primary access terminal NAU 409. The RPC Client Library 427 is shown in FIG. 16. The RPC Client Library 427, or RPCLIENT.DLL 427, comprises a ToExec Queue 770, a FromExec Queue 771, a FromGUI Queue 772, and an APIINT::CMSToGui Queue 773. The ToExec Queue 770 and FromExec Queue 771 are coupled to transmit and receive CGUIService::ProcessRequest( ) threads 775. The FromGUI Queue 772 is coupled to transmit various APIINT.CCP calls 782 to the CGUIService::ProcessRequest( ) threads 775. The APIINT.CCP calls 782 are derived from CAPI_C.C Calls 783 that are routed by way of the Ethernet network 228 from CAPI_S.C calls 784 in the Services.exe program 477 running in the cabin file server 268. The CGUIService::ProcessRequest( ) threads 775 route messages to and from a local transaction dispatcher 421a. The APIINT::CMSToGui Queue 773 receives messages from the local transaction dispatcher 421a and from a remote transaction dispatcher 421b. Messages sent from the transaction dispatchers 421a, 421b, are forwarded to an APIINT::CAPIMessageInThreadProcedure( ): 785 which routes the messages to the CAPI Message Service Window 781.

[0325] The PAT GUI 426 cannot be communicated to via Named Pipes because it is a WINDOWS application, and must therefore communicate using standard WINDOWS messages. The CAPI Message Handler is a set of routines within the CAPI Library 427 which provides a bridge between the IFE messages and the GUI WINDOWS application. Instead of communicating via Named Pipes directly with the GUI, Unsolicited Messages 780 utilize Named Pipes into a Message Service Window 781. In order for the GUI 426 to be able to receive them, it must have already opened or started a Window capable of receiving this type of message in the background using the appropriate CAPI Library calls.

[0326] Any WINDOWS User Interface that needs to communicate with the transaction dispatcher(s) 421 of the primary access terminal 225 and/or cabin file server 268, or who needs to access the CAPI calls in the SERVICE.EXE program of the cabin file server 268 needs to link in and use the RPCLIENT.DLL library 427 which contains the following files:

- [0327] APIINT.CPP Dllmain( ) and Visual Basic Application Interface Routines
- [0328] CAPI_C.C The CAPI's RPC Client Support Routines
- [0329] HOOKSDLL.C ‘Canned’ Dynamic Link Library ‘glue’ from MICROSOFT
- [0330] CGUSRVCE.CPP Core Gui (CGUIService) Class (connects to TD)
- [0331] CPMSSGSR.CPP CAPI_Message_Service Class
- [0332] UNSLCTDM.CPP Unsolicited_Message Class

[0333] APPIINT.CPP is the interface between the graphical user interface 426 (GUI or Main Application) and the rest of the system 100. In order to connect to the rest of the system 100, InitializeInterfaceVB( ) must be called to establish communications with the transaction dispatcher(s) 421 and start CAPI_Message_Service::GetTDInMessage( ) threads, which receive all unsolicited messages from the transaction dispatcher(s) 421.

[0334] A call to StartMessageServiceVB( ) launches a thread, CAPIMessageInThreadProcedure( ) to continuously read and process unsolicited messages obtained from the CMSToGui Queue, supported by the CAPI_Message_Service class object.

[0335] The cabin file server 268 and the primary access terminal 225 have many similar functions such as message processors 404 and 452, transaction dispatchers 421 and 473, system monitors 412 and 454, and ARCNET drivers 412 and 450. The discussion of these functions in conjunction with the primary access terminal 225 presented above also applies to the cabin file server 268 with differences as noted. The cabin file server executive extension is discussed with reference to FIG. 10.

[0336] The cabin file server Executive Extension set of routines together with the Common Executive Software forms the generic application for the cabin file server 268. It includes the following components: Backbone NAU 463, Seat NAU 465, VCP NAU 462, Test Port NAU 461, High-Speed Download Driver 449, Services 477 including Cabin Services 478-482, 487-490 and Sales Services 483-486, CAPI calls 476, and the database 493, as shown in FIG. 10. The function and data paths of the many of the NAUs 461-465 have a structure substantially identical to the primary access terminal 225 structure shown and described with reference to FIG. 10 regarding the basic network addressable units function and data paths. The changes generally relate to the structure of the state machine objects that are used in the respective NAUs 461-465.

[0337] The detailed design of the cabin file server executive extension will now be discussed. The BACKBONE.EXE routine contains the backbone NAU program 463. FIG. 17 illustrates the backbone NAU program 463 function and data paths. The backbone NAU 463 is responsible for receiving and processing messages that originate from the audio-video units 231, area distribution boxes 217, passenger entertainment system controllers PESC-A 224a and the PESC-V 224b, and any other communications backbone line replaceable unit. The structure of the backbone NAU 463 is substantially the same as the network addressable unit 409 function in the primary access terminal 225 and data paths discussed with reference to FIG. 13. The backbone NAU 463 comprises a PESC-V NAU dispatcher 500a and PESC-V and PESC-AP VLRU state machine objects 510a shown in FIG. 17. The backbone NAU program 463 includes the following primary components:

[0338]


	BACKBONE.CPP	The Main( ) Program
	PSCPDSPT.CPP	The NAU Dispatcher for the PESC-A
	PSCVDSPT.CPP	The NAU Dispatcher for the PESC-V
	PSCPVLRU.CPP	The VLRU Class for the PESC-A
	PSCVVLRU.CPP	The VLRU Class for the PESC-V

[0339] The Main( ) program is a standard NAU starter that registers the Backbone NAU 463 with the system monitor 454 using a SysMonInterfaceClass::Register( ) routine.

[0340] The Main( ) program launches a PescV_Dispatch object to open up PESC-V VLRU communications between the message processor 452 and the transaction dispatcher 473, and a PescAp_Dispatch object as well to launch the PESC-A 224a. It calls PescV_Dispatch::startItUp( ) to initialize both of the VLRUs.

[0341] The Main( ) program launches 14 Session( ) threads, although only three are actually in use. It sends a SubProcessStart command to the VLRUs which causes the first Session( ) threads in to connect to each VLRU permanently. Only the PescV_Dispatch object maintains a set of MPRight( ), MPLeft( ), TDRight( ) and TDLeft( ) threads.

[0342] Finally, the Main( ) program sleeps forever until interrupted. It does not call shutItDown( ) to close all the VLRUs down and exit gracefully. Instead, it simply deletes the PescV_Dispatch object and dies.

[0343] The VLRUs in this NAU contain their own set of NAUPutTD( ), NAUPutMP( ), NAUGetTD( ) and NAUGetMP( ) routines because they use I/O routines from the PESCA_Message class and PESCV_Message class instead of the IFE_Message class.

[0344] The PescAp_VLRU object attaches directly to the first Session( ) possible via its StartItUp( ) function. Then it continuously loops waiting for data to appear in its message processor and transaction dispatcher input queues. It processes the following commands:

[0345] FlightInfoRequest IFE Function from the PESC-A 224a. This VLRU creates its own IFE message to the IFE Control Service asking for Flight Information.

[0346] FlightInfoUpdate IFE Function from the IFE Control Service, after the PESC-A 224a issues it a FlightInfoRequest. This VLRU creates its own IFE message to forward this to the PESC-A 224a via the message processor 452.

[0347] PES_CONTROL command from the PESC-A 224a. This VLRU examines the state of the WeightOnWheels using PESCA_Message::IsGearCompressed( ). If the state of the wheels has changed, it forwards this new information to the database using NotifyNewFlightState( ), and to the CAPI Message Service via its own NAUPutTD( ). All other messages are ignored.

[0348] The PescV_VLRU object attaches directly to the first Session( ) possible via its StartItUp( ) function. Then, it continuously loops waiting for data to appear in its message processor 452 and transaction dispatcher 473 input queues. It processes the following commands:

[0349] VideoControl command from IFE Control Services is formatted and forwarded to PESC-V 224b. Any other message from PESC-V 224b is routed directly to the IFE Control Services.

[0350] The Seat NAU program 465 function and data paths are depicted in FIG. 18. The Seat NAU 465 controls communication with the seats in the aircraft 111. It maintains three kinds of VLRUs: one that controls high speed download of games and programs to the seats 123; one that periodically broadcasts status messages to the seats 123, and one for each seat 123 to communicate during the flight for sales and other requests.

[0351] The structure of the Seat NAU 465 is substantially the same as the Network Addressable Units function and data paths discussed with reference to FIG. 13. However, the Seat NAU 465 also includes VLRU state machine objects 510b comprising an HSDLInterface VLRU 650, a SeatInterface VLRU 651, and a SeatBroadcast VLRU 652.

[0352] The HSDLInterface VLRU 650 comprises a ProcessFileChanges( ) 650a, ProcessDownloads( ) 650b, and a RefreshThread( ) 650c. The SeatInterface VLRU 651 comprises a Crank( ) 651a, a SessionQueueLeft 651b, and a SessionQueueRight 651c. The SeatBroadcast VLRU 652 comprises a PendingSessionMonitor( ) 652a and a WheelStatusMonitor( ) 652b.

[0353] SEAT.EXE contains the Seat NAU program 465. This program includes the following primary components:

- [0354] NAUMAIN.CPP The Main( ) Program
- [0355] HSDLDSPT.CPP The High Speed Download NAU Dispatcher
- [0356] STDSPTCH.CPP The Seat NAU Dispatcher
- [0357] STNTRFCE.CPP The Seat VLRU Class
- [0358] SESSION.CPP The Service Session Class
- [0359] STBRDCST.CPP The Seat Broadcast VLRU Class
- [0360] HSDLNTRF.CPP The HSDL VLRU Class
- [0361] DWNLDFLN.CPP For HSDL, the DownLoadFileInfo Class
- [0362] FILEMAP.CPP For HSDL, The FileMap Class

[0363] A VLRU Session is characterized by the NAU::Session( ) threads, one for each VLRU that may be active concurrently. A Service Session is characterized by the Session class that controls a stream of communications between a single seat and a Service (such as a Sales Service). This stream may include several messages back and forth before a Service Session is complete.

[0364] The Main Program is a standard NAU starter. Main( ) registers this program with the System Monitor 454 using the SysMonInterfaceClass::Register( ) routine. For test purposes only, if any parameter is passed to this program, it bypasses this step.

[0365] The Main Program creates a HDSLDispatch object to open up communications between the message processor 452 and the transaction dispatcher 473 and create the High Speed Download VLRU 650. Then the Main Program creates the SeatDispatch object to create all the SeatInterface VLRUs 651 and the SeatBroadcaster VLRU 652. The Main Program launches 14 Session( ) threads 507 that are shared by all the VLRUs. A typical number of Sessions is 14 including 10 seats' Service Sessions, plus HSDL, plus Broadcast, plus two more to control seats that are waiting for a Service Session to free up (pending seats). The Main Program calls NAUDispatch::startItUp( ) 518 to initialize the VLRUs with a SubProcessStart command.

[0366] The HSDLDispatch file defines a MPRightHook( ) function to be called within the NAUDispatch::MPRight( ) thread prior to processing the incoming message from the message processor 452. It uses this hook function to intercept the High Speed Download Request messages and route them to the HSDL VLRU 650 instead of to the Seat VLRU 651, where its LRU address would normally send it. This reduces traffic to the 10 Sessions( ) 507 reserved for the seats.

[0367] Finally, Main( ) sleeps forever until interrupted. It does not call shutItDown( ) to close all the VLRUs down and exit gracefully. Instead, it simply deletes the NAU Dispatch and dies.

[0368] The SeatInterface VLRU 651 is responsible for processing requests from the seats 123 such as ordering a movie or a game. It routes these requests to the applicable Service via the Transaction Dispatcher 473. One VLRU for each seat 123 in the system exists; however, only 10 VLRUs at a time may actively be engaged in a communication session between seat 123 and Service.

[0369] Each SeatInterface VLRU 651 has a Session object that it uses as its state machine. Its StartItUp( ) function loops continuously as long as it is actively engaged within a session (that is, the session state is not idle), looking for one of the following events: Data from the message processor 452, Data from the transaction dispatcher 473, an NAU TIMEOUT, an NAU RUN IMMEDIATE, a NAU AUX, a SessionQueue.Right or SessionQueue.Left events. It passes any TD messages on to the seat display unit 122 provided they do not affect the State of the VLRU. StartItUp( ) then calls Session::Crank( ) to process one event from the SessionQueue.Right queue. Once it has been processed, StartItUp( ) forwards any message that may be waiting in SessionQueue.Left (sending it out to the message processor 452 or transaction dispatcher 473), then determines what to do with the input event that got it going (from the message processor 452, transaction dispatcher 473, Timeout etc.). Usually, it simply puts it in SessionQueue.Right, which re-triggers StartItUp( ) to again call Session::Crank( ) until all events and/or messages are processed. Once the processing is complete for this VLRU's Session, StartItUp( ) exits, to give the session thread to another seat. It uses MessageToEvent( ) to convert a Seat_Message into its corresponding Event value, and it uses EventToMessage( ) to develop an appropriate outgoing message based on the current VLRU Event.

[0370] StartItUp( ) also processes the following control messages:

[0371]


IFE Message	Action

StartStatisticsCapture	Sent by the SeatBroadcast thread when
	WeightOnWheels is detected, uses
	timedCallback::queue( ) to set a timer to a random
	value to cause the Statistics request to go to the
	seat after the timeout. This prevents all seats from
	processing the request at the same time (as it
	would from a broadcast), to keep the traffic on the
	network less congested.
SubProcessReinit	Re-Initializes tables via Initialize( ).
SubProcessStart	Starts the State Machine for this VLRU, putting it
	into the Start state.
SubProcessStop	Exits.

[0372] At a minimum, a seat transaction requires sending a message to a service 477 and receiving an answer back. However, if it is a complex transaction (for example, a multiple-product merchandise order), several messages are routed before the entire transaction is complete. Because 500 seats 123 may be all communicating at the same time, the basic design of communications flow from the seat 123 to the services 477 and back can get highly fragmented when these complex transactions are involved. To minimize this fragmentation (and thus create the appearance of faster response at the seats), the Service Session protocol has been developed.

[0373] Supported by the Session class and the SDU interface, this protocol requires a seat 123 to open a session (or tap dibs) with the Seat NAU 465 before a transaction can take place. Only 10 Sessions 507 are supported simultaneously (controlled in the Session constructor by hSessionSemaphore), so if they are all busy, a Pending message is returned to the seat 123 to tell it to wait, and the seat's ID is kept on the SeatInterface::PendingSeats queue. Once a seat has a Session 507 assigned to it, it can communicate freely with the Service 477 via the NAU 465 until it closes or releases the Session.

[0374] The following table illustrates a Sample Session Communication Flow.

[0375]


Seat	Seat NAU	Sales Service

Session Control -
OPEN>
	<Session Status - Pending
Session Control -
SDU Pending>
	<Session Status - Opened
Transaction
Command -
Order>
	Transaction Command -
	Order>
		<Transaction Status -
		Ordered
	<Transaction Status - Paid
Transaction
Command -
Order>
	Transaction Command -
	Order>
		<Transaction Status -
		Ordered
	<Transaction Status - Paid
Session Control -
Close>
	<Session Status - Closed

[0376] Each SeatInterface VLRU 651 has a Session class, called the_Session to support this which uses an EventStateTable that keeps track of the action to perform for any given Event and/or State. Each action is maintained as a separate function whose name begins “Ac” (e.g., AcTerminateSelf( )). These Action functions are all static BOOL functions that need the current Session and Event pointers passed to them to operate. They are called by the function Crank( ) 651a after it looks them up in the EventStateTable.

[0377] The following state table, called “Action” in the software, shows the relationship between the States, Events, Actions and changed or new states, sorted by From-State. Using this table, one can see how a Seat's Session moves from one state to another, which events can trigger the change and what actions are performed to cause the change. In the software, the events are prefixed with “Ev” (such as “EvSelfBackOut”), actions with “Ac” (such as “AcBackOut”) and states with “St” (such as “StBackOut”). These prefixes are omitted from the table below for easier reading.

[0378]


From-State	Event Trigger	Action Function	To-State
(St . . . )	(Ev . . . )	(Ac . . . )	(St . . . )

BackOut	SelfBackOut	BackOut	BackOut
BackOut	ServiceBackedOut	BackOut	BackOut
BackOut	SelfBackOutDone	BackOutDone	Opened
CancelPending	ServiceCanceled	ServiceGeneralAction	Opened
CancelPending	SelfTimeOut	GeneralTimeOut	Terminating
Closed	SelfClosed	SessionNormal-	Terminated
		Terminate
Closed	SelfTimeOut	GeneralTimeOut	Terminating
CompleteUpdate	SDUGetNext-	SendTransaction-	Complete-
ByCommand	Transaction	Update	UpdatePending
Complete-	SDUGetNext-	SendTransaction-	CompleteUpdate-
UpdatePending	Transaction	Update	Pending
Complete-	SelfUpdateDone	TransactionUpdate-	Opened
UpdatePending		Complete
Complete-	SelfTimeOut	GeneralTimeOut	Terminating
UpdatePending
DeliveryPending	ServiceDelivered	ServiceGeneralAction	Opened
DeliveryPending	SelfTimeOut	GeneralTimeOut	Terminating
End	SelTimeOut	GeneralTimeOut	Terminating
Foo	SDUPending	SessionNotAvailable	Paused
Incremental-	SDUGetNext-	SendTransaction-	Incremental-
Update-	Transaction	Update	UpdatePending
ByCommand
Incremental-	SDUGetNext-	SendTransaction-	Incremental-
UpdatePending	Transaction	Update	UpdatePending
Incremental-	SelfUpdateDone	Transaction-	Opened
UpdatePending		UpdateComplete
Incremental-	SelfTimeOut	GeneralTimeOut	Terminating
UpdatePending
Opened	SDUCancel	SDUGeneralAction	CancelPending
Opened	SDUClose	SessionClose	Closed
Opened	SDUDeliver	SDUGeneralAction	DeliveryPending
Opened	SDUOpen	DoNothing	Opened
Opened	SDUStatisticsData	Statistics	Opened
Opened	SDUSurveyData	Survey	Opened
Opened	SDUOrder	SDUOrder	OrderPending
Opened	SDURefund	SDUGeneralAction	RefundPending
Opened	SelfTimeOut	GeneralTimeOut	Terminating
Opened	SDUCompleteUpdate	DetermineUpdate-	UpdateType-
		TypeNeeded	Pending
Opened	SDUIncremental-	DetermineUpdate-	UpdateType-
	Update	TypeNeeded	Pending
Opened	SDUUpdateRequest	DetermineUpdate-	UpdateType-
		TypeNeeded	Pending
Ordered	SelDeliverOnOrder	ServicePaid	Opened
Ordered	SDUPayment	SDUPayment	PaidPending
Ordered	SelfTimeOut	GeneralTimeOut	Terminating
OrderPending	ServiceOrdered	ServiceOrdered	Ordered
OrderPending	SelfTimeOut	GeneralTimeOut	Terminating
PaidPending	ServiceNotpaid-	ServiceNotpaid	BackOut
	ForReason
PaidPending	ServicePaid	Servicepaid	Opened
PaidPending	SelfTimeOut	GeneralTimeOut	Terminating
Paused	SDUOpen	SessionOpenNow	Waiting
Pending	SelfSystem	SystemNotAvailable	Closed
	NotAvailable
Pending	SelfSession-	SessionNotAvailable	Foo
	NotAvailable
Pending	SelfSession-	SessionAvailable	Opened
	Available
Pending	SDUOpen	SessionTryToOpen	Pending
Pending	SelfTimeOut	GeneralTimeOut	Terminating
RefundPending	ServiceRefunded	ServiceGeneralAction	Opened
RefundPending	SelfTimeOut	GeneralTimeOut	Terminating
SessionInit	SDUClose	SessionNormal-	Closed
		Terminate
SessionInit	SDUOpen	SessionTryToOpen	Pending
SessionInit	Terminate-	SessionInit	SessionInit
	Immediatly
SessionInit	SDUTerminate	SessionAbnormal-	Terminating
		Terminate
SessionInit	SelfTimeOut	GeneralTimeOut	Terminating
SessionInit	SelfStatisticsNotify	SendUpdate-	UpdateNotify-
		NotifyToSDU	AckPending
SessionInit	ServiceComplete-	SendUpdate-	UpdateNotify-
	UpdateNotify	NotifyToSDU	AckPending
SessionInit	ServiceInc-	SendUpdate-	UpdateNotify-
	UpdateNotify	NotifyToSDU	AckPending
SessionInit	ServiceIncUpdate	SendUpdate-	UpdateNotify-
	NotifyWithRevoke	NotifyToSDU	WithRevoke-
			AckPending
Start	Start	SessionInit	SessionInit
Start	SelfTimeOut	GeneralTimeOut	Terminating
Terminated	SelfReinitialize	SessionInit	SessionInit
Terminated	SelfTimeOut	GeneralTimeOut	Terminating
Terminating	SelfTerminated	Terminated	Terminated
Terminating	SelfTimeOut	GeneralTimeOut	Terminating
TVOffAck-	SelfTimeOut	UpdateNotifyTimeOut	DontChangeState
Pending
TVOffAck-	SDUTVOffAck	ServiceUpdate-	SessionInit
Pending		NotifyComplete
TVOffAck-	SelfCancel-	DoNothing	SessionInit
Pending	UpdateNotify
UpdateNotify-	SelfTimeOut	UpdateNotifyTimeout	DontChangeState
AckPending
UpdateNotify-	SDUUpdateNotify-	ServiceUpdate-	SessionInit
AckPending	AckFromSDU	NotifyComplete
UpdateNotify-	SDUUpdateNotify	ServiceUpdate-	SessionInit
AckPending	AckFromSI	NotifyComplete
UpdateNotify-	SelfCancel-	DoNothing	SessionInit
AckPending	UpdateNotify
UpdateNotify-	SelfTimeOut	UpdateNotifyTimeOut	DontChangeState
WithRevoke-
AckPending
UpdateNotify-	SDUUpdateNotify-	SendTVOff	TVOffAckPending
WithRevoke-	AckFromSI
AckPending
Update-	SelfCompleteType	SendUpdateType	CompleteUpdate-
TypePending			ByCommand
UpdateType-	SelfIncrementalType	SendUpdateType	Incremental-
Pending			UpdateBy-
			Command
Waiting	SelfSessionAvailable	SessionAvailable	Opened
Waiting	SelfSession-	SessionNotAvailable	Waiting
	NotAvailable

[0379] All possible From-State/Event Trigger combinations are not represented in the Action table. Many do-nothing or illogical combinations need to default. For that reason, the. Action table is used to fill in a larger, more comprehensive table called the EventStateTable. This two-dimensioned table uses the values of From-State and Event Trigger as indexes, and defaults the illogical values to either do nothing or to terminate.

[0380] A typical session flow (with no errors) to place an order would start and end in the SessionInit state as shown below:

[0381]


From-State	Event Trigger	Action Function	To-State
(St . . . )	(Ev . . . )	(Ac . . . )	(St . . . )

Start	Start	SessionInit	SessionInit
SessionInit	SDUOpen	SessionTryToOpen	Pending
Pending	SelfSession-	SessionAvailable	Opened
	Available
Opened	SDUOrder	SDUOrder	OrderPending
OrderPending	ServiceOrdered	ServiceOrdered	Ordered
Ordered	SDUPayment	SDUPayment	PaidPending
Paidpending	ServicePaid	ServicePaid	Opened
Opened	SDUClose	SessionClose	Closed
Closed	SelfClosed	SessionNormal-	Terminated
		Terminate
Terminating	SelfTerminated	Terminated	Terminated
Terminated	Self-	SessionInit	SessionInit
	Reinitialize

[0382] Each Session 507 has a SessionQueue queue pair that is used to store the Events to perform for this Session's State Machine. The SessionQueue's Right queue 651c stores incoming message/event pointers for Session::Crank( ) 651a to process, while its Left queue 651b stores outgoing event/message pointers for SeatInterface::StartItUp( ) 518 to forward to either the message processor 452 or the transaction dispatcher 473 or timeouts as appropriate.

[0383] The SeatBroadcast VLRU 652 is a child of the SeatInterface class so that it can help monitor the seat communication traffic for the other SeatInterface objects. It is responsible for sending messages to more than one seat or more than one Seatinterface VLRU 652. Only one message is actually sent in a broadcast to the seats with the destination set to “AllSeats”. It uses the CalledTimeOut utilities to create a TimeOut Thread called SeatBroadcastTimeout( ) to force periodic, unsolicited broadcasts. It also launches the PendingSessionMonitor( ) 652a and WheelStatusMonitor( ) threads 652b.

[0384] It's StartItUp( ) 518 function loops forever, retaining possession of one of the Session( ) 507 threads. It continuously monitors messages and processes the following events or messages:

[0385]


Message or Event	Action

CPMS Message	Tells all SDU-SI boards the current status of
	the HSDL Queue. Retriggers the
	HSDLInterface::ProcessDownLoadQ( ) event.
MovieTimes Message	Tells the MP what the Movie Run Times are
NAU_TIMEOUT	Triggers every tenth of a second using the
Event	timedCallback::queue( ) function. When re-
	ceived, this broadcasts a “Session Complete”
	message to all seats if a Service Session has
	just completed, so they can retry communica-
	tions, if needed.
ProcessReinit Message	Tells all VLRUs to “SubProcessReinit”.
SeatTransfer Message	Uses ProcessSeatTransfer( ) to parse and for-
	ward this message to the two SeatInterface
	VLRUs that are involved in the transfer.
SubProcessStart Message	Tells all VLRUs to “SubProcessReinit”.
SubProcessStop Message	Stops the Timeout thread and ends the
	program.
Weight_On_Wheels	Tells all VLRUs to Start Statistics Capture,
Event	now that the aircraft has landed (ending flight).

[0386] The PendingSessionMonitor( ) 652a has nothing to do with Seat Broadcasting: It is a supplement to the normal SeatInterface processing. This monitor continuously waits for a Seat 123 to be put onto the static SeatInterface::PendingSeats queue (by any of the other SeatInterface::StartItUp( ) threads), and then waits until one of the Seat Sessions is available for processing. Then it puts this Seat ID onto the AuxFifo queue to be taken by the next available Session( ) thread 507.

[0387] The WheelStatusMonitor( ) 652b is a High Priority thread that waits for a signal from the PESC-A VLRU in the Backbone NAU, which pulses the Weight On Wheels or the Weight Off Wheels events when their status changes. This monitor forwards this event information to the StartItUp( ) 518 to process when it next loops.

[0388] The HSDLInterface VLRU 650 is a standard NAU child dedicated to servicing all download requests for games or application programs by the seats. Its constructor connects to the driver, “HSDL1” to transmit data to the seats via the Digitized Video Multiplexer system. The constructor also prefills a CRC Table used for deriving the CRC values during downloads. It creates a Mutex to control access to the HSDL directory to ensure that the routines in COPYDNL.CPP and SDU_BLDR.CPP don't interfere with the download process by modifying the files in the download directory at the wrong time.

[0389] The StartItUp( ) 518 routine launches the following threads:

[0390]


Thread	Function

ProcessFileChanges( )	Reacts to changes in the NT Registry as well as
	changes in the Download Files Directory. It then
	calls ProcessEntireDirectory( ) to read the direct-
	ory that contains the files that can be downloaded,
	creating a DownLoadFileInfo object for each, and
	placing all download files in the ConvertQ for
	RefreshThread( ) to handle. This thread places all
	programs and database files ahead of games in the
	ConvertQ so that the Seats can be ready for use as
	soon as possible.
RefreshThread( )	Looks for files in the ConvertQ queue to prepare
	for later downloading. Calls
	DownLoadFileInfo::Refresh( ) to block the data
	and add checksums and CRCs for Seat verifica-
	tion. It also saves the identity of the requesting
	seat for communication during the actual
	download.
ProcessDownLoads( )	This thread is launched at a low priority, so that
	the others can prepare all the files beforehand. It
	calls ProcessDownloadQ( ) to use
	SeatInterface::GetDownLoadInstruction( ) to
	handle this file properly. Calls
	DownLoadFileInfo::Download( ) for each file in
	the DownLoadQ to actually send them to the
	output driver. During the download, it redirects
	message handling away from the seats SEB and
	toward its SDU I/F board because the seat display
	unit 122a can't receive messages without its
	application running, which is true whenever it is
	receiving a download.

[0391] Then StartItUp( ) calls ProcessIOQueues( ) to continuously sample the message processor and transaction dispatcher input queues. It processes the following message processor messages:

[0392]


IFE Message	Action

HighSpeedDownload	Puts the download request onto the DownLoadQ.
	It moves a request to the top of the queue if the
	request is for a program (high priority).
SubProcessStart	Simply recognizes this command, no further
	processing.
SubProcessStop	Flushes its MP and TD Input queues and tells the
	DestructFifo queue (one of the few VLRUs to use
	this) that it can be shut down.

[0393] The VCP NAU controls communications with the video players and other video sources. It maintains one VLRU for each video source, and constantly polls the players for their status. The VCP Network Addressable Unit program 462 function and data paths are shown in FIG. 19. The structure of the VCP NAU 462 is substantially the same as the Network Addressable Units function and data paths discussed with reference to FIG. 13.

[0394] VCP.EXE contains the VCP NAU program. This program includes the following primary components:

- [0395] VNUMAIN.CPP The Main( ) Program
- [0396] VCPDSPTCH.CPP The NAU Dispatcher
- [0397] VCPNTRFC.CPP The VCP VLRU Interface Class
- [0398] VCPSTSVL.CPP The VCP Status VLRU Class

[0399] Main( ) issues a call to GetLruInfo( ) to read the database 493 for all the VCP names (e.g., “VCP01”). It then launches a VCPDispatch object to open up communications between the message processor 452 and the transaction dispatcher 473. It calls VCPDispatch::startItUp( ) to initialize the VLRUs, one for each video cassette player 227 plus one for periodic statusing of all video cassette players 227. It also launches the Session( ) threads 507.

[0400] Main( ) then calls ConsoleCmd( ) to process all console characters that may be in the input buffer. If “S” is encountered, a STOP command is issued to VCP01. If “P” is encountered, a PLAY command is issued to VCP01. This is for testing purposes only.

[0401] Finally, Main( ) sleeps forever until interrupted. It calls shutItdown( ) to close all the VLRUs down and exit gracefully.

[0402] A VCP VLRU is created for each video cassette player 227 in the database 493 using the VCPInterface Class. This class is derived from the Generic NAU Class; however, due to the communications protocol employed by the players, many of the generic functions are overcast or not used at all.

[0403] The VCPInterface( ) constructor creates two unique controllers: Static hIOSemaphore and bHasSemaphore. These are used to enforce single-threaded communications between a video cassette player 227 and the transaction dispatcher 473. Using these controllers, only one VLRU can be processing communications at a time.

[0404] hIOSemaphore is a handle that acts as ‘dibs’: When this handle is owned by a thread, that thread can process communications. bHasSemaphore is a local flag that tells the thread whether it currently is the owner of the semaphore.

[0405] VCPInterface::StartItUp( ) is called immediately for each Session( ) to process a ‘dummy’ message from the message processor 452 for each of the video cassette players 227. This ‘dummy’ message was invoked at their creation to glue each video cassette player 227 to its own Session.

[0406] This function then loops forever to continuously process messages. The basic loop does the following:

[0407] If this session does not have dibs, it waits for input from the transaction dispatcher 473 and waits for the hIOSemaphore. Then it flushes all possible input from the message processor 452, reads the transaction dispatcher message and transmits it to the message processor 452. It retains ownership of the I/O handle, and loops again.

[0408] If this session already has dibs (from the previous paragraph), it waits for input from the message processor 404. Once received, it processes it and sends an acknowledgement back to the video cassette player 227 via the message processor 452. It then releases dibs for use by the other VLRUs.

[0409] A single VLRU of class VCPSts_VLRU is created to periodically poll the players for their status. Two lists of information are used to organize this: MessageMap, that contains a list of each video cassette player 227 and its network address; PendingStatus, that contains a list of video cassette players 227 that have just completed a communications event. MessageMap is maintained via Add VLRU( ) as each VCP VLRU is created by the dispatcher. PendingStatus is maintained by XmitResponse( ) each time the VCP VLRU completes a communications event.

[0410] VCPSts_VLRU contains a timeout function that is invoked approximately 10 times per second. The StartItUp( ) 518 function is immediately invoked and tied permanently to a Session( ) 507 thread. It then loops forever waiting for both a timeout to occur and the hIOSemaphore to be available. Once both events have occurred, it examines the contents of the PendingStatus string list and prompts the topmost video cassette player 227 on this list for its status. If none are on this list, it prompts the next video cassette player 227 in the MessageMap list. This is performed via SendStatus( ). These status responses are formatted and forwarded to the Video Control Service via the transaction dispatcher 473. The I/O semaphore is released and the process cycle repeats.

[0411] The Test Port NAU program 461 function and data paths is shown in FIG. 20. The Test Port NAU 461 controls communications to the serial test port for BIT/BITE and MAINT system access. The structure of the Test Port NAU 461 is substantially the same as the Network Addressable Units function and data paths discussed with reference to FIG. 13. However, the Test Port NAU 461 includes NAU VLRU state machine objects 510d comprising a LoopbackThread( ) 660, a EthernetThread( ) 661, a VCPStatusThread( ) 662, and a Loopback Timout( ) 663 that are initiated by StartItUp( ) 518.

[0412] The Test Port NAU program 461 has two exclusive behaviors: BIT test mode and BITE test mode. The Test Port NAU program 461 starts out in BIT mode, and upon receipt of a GO_BITE command (presumably from the PESC-A 224a), it attempts to switch to BITE mode. BITE test mode is only available while the aircraft 111 is on the ground (as indicated by weight-on-wheels).

[0413] A BITE test is a three-pass ‘loopback’ in which data is sent to one of the I/O devices (the primary access terminal 225 to test the Ethernet network 228, a PESC-A 224a to test the ARCNET 216, and VCP Status Service to test video cassette players 227) and an answer is expected back.

[0414] BIT tests are continuously occurring ‘loopback’ tests, however 3 consecutive failed communications are needed before a fault is recorded for any I/O device. A BIT test failure is only reported once per device per flight.

[0415] All BIT/BITE information is forwarded to a ‘depository’ or line replaceable unit that stores the information. In addition, BITE tests are initiated by an outside source or BITE Host. The default value for both of these is the primary PESC-A 224a, however, a SET_DEPOSITORY command executes SetBITEDepository( ) to alter these values.

[0416] TESTPORT.EXE contains the Test Port NAU program 461. The Test Port NAU program 461 includes the following primary components:

- [0417] TESTPORT.CPP The Main( ) Program
- [0418] TSTPRTDS.CPP The NAU Dispatcher
- [0419] TSTPRTVL.CPP The VLRU Class

[0420] The Main Program is a standard NAU starter. Main( ) registers the program with the System Monitor 412 using the SysMonInterfaceClass::Register( ) routine. Main( ) launches a TestPortDispatch object to open communication between the message processor 452 and the transaction dispatcher 473 and calls TestPortDispatch::startItUp( ) to initialize the VLRU. Main() launches two Session( ) threads 507, although only one is actually busy. Main( ) sends a SubProcessStart command to the TestPort VLRU which causes the first Session( ) thread to connect to the VLRU permanently. Finally, Main( ) sleeps forever until interrupted. Main( ) does not call shutItDown( ) to close all the VLRUs down and exit gracefully, it deletes the VLRU and dies.

[0421] A single Test Port VLRU is created using the TestPortVLRU Class. This class is derived from the Generic NAU Class, however it overcast the communications routines to support the TestPort_Message Class data routines. This constructor reads the database to develop a table of all Test Port LRUs, PESC LRUs, Process LRUs, ADB LRUs and ALAC LRUs. This table of LRU addresses is passed to the TestPort VLRU for reference in GetSourceAddress( ) and SetBITEDepository( ).

[0422] TestPortVlru::StartItUp( ) is called immediately for the first Session( ) to process a ‘dummy’ message from message processor 452. This ‘dummy’ message is invoked at their creation to glue the VLRU to a Session (a SubProcessStart message).

[0423] The VLRU then creates a set of 6 events used to communicate to 3 new threads:

[0424]


Thread Name	Event 1	Event 2

ARCNET LoopbackThread	Message	Abort
EthernetThread	Message	Abort
VCPThread	Message	Abort

[0425] This function loops forever to continuously process messages to-and-from the message processor 452. As a message is received, it is tested for validity, and then passed to the appropriate thread via a Message Event. Typically, the Message Events are used to determine what to do next, however to end BITE mode testing, the Abort Event is triggered for each thread to stop BITE testing, making BIT testing possible again.

[0426] StartItUp( ) 518 uses the TimedCallback Utility Class to periodically launch LoopbackTimeout( ) which is responsible for issuing a command to the ARCNET network 216, the primary access terminal 225 and the VCP Service to initiate a ‘loopback’ test, in that it causes these devices to respond. Failure to respond within a specified timeframe causes the associated thread to log that device as FAILED. The initiation is accomplished by calling PerformLoopback( ). It uses its own versions of NAUPutMP( ) and NAUPutTD( ) to communicate because it needs to use the TestPort_Message class instead of IFE_Message class routines to process the data.

[0427] When an event is received, the LoopbackThread( ) Thread process calls ProcessLoopback( ) to fully process the event. It tests ARCNET by communicating with the PESC-A 224a. If the PESC-A 224a fails to respond within a given timeframe, it times out, causing a failure to be noted.

[0428] In order to efficiently load programs, data and video games in the seats 123, the high-speed download driver 449 in FIG. 10 provides the ability to convert this information into a synchronous data link control (SDLC) data stream. This data stream is forwarded to the video modulator (VMOD) 212b to broadcast to all seats 123 via the RF distribution system. Any seat 123 that requires the download can then tune to the download channel and retrieve the information. HSDL.SYS is the high speed down load driver, written in C as a standard WINDOWS NT driver.

[0429] HSDL.SYS is the High Speed DownLoad driver, written in C as a standard WINDOWS NT driver, and includes the following files:

- [0430] CONFIG.C Code for the initialization phase of the HSDL device driver.
- [0431] DISPATCH.C Code for the function dispatcher.
- [0432] DMA.C Code for input and output which is non-hardware specific.
- [0433] HARDWARE.C Code for communicating with the Zilog 85230 processor on the HSDL card.
- [0434] HSDLLIB.C Common code for HSDL Kernel mode device drivers.
- [0435] INIT.C Code for an initialization phase of the HSDL device driver.
- [0436] ISR.C Code for an Interrupt Service Routine for the HSDLBlaster device driver.
- [0437] REGISTRY.C Common code for Sound Kernel mode device drivers for accessing the registry.

[0438] The HSDL device is a Zilog 85230 Enhanced Serial Communications Controller (ESCC), which is an industry-standard serial controller. HSDL is a Synchronous Data Link Control (SDLC) data stream running at 409.6 Kbps with 514-byte frames using FM0 (biphase space) data encoding. To move the data as quickly as possible, DMA transfers are employed.

[0439] The driver is registered as “\\HSDL1” and the following NT driver commands are supported: CreateFile( ), WriteFile( ), DeviceIoControl( ) and CloseFile( ). The calling program writes to the device in 514-byte blocks. Currently, only CreateFile( ) and WriteFile( ) are used in the system 100.

[0440] The application functions are divided into Services 477 that are responsible for carrying out the requests that come from the various devices (Seats 123, PAT GUI 426, etc.). Requests come in two forms: IFE_Messages from the transaction dispatcher 473 and CAPI calls from the GUI 426. Service functions are the primary functions that interact with the database 493 during runtime. Each Service is connected to the transaction dispatcher 473 via its own Named Pipes, and as needed, it connects to the SQL Server 492 for database access.

[0441] SERVICE.EXE is organized into 4 basic components: Main, CAPI Calls 476, Cabin Services 478-482, 487-490 and Sales Services 483-486. The Cabin Services 478-482, 487-490 and Sales Services 483-486 are sets of Service classes whose objects each connect to the transaction dispatcher 473 via named pipes. They also each have a thread and subroutines to process all IFE messages received, and they all have sets of functions that are used by CAPI.CPP routines of the same name.

[0442] SERVICE.EXE is comprised of the following source files:

- [0443] SRVCPRCS.CPP The Main Program and Service Class
- [0444] CAPI_S.C The RPC Server Functions (See CAPI_C for its client companion functions)
- [0445] CAPI.CPP The actual CAPI Application Functions, called by CAPI_S.C, APIINT.CPP, and the Services.
- [0446] CBNSRVCC.CPP The CabinService Base Class
- [0447] CRDTCRDP.CPP The CreditCardProcessor Class
- [0448] DTYFRSRV.CPP The DutyFreeService Class
- [0449] GMSRVCCL.CPP The GamesService Class
- [0450] IFCNTRLS.CPP The IFEControlService Class
- [0451] MVCYCLCL.CPP The MovieCycle Class
- [0452] MVSRVCCL.CPP The MovieService Class
- [0453] OFFLOADR.CPP Database Offloader Functions
- [0454] PCKGSRVC.CPP The PackageService Class
- [0455] PLYRCNFG.CPP The PlayerConfiguration Class
- [0456] SET.CPP The Set Class (to support the_Set table)
- [0457] SLSSRVCE.CPP The SalesService Base Class
- [0458] VCPMSSGE.CPP The VCP_Message Class (see MESSAGES.LIB for details)
- [0459] VDNNNCMN.CPP The VideoAnnouncement Class
- [0460] VDSRVCCL.CPP The VideoService Class

[0461] The Services NAU program 477 function and data paths are shown in FIG. 21. Located in SRVCPRCS.CPP file, the main( ) program is responsible for launching each of the services. Once launched, they are each connected to the named pipes that communicate with the transaction dispatcher 473.

[0462] The services include CAPI.CPP calls 701 which access CAPI_S.C. calls 702 that access CAPI_C.C programs 427. The services include an IFEControlService Class 703, MovieCycle, VideoService and VideoAnnouncement Classes 704, and SalesService, MovieService and GameService Classes 705. The Services NAU program 477 includes a ServiceProcessor 706 that employs a GetContextHandle( ) 722 a ContextHandleSessionQueue 723, and a PutcontextHandle( ) 724.

[0463] The IFEControlService Class 703 employs a CabinService::Get Message( ) thread 711 and a CabinService::Put Message( ) thread 712 that are coupled to the transaction dispatcher 473 by way of name pipes 474. The CabinService::Get Message( ) thread 711 is routed to an InQueue 713 to a ProcessRequest( ) 715 which accesses IFE Message Support Functions 718. The ProcessRequest( ) 715 is coupled by way of an OutQueue 714 to a CabinService::Put Message( ) thread 712 which is coupled to the transaction dispatcher 473 by way of the name pipe 474. A TimeSynchronizationThread( ) 716 is also routed through the OutQueue 714 and CabinService::Put Message( ) thread 712. CAPI Support functions 717 are routed to the CAPI.CPP calls 701 and to the SQL server 492. The IFE Message Support Functions 718 access the SQL server 492.

[0464] The MovieCycle, VideoService and VideoAnnouncement Classes 704 employs a CabinService::Get Message( ) thread 711 and a CabinService::Put Message( ) thread 712 that are coupled to the transaction dispatcher 473 by way of name pipes 474. The CabinService::Get Message( ) thread 711 is routed to an InQueue 713 to a ProcessRequest( ) 715 which accesses IFE Message Support Functions 718. The ProcessRequest( ) 715 is coupled by way of an OutQueue 714 to a CabinService::Put Message( ) thread 712 which is coupled to the transaction dispatcher 473 by way of the name pipe. CAPI Support functions 717 are routed to the CAPI.CPP calls 701 and to the SQL server 492. The IFE Message Support Functions 718 access the SQL server 492.

[0465] The SalesService, MovieService and GameService Classes 705 employs GetMessage( ) 719 and PutMessage( ) threads 720 that interface to the transaction dispatcher 473 by way of name pipes 474. The GetMessage( ) thread 719 is routed by way of an InQueue 713 to a ProcessRequest( ) 715 which accesses IFE Message Support Functions 718. ProcessRequest( ) 715 are routed by way of an OutQueue 714 to the Put Message( ) thread 720 which is coupled to the transaction dispatcher 473 by way of the name pipe 474. CAPI Support functions 717 are routed to the CAPI.CPP calls 701 and to the SQL server 492. The IFE Message Support Functions 718 access the SQL server 492.

[0466] The main( ) program establishes a logon to the SQL Server 492 for database access using the standard SQL library commands in NTWDBLIB.LIB library. The main( ) program establishes 10 SQL Sessions, for example, with Context Handles to be used by the Services 477 to talk to the database 493. The main( ) program establishes multiple handles to the database 493 for all the services and CAPI functions to use, then starts Pipe Threads and Process Threads for each service to run independently.

[0467] The main( ) program establishes itself as an RPC Server to communicate with the PAT GUI 426 and any other RPC Clients with the NT RPC utilities. Any program that has CAPI_C.C linked into it is an RPC Client in the system 100. The main( ) program registers itself with the system monitor 454 for subsequent Shutdown support with SystemMonitor::Register( ). The main( ) program issues a call to ServiceProcessor::StartActivityMailSlotThread( ) to hook up to the primary access terminal NAU's GUI Monitor process, periodically sending it a message to let it know that Service is alive and well. Finally, the main( ) program waits forever listening to the RPC Server that it set up (via RpcServerListen( )) until System Monitor's Shutdown( ) kills the process.

[0468] The ServiceProcessor class is used by main( ) and the Services 477 to control the access to the database 493 using the finite number of Context Handles available. This program has more Service SQL functions than Context Handles. It is conceivable that as many as 25 SQL requests may be present at one time (10 games, 10 movies, 1 CAPI, 1 IFE Control, 1 Movie Cycle, 1 Video Service and 1 Video Announcement). As a result, this code provides for optimum processing efficiency by queueing up the available Context Handles and issuing them on a first-come first served basis.

[0469]


ServiceProcessor Public
Functions	Purpose

CONTEXTHANDLESTRUCT *	Returns the handle to the next avail-
GetContextHandle( )	able context structure for access to
	the database.
int	Returns the numher of available Con-
GetcontextHandleCount( )	text Handles.
HANDLE	Returns the semaphore for the context
GetContextHandleSemaphore( )	handle Queue.
DWORD	Retrieves the error code associated
GetLastError	with the specified context handle
(PCONTEXT_HANDLE_TYPE	(phContext) that was most recently
phContext)	set by the SetLastError( ) member
	function.
void	Adds the DPROCESS handle to the
PutContextDB(int	context handle structure.
dContextLocation,
DBPROCESS*pDBProc)
void	Replaces the context structure into
PutContextHandle	the context structure queue. Service
(CONTEXTHANDLESTRUCT*	Classes use this one.
pContextHandle)
void	Adds the context structure to the con-
PutContextHandle(int	text structure queue. The main( ) pro-
dContextLocation)	gram uses this one to initialize the
	queue.
void	Associates the error code in
SetLastError	dwErrorCord with the context
(PCONTEXT_HANDLE_TYPE	handle pointer (phContext) storing
phContext, DWORD	them in the LastErrorMap structure.
dwErrorCode)	Values are retrieved from the struc-
	ture via the GetLastError( ) member.
	This makes the errors available to all
	RPC Clients outside the Services.
bool	Starts the Mail Slot Thread used for
StartActivityMailSlotThread( )	transmitting an “I'm alive” signal to
	the PAT NAU GuiMonitor.
	Returns FALSE if fails to start
	the thread.

[0470] Based on the DBAccess class, the Service class is a template for all the Services 477 to follow for proper operation. As a result, all its functions are virtual, and are defined in its children classes.

[0471]


Service Class
Virtual Functions	Purpose

virtual bool	Abstract definition to interface supports Service-
ConnectToTD( )	to-TD named pipe connections.
virtual void	Abstract definition to define the interface to
GenerateReport	launch a report.
(ReportType nReport)	(All of them are stubs for now, and not called by
	anyone.)
virtual void	Abstract definition to receive data into the Ser-
GetMessage( )	vice.
virtual PolicyType	Abstract definition to retrieve the access policy
GetPolicy( )	for the Service.
	(All of them are stubs for now, and not called by
	anyone.)
virtual bool	Abstract definition that defines an interface to
IsAvailable( )	evaluate whether a Service is available and ready
	to process requests or commands.
	(All of them are stubs for now, and not called by
	anyone.)
virtual void	Abstract definition that defines an interface to
MakeAvailable(	make a Service available.
SERVICESTATE	(All of them are stubs for now, and not called by
ServiceAction)	anyone.)
virtual void	Abstract definition for an interface that handles
ProcessRequest( )	IFE_Messages for the Service. In addition to
	specific messages designed for each Service, all
	ProcessRequest( ) functions should handle the
	SubProcessStart, SubProcessStop and
	SubProcessReinit messages to get themselves
	going and synchronized as needed by the rest
	of the system.
virtual void	Abstract definition to send data out of the Service
PutMessage( )	to TD and beyond.

[0472] The Cabin Services 477 control all the functions of In-Flight Service except those in which individual passengers 117 are involved. Cabin Services 477 are divided into the following Services: IFE Control Service 703, Movie Cycle Service, Video Service and the Video Announcement Service 704. In addition to its overcast versions of the Service class functions, CabinServiceClass includes:

[0473]


CabinServiceClass
Public Functions	Purpose

TIME	Retrieves the remaining flight time
GetRemainingFlightTime	using the CalcRemainingFlightTime
(PCONTEXT_HANDLE_TYPE	stored procedure.
phContext)
bool	Registers this named pipe with the
RegisterPipe	Transaction Dispatcher to make I/O
(HANDLE hPipeHandle)	possible.
bool	Transfers the data contained in
SetStatus	pszData into the status message field
(STATUS_TYPE nStatusType,	identified by nStatusType.
char *pszData)
bool	Called by main( ) to get a pair of
startPipeThreads	named pipes to TD for this Service.
(ServiceProcessor
*pServiceProcessor)
bool	Called by main( ) to get the child's
StartProcessThreads	ProcessRequest( ) loop going by in-
(ServiceProcessor	voking ProcessRequestInterface( ).
*pServiceProcessor)
static UINT	Shared by all the CabinServiceClass
GetMessageThreadInterface	children, this launches the child's
(LPVOID lpParam)	GetMessage( ) function to handle its
	input from TD.
static UINT	Shared by all the CabinServiceClass
ProcessRequestInterface	children, this launches the local
(LPVOID lpParam)	ProcessRequest( ) function that loops
	forever handling the messages that it
	receives.
static UINT	Shared by all the CabinServiceClass
PutMessageThreadInterface	children, this launches the child's
(LPVOID lpParam)	PutMessage( ) function to handle its
	output to TD.
void	Initiates a delay for the number of
Wait(DWORD	seconds specified by the input para-
dwSeconds)	meter dwSeconds.

[0474] The IFEControlService 703 class is derived from the CabinService class and contains several additional sets of functions that are used sporadically throughout the flight including:

[0475]


Function Set	Tables Used

IFE State Changes	Aircraft, Order_—
Flight Duration
Management
Statistics	Member, PassengerMap, PassengerStatistics, Set_—
Surveys	SurveyAnswer
Seat Transfers
Database Backup	All Database Tables

[0476] CAPI support 717 includes the following public functions accessed by CAPI.CPP 701 calls (having the same name):

[0477]


IFEControlService Class
Public Functions	Purpose

bool	Formats an IFE Message as specified
CommandSeat	by nCommand and transmits the mes-
(PCONTEXT_HANDLE_TYPE	sage to the seat specified by
phContext, SEAT_COMMAND	pszSeatName.
nCommand,
PGENERIC_TEXT pszSeatName)
bool	Due to a CAPI call, Formats and
SeatTransferInit	sends an IFE_Message to the Seat
(PGENERIC_TEXT pszSeat1,	NAU, which is where the actual
PGENERIC_TEXT pszSeat2)	transfer takes place. The data in the
	message reflects the two seats that are
	to be transferred.
void	Formats and transmits an unsolicited
SendStatusMessage	Status Window Message to the GUI.
(PCONTEXT_HANDLE_TYPE
phContext)
bool	Calls the local SetState( ) to update
SetIFEState	the system state information. IFE
(PCONTEXT_HANDLE_TYPE	State is a term that describes whether
phContext,	the IFE System is IDLE, STARTED,
IFESTATE IFEStateValue)	PAUSED, and more. This allows
	CAPI to alter these states to either
	free up services or disable them as
	appropriate for the current runtime
	state of the system. For example,
	when the system is IDLE or
	PAUSED, movies cannot be
	viewed which affects the Movie
	Cycle Service as well as the Movie
	Rental Service.
void	Called to refresh the value contained
SetRemainingFlightDuration	in the tmRemainingFlightDuration
(PCONTEXT_HANDLE_TYPE	which is defined statically in the
phContext)	CabinService class. This function is
	called periodically from the
	IFEControlService::Time-
	SynchronizationThread( ) thread to
	update the value as the flight pro-
	gresses, and directly from the CAPI
	when a change to the flight duration
	occurs.

[0478] In addition to the CAPI support functions 717, the IFE Message Support 718 also handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. In addition to the standard messages, this class handles the following messages: Statistics, Survey, SeatFault, FlightInfoRequest and DatabaseBackup.

[0479]


			Tables
IFE Message	Function Called	Purpose	Affected

DatabaseBackup	ProcessDatabase	Generates a	All database
	Backup( )	backup of the	tables
		entire CFS
		database to
		recover after a
		possible CFS
		hard disk
		failure.
FlightInfoRequest	ProcessFlightInfo( )	Gathers flight	Aircraft
		information	FlightV
		from the CFS
		database and
		uses the in-
		formation to
		populate an
		IFE_Message.
		The
		IFE_Message
		is then returned
		to the request-
		ing program
SeatFault	ProcessSeatFault( )	Updates the	PassengerMap
		database,
		clearing or set-
		ting a fault in-
		dication for the
		seat or range of
		seats in the IFE
		message
Statistics	ProcessStatistics( )	Stores statisti-	Member
		cal information	Set_{—Passenger-}
		from the seats	Map
		to the database	Passenger-
		and prepares	Statistics
		them for output
		to a text file.
		Statistics in-
		clude informa-
		tion such as
		how many
		hours of which
		movie was
		viewed, which
		games were
		played and
		more.
SubProcesStart	InitService( )	Establish IFE	Aircraft
		State and tell it
		to all affected
		programs via
		IFE Messages.
		Calls
		StartTime-
		Synchroniza-
		tionThread( )
		to launch
		Time-
		Synchroniza-
		tionThread( )
Survey	ProcessSurvey( )	Stores the	Survey
		answers given	SurveyAnswer
		by passengers	Survey-
		to survey ques-	AnswerKey
		tions available	Survey-
		through the	Question
		IFE system.
		These answers
		are stored in
		the database, as
		well as pre-
		pared for out-
		put to a text
		file

[0480] The TimeSynchronizationThread( ) thread 716 in the IFEControlService class 703 is responsible for managing flight duration information, which changes all the time. It uses SetRemainingFlightDuration( ) to update values, and calls AutoEndRevenue( ) to send a Stop Revenue Unsolicited Message to the GUI 426 once there is no time for further revenue purchases.

[0481] The PlayerConfiguration class supports any Service that uses video players, such as the MovieCycle, VideoAnnouncement and Video Services 704. The PlayerConfiguration class contains all pertinent information necessary to describe information specific to a Movie Cycle or Video Announcement. The PlayerConfiguration class also contains the methods needed to issue all appropriate messages to start a specific Movie Cycle or Video Announcement.

[0482]


PlayerConfiguration
Class Public Functions	Purpose

PlayerConfiguration	Creates a PlayerConfiguration object
(Queue *pParentQueue,	of specified Name, Intermission Time
CString csName,	and Start time. In addition, a refer-
CString csAddress,	ence to the parent object's queue is
TIME tmIntermission,	stored in order for this
TIME tmStart)	PlayerConfiguration object to com-
	municate with the parent object.
PlayerConfiguration	Same as above, except default values
(Queue *pParentQueue,	for Intermission Time and Start Time
CString csName,	are assigned as Zero.
CString csAddress)
void AddPlayer	Adds the specified player to this
(CString csPlayerName,	Player Configuration. If the program
BYTE bySegment,	to be played is a Video Segment, then
BYTE byRepeat,	a segment number is provided, other-
DWORD dwMediaId)	wise a value of zero is passed in the
	bySegment argument. If the repeat
	flag is set TRUE then the associated
	player is placed into it's REPEAT
	state.
bool ChangeCabinAudioLevel	Updates internal data structures for
(BYTE byAudioLevel,	this PlayerConfiguration object with
BYTE byZone)	the audio level specified in the
	byAudioLevel argument.
void CommandCabinAudio	Transmits the necessary messages to
(bool bAudioOn)	the Backbone NAU which command
	the PESC-V to make the necessary
	cabin audio connections for the zones
	associated with this Player Config-
	uration object. If the input argument
	bAudioOn is TRUE, the connections
	are enabled, if bAudioOn is FALSE,
	the connections are disabled.
void CommandCabinVideo	Sends messages to the PESC-V to
(bool bVideoOn)	activate or de-activate the Overhead
	Monitors and override the in-seat
	video displays associated with this
	Player Configuration object. A value
	of TRUE for the input argument
	bVideoOn causes cabin video con-
	nections to be enabled, a value of
	FALSE for bVideoOn causes cabin
	video connections to be disabled.
bool CommandPlayer	Transmits the player command speci-
(CString csPlayerName,	fied by nCommand to the player
PLAYERCOMMANDS	specified by csPlayerName. Any
nCommand,	additional data needed for the com-
PGENERIC_TEXT pszExtra)	mand must be passed in pszExtra.
bool CommandPlayers	Issues the commands to start, stop or
(PlayerCommands	rewind the player.
nPlayerCommand)
bool CreateAssignmentMap	Populates the static data structure
(PCONTEXT_HANDLE_TYPE	AssignMap with a status record for
phContext)	each LRU of type VCP residing in
	the LRU table.
BYTE GetCabinAudioZoneMap( )	Returns the Cabin Audio Zone
	BitMap.
BYTE GetCabinVideoZoneMap( )	Returns the Cabin Video Zone
	BitMap.
CString GetConfigAddress( )	Returns the Configuration Address.
PLAYERSTATE	Returns the cumulative state of all
GetConfigState( )	players currently assigned in this
	PlayerConfiguration object.
PLAYERSTATE	Returns the state of the Player's
GetConfigState( )	Configuration.
void GetConfigStatus	Returns information pertinent to this
(ULONG *ulCurrentViewing,	PlayerConfiguration object. The
long *tmElapsed,	information returned is:
long *tmRemaining,	Number of configurations started
long *tmNextShow)	Elapsed time current configuration
	has been playing
	Remaining play time for current
	configuration
	Number of minutes until the next
	Configuration starts.
ConfigState GetCurrState( )	Returns the current configuration
	state.
TIME GetCycleTime( )	Returns the sum of the Longest Pro-
	gram Time and the Intermission.
int GetCycleTimes	Computes a list of start times for all
(TIME tmFlightRemaining,	movie cycles contained in this
CDwordArray	PlayerConfiguration object. Cycle
*dwCycleTimeList)	time values are store in
	dwCycleTimeList and the number of
	elements added to the array is re-
	turned to the calling function.
long GetLongestProgramTime( )	Returns the Longest Program dura-
	tion in minutes.
CString	Returns the value of the Longest VCP
GetLongestProgramVcp( )	Program name.
DWORD GetMediaId	Returns the MediaId associated with
(CString csPlayerName)	the Video Player specified in
	csPlayerName. A value of - 1 is
	returned if an invalid player name
	is specified.
CString GetName( )	Returns the configuration name.
int GetPlayerList	Populates a CStringArray with a list
(CStringArray &csList)	of the VCP Player Names currently
	associated with this
	PlayerConfigurationObject.
WORD GetPlayerStateCount	Returns the number of players in this
(PLAYERSTATE nPlayerState)	PlayerConfiguration object that are
	currently in the state specified by
	nPlayerState.
ConfigState GetPrevState( )	Returns the previous configuration
	state.
BYTE GetSeatVideoZoneMap( )	Returns the Seat Video Zone BitMap.
TIME GetStartTime( )	Returns the Start Time.
bool GetTimeoutFlag( )	Returns the value of the Timeout
	Flag.
PLAYERSTATE GetVCPState	Returns the state currently stored in
(CString csVCPName)	the assignment map for the player
	specified by csVCPName.
bool IsCabinAudioActive( )	Returns a value of TRUE to the call-
	ing function if cabin audio is being
	used by any of the currently active
	assignments. A value of FALSE is
	returned otherwise.
bool IsLastViewing	Determines whether or not the cycle
(TIME tmFlightRemaining)	being played is the final cycle based
	on the remaining time in the flight. It
	returns a value of TRUE if the last
	cycle has started and returns a
	value of FALSE otherwise.
bool IsRunning( )	Returns TRUE if the current state is
	IDLE.
bool IsTransitionActive( )	Returns TRUE if Transition is
	marked as active.
bool IsValidVCP	Returns a value of TRUE to the call-
(CString csVCPName)	ing function if the player name speci-
	fied by the csVCPName argument is
	found in the Assignment map.
	Otherwise a value of FALSE
	is returned.
void Purge( )	Removes references to all video
	player names and configuration data
	associated with this
	PlayerConfiguration Object.
void RecoverCycle	Extracts recovery information from
(IFE_Message	the IFE_Message object referenced
*msgRecoveryInfo)	by msgRecoveryInfo, converts the
	data into Binary and uses the con-
	verted data to initialize timing
	information for this
	PlayerConfiguration object.
bool ReplacePlayer(	Removes the player identified by
CString &csOld,	csOld from this PlayerConfiguration
CString &csNew)	object and adds the player identified
	by csNew to this PlayerConfiguration
	object.
void ResetTransitionActive( )	Sets Transition to InActive.
void SetAudioDistributionInfo	Stores the Audio distribution infor-
(BYTE byAudioMap,	mation for this Player Configuration.
BYTE byMapType,
CByteArray *pbyVolume)
bool SetConfigState	Sets the state of this
(ConfigState nState)	PlayerConfiguration object to the
	value specified by nState. Performs
	all initialization necessary to make
	the transition into the new state. Re-
	turns TRUE if the state was success-
	fully entered, returns FALSE
	otherwise.
void SetIntermission	Sets the Intermission Duration for
(TIME tmIntermission)	this Player Configuration.
void SetLongestProgram	Identifies a VCP Name and Program
(int nPlayTime,	Duration as the longest program in
CString csPlayerName)	this PlayerConfiguration.
void SetStartTime	Sets the player start time.
(TIME tmStartTime)
void SetTransitionActive( )	Sets Transition to Active.
int SetVCPAssignment	Updates the pConfig entry in the
(int nLockState)	PlayerMap data structure associated
	the player identified by csVCPName.
	If the value of nLockState is LOCK
	the pointer to this
	PlayerConfiguration object is written.
	If the value of nLockState is
	AVAILABLE and the player is cur-
	rently assigned to this player config-
	uration object, the pConfig field is
	set to NULL.
	Returns the number of players which
	were successfully assigned.
bool SetVCPState	Updates the entry in the PlayerMap
(Cstring csVCPName,	data structure associated the player
PLAYERSTATE nVCPState,	identified by csVCPName with the
DWORD dwVCPTime)	value contained in the nVCPState
	argument.
void	Stores the video distribution informa-
SetVideoDistributionInfo	tion for this Player Configuration.
(BYTE byRFChannel,
BYTE bySeatMap,
BYTE byOHMap,
BYTE byMapType)
void UpdateConfigState	Updates the state of this
(VCP_Message	PlayerConfiguration object based.
*pMessage)	The state may be changed based on
	the content of the input message or
	based on a timeout applied to the
	current state.
void UpdateConfigTimeout( )	Sets the state of the
	bConfigTimeoutFlag variable TRUE
	if the elapsed time for the current
	state has been exceeded. Otherwise,
	the bConfigTimeoutFlag variable is
	set False.
void UpdateCycleStatus	Used periodically to transmit the
(TIME tmStatusUpdateRate,	Movie Cycle Times (based on
TIME tmRemainingCycleTime)	RemainingCycleTime) message to the
	Seat NAU. Also periodically trans-
	mits a RecoveryInfo message to the
	IFEControlService.

[0483] Throughout the In-Flight operation, one or more movies continuously play, all starting together as a set, providing maximum viewing possibilities for the passengers 117. This is known as Movie Cycling. The Movie Cycle Service controls the synchronization of these cycles.

[0484] Derived from the CabinService class, MovieCycleClass is responsible for keeping track of the remaining time of the flight, as well as the longest movie duration. It starts a cycle, stops a cycle, pauses a cycle, and recovers a cycle. The following database tables are used to support the MovieCycle Class: Member, MovieCycle, Set_, VideoMedium, Videoplayer, VideoSegment, and VideoUse.

[0485]


MovieCycle Class Public
Functions	Purpose

bool	Adds a player to a movie cycle.
AddPlayerToMovieCycle
(PCONTEXT_HANDLE_TYPE
phContext,
PGENERIC_TEXT
MovieCycleName,
PGENERIC_TEXT
PlayerName)
bool	Modifies the movie cycle
ChangeMovieCycleIntermissionTime	intermission time.
(PCONTEXT_HANDLE_TYPE
phContext,
PGENERIC_TEXT
MovieCycleName,
TIME Intermission)
bool	Update the start delay time for the
ChangeMovieCycleStartTime	PlayerConfiguration object speci-
(PCONTEXT_HANDLE_TYPE	fied by MovieCycleName. Updates
phContext,	the start delay locally: The value is
PGENERIC_TEXT	written to the database as part of
MovieCycleName, TIME StartDelay)	the StartMovieCycle processing.
APIResult	Calculates the number of minutes
GetFirstMovieCycleTime	until each of the remaining movie
(PCONTEXT_HANDLE_TYPE	cycles starts. Returns the first start
phContext,	time in tmMinUntilStart. The re-
PGENERIC_TEXT	turn value is APIOK if there are 2
pszMovieCycleName,	or more entries in the list and
TIME *tmMinUntilStart)	APIEndOfList if there is only 1
	entry in the list.
bool	Returns TRUE if the movie cycle
GetMovieConfigurationState	specified by pszMovieCycleName
(PCONTEXT_HANDLE_TYPE	is running.
phContext,
PGENERIC_TEXT
pszMovieCycleName)
bool	Returns the duration, in minutes, of
GetMovieCycleDuration	the Movie Cycle specified by
(PCONTEXT_HANDLE_TYPE	pszMovieCycleName. A return
phContext,	value of TRUE indicates that the
PGENERIC_TEXT	specified movie cycle was found
pszMovieCycleName,	and the time is valid.
TIME *tmDuration)
APIResult	After GetFirstMovieCycleTime( )
GetNextMovieCycleTime	has been called to calculate movie
(PCONTEXT_HANDLE_TYPE	cycle times and return the first one,
phContext,	this can be called iteratively to re-
TIME *tmMinUntilStart)	trieve the remaining movie cycle
	start times.
	Returns APIEndOfList for the last
	entry in the list.
	Returns APIOK for all other
	entries.
bool	Removes the PlayerName player
RemovePlayerFromMovieCycle	from the movie cycle
(PCONTEXT_HANDLE_TYPE	MovieCycleName.
phContext,
PGENERIC_TEXT
MovieCycleName,
PGENERIC_TEXT PlayerName)
bool	Swaps players (usually because of
ReplaceMovieCyclePlayer	a hardware failure, and movies
(PCONTEXT_HANDLE_TYPE	must be moved to new devices).
phContext,
PGENERIC_TEXT
pszMovieCycleName,
PGENERIC_TEXT
pszPlayerToRemove,
PGENERIC_TEXT
pszPlayerToAdd)
bool	Sets the movie cycle update rate.
SetMovieCycleUpdateRate	The movie cycle update rate is the
(PCONTEXT_HANDLE_TYPE	rate at which the system transmits
phContext,	movie cycle update information to
long lSeconds)	the seats in seconds.
bool	Starts the specified
startMovieCycle	MovieCycleName at the given
(PCONTEXT_HANDLE_TYPE	tmStartTime.
phContext,
PGENERIC_TEXT
MovieCycleName,
TIME tmStartTime)
bool	Stops the specified Movie Cycle.
StopMovieCycle
(PCONTEXT_HANDLE_TYPE
phContext,
PGENERIC_'TEXT
MovieCycleName)
void	Notifies MovieCycleService that a
UpdateSystemState	change to the system state has
(PCONTEXT_HANDLE_TYPE	occurred. The Service retrieves the
phContext)	system state from the database and
	updates the state of the active
	cycle(s) accordingly.

[0486] IFE Message Support 718 handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. In addition to the standard IFE messages, this class handles the following messages: MovieTimes and MovieCycle.

[0487]


IFE Message	Function Called	Purpose

MovieCycle	StopMovieCycle( ) or	Starts or Stops the movie
	StartMovieCycle( )	cycle as needed.
MovieTimes	UpdateMovieTimes( )	Updates the duration of the
		movies that are playing or
		scheduled to play.
SubProcessStart	InitService( )	Creates a PlayerConfiguration
		object, determines what the
		players are doing using
		UpdateSystemState( )

[0488] Flight Attendants often need the ability to view and listen to videos to verify quality and accuracy (for example, to determine if the expected movie is installed in the proper player 227). The Video Service functions support this capability. Derived from the CabinService class, the VideoServiceClass is responsible for connecting the GUI 426 to the individual players 227 for preview and overhead control. The following database tables are affected by the Video Service Class: VideoMedium, VideoPlayer, and VideoUse.

[0489] The following table shows those functions that are used by CAPI.CPP calls 701:

[0490]


VideoServiceClass Public
Function	Purpose

PLAYERSTATE	Uses PlayerConfiguration class functions to
CommandPlayer	tell VCP pszPlayerName to perform
(PGENERIC_TEXT pszPlayerName,	nCommand (e.g., start, stop, play . . . etc).
PLAYERCOMMANDS nCommand,
PGENERIC_TEXT pszExtra)
void	Returns the state and channel # of the
GetOverhead	currently selected Overhead Video source.
(OVERHEADSTATETYPE
*pOHState,
long *pChannel)
PLAYERSTATE	Uses CommandPlayer( ) to prompt the VCP to
GetPlayerState	supply its current state.
(PGENERIC_TEXT pszPlayerName)	Returns this state to caller.
long	Uses CommandPlayer( ) to prompt the VCP to
GetRemainingPlayerTime	supply its remaining play time.
(PGENERIC_TEXT pszPlayerName)	Currently, this always returns ZERO.
bool	Sets the Cabin Audio volume level.
SetAnnouncementAudioLevel	A value of −1 for dwZone specifies that PA
(PCONTEXT_HANDLE_TYPE	volume for all zones is to be set to the
phContext,	specified audio level. If Persist is set TRUE,
long lAudioLevel,	this updates the database as well, making
DWORD dwZone,	this a permanent setting.
bool Persist)
void	Transmits a message to the PESC-V via the
SetOverhead	Backbone NAU to identify which channel
(OVERHEADSTATETYPE OHState,	represents the overhead video source. All
long Channel,	parameters are Input Parameters.
PGENERIC_TEXT pszPlayerName)
bool	Tells the VCP NAU to set the given
SetPlayerSegment	pszPlayerName VCP to the selected lSegment.
(PGENERIC_TEXT pszPlayerName,	Returns FALSE if Segment value is invalid (>
long lSegment)	0xff).
void	Notifies this Service that a change to the
UpdateSystemState	system state has occurred.
(PCONTEXT_HANDLE_TYPE
phContext)

[0491] IFE Message Support 718 handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. In addition to the standard IFE messages, this class handles the following messages: FailedPlayer, VCPStatus, and VideoControl.

[0492]


IFE Message	Function Called	Purpose

FailedPlayer	ProcessFailedPlayer( )	Returns to the caller the
		number of players and
		which ones are flagged as
		failed.
SubProcessStart	InitService( )	Creates a
		PlayerConfiguration
		object and initialize
		its variables.
VCPStatus	ProcessVCPStatus( )	Updates the VCPState (via
		PlayerConfiguration::
		SetVCPState( )),
		updates the database and
		tell the MovieCycle Service
		of the changed status via an
		IFE_Message.
VideoControl	ProcessVideoControl( )	Updates the named player's
		status as given in the
		message, and outputs it
		to the Status Window.

[0493] The VideoAnnouncementService class is derived from the CabinService class and contains several additional sets of functions that are used sporadically throughout the flight to support the playing of video clips, such as a safety video that must be broadcast to all passengers 117 at specific times during the flight. It provides the following functionality: creates a message for cabin configuration (cabin audio/video), works with MovieCycleService to pause the movie cycle, starts an announcement tape, and talks to PESC-V 224b to control PA. The database tables affected by the VideoAnnouncementService Class are: Aircraft, PA_Volume, VA_Distribution, VideoMedium, and VideoSegment.

[0494] The following table shows those functions that are used by CAPI.CPP calls 701:

[0495]


VideoAnnouncementService Public
Functions	Purpose

APIRESULT
GetFirstVideoAnnouncementPlayList
(PCONTEXT_HANDLE_TYPE phContext,
PGENERIC_TEXT
pszVideoAnnouncementName,
PGENERIC_TEXT pszPlayerName,
VIDEOANNOUNCEMENTSTATUSTYPE
*nState)
APIRESULT
GetNextVideoAnnouncementPlayList
(PCONTEXT_HANDLE_TYPE phContext,
PGENERIC_TEXT
pszVideoAnnouncementName,
PGENERIC_TEXT pszPlayerName,
VIDEOANNOUNCEMENTSTATUSTYPE
*nState)
bool
ReplaceVideoAnnouncementPlayer
(PCONTEXT_HANDLE_TYPE phContext,
PGENERIC_TEXT pszAnnouncementName,
PGENERIC_TEXT pszReplacementPlayer)
bool	Starts the
ResumeVideoAnnouncement	PlayerConfiguration
(PCONTEXT_HANDLE_TYPE phContext)	Object associated with
	the next Video
	Announcement to be
	played.
bool	Starts the specified video
StartVideoAnnouncement	announcement.
(PCONTEXT_HANDLE_TYPE phContext,
PGENERIC_TEXT pszAnnouncementName)
bool	Stops the specified video
StopVideoAnnouncement	announcement.
(PCONTEXT_HANDLE_TYPE phContext,
PGENERIC_TEXT pszAnnouncementName)
void	Notifies this Service that
UpdateSystemState	a change to the system
(PCONTEXT_HANDLE_TYPE phContext)	state has occurred.

[0496] In addition to the CAPI support functions 717, IFE Message Support 718 also handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. In addition to the standard IFE messages, this class handles the following messages:

[0497]


IFE Message	Function Called	Purpose

Ack or Nak	SetNextState( )	Sets the next state for the video
		announcement associated with
		the Player Configuration Object
		pPlayerConfig.
PlayNextVA	PlayNextAnnouncement( )	First, determines if the next
		announcement in the Video
		Announcement Play list requires
		installation of a new tape (i.e.,
		Media ID). If so, then an
		Unsolicited message is
		transmitted to the GUI and the
		video announcement cycle is
		suspended. Once paused, the
		cycle must be restarted via
		either StartVideoAnnouncement( )
		or ResumeVideoAnnouncement( ).
SubProcessStart	InitService( )	Performs the necessary Inits to
		get this Service going, including:
		SetAudioDistributionInfo( )
		SetVideoDistributionInfo( )
		SetPlayerInfo( )

[0498] Sales Services control all the functions of In-Flight Service in which goods and entertainment are made available to passengers 117. Sales Services 482-486 are divided into the following Services: GamesService 482, MovieSaleService 483, CatalogService 484, DutyFreeService 486, and DrinkService 485.

[0499] The design structure of the Sales Service classes are similar to the Cabin Service classes, except that sales services 482-486 launch many more ProcessRequest( ) threads 715 to be able to service as many passengers 117 as possible. This is not necessary for the Cabin Services because they do not service individual passengers 117; they service the system as a whole.

[0500] In addition to its overcast versions of the Service class virtual functions, SalesService Class includes its own virtual definitions within its children classes. This keeps the CAPI consistent in its calls:

[0501]


SalesService Virtual Function	Purpose

virtual bool	Abstract to cancel an open order.
CancelOrder
(ID OrderID)
virtual ID	Abstract to Create an order.
CreateOrder
(unsigned char *ProductCode,
long Quantity,
LRU_NAME Seat,
unsigned char
*EmployeeNumber,
long lProductMap,
MONEY AmountDue)
virtual bool	Abstract to schedule an Order for
DeliverOrder	Delivery.
(ID OrderID,
GENERIC_TEXT
EmployeeNumber)
virtual bool	Abstract to record the payment for an
PayForOrder	order.
(ID OrderID,
MONEY AmountCash,
MONEY AmountCredit,
GENERIC_TEXT CurrencyCode,
GENERIC_TEXT
EmployeeNumber,
GENERIC_TEXT
AccountNumber,
GENERIC_TEXT ExpirationDate,
GENERIC_TEXT CardName,
CREDITCARDS CardType)
virtual bool	Abstract to Refund an order.
RefundOrder
(ID OrderID,
GENERIC_TEXT
EmployeeNumber,
bool RevokeProduct)
virtual bool	Abstract to start the I/O with
StartPipeThreads( )	Transaction Dispatcher.
virtual bool	Abstract to start ProcessRequest( )
StartUpProcessThreads( )	threads.

[0502] SalesService also provides several ‘generic’ sales functions, as shown in the sub-sections that follow.

[0503] The following functions are called by CAPI functions. In the Sales Services 482-486, all CAPI calls cause an update message to be built and sent to the applicable seat 123, so that it knows the status of its sales.

[0504]


SalesServiceClass Public Functions	Purpose

bool	Removes the any OrderId records
BackOrderOut(	from the database.
CONTEXTHANDLESTRUCT
*pContextHandle,
ID OrderID)
bool	Sets the status of the store to Closed.
CloseSalesStore(
ID StoreID)
SERVICESTATUSTYPE	Verifies the type of card, expiration
IsValidCreditCard(	date and checksum according to the
char *CardNumber,	policy of this card type.
char *ExpirationDate,
double CreditAmount,
CONTEXTHANDLESTRUCT
ContextHandle)
bool	Sets the status of the store to Open.
OpenSalesStore(
ID StoreID)

[0505] The following functions are provided to support these IFE Messages for all Sales:

[0506]


IFE Message	SalesService Function	Purpose

BackOut	bool	Removes the order from
	BackOrderOut(	the database. This is
	CONTEXTHANDLESTRUCT	usually due to an error
	*pContextHandle,	during processing, rather
	ID OrderID)	than a customer request.
Cancel	bool	Cancels an open order
	PrepareCancel(	upon customer request.
	CONTEXTHANDLESTRUCT
	*pContextHandle,
	Seat_Message *pSeatMessage)
CompleteUpdate	void	Collects revenue and
	ProcessUpdateRequest(	movie or game lock
	Seat_Message *pMsg,	information for a specified
	IfeIdType nProcessID,	seat and returns the data
	Queue *pTransmitQueue)	to the SeatNAU.
Delivery	bool	Prepares an order for
	PrepareDelivery(	delivery.
	CONTEXTHANDLESTRUCT
	*pContextHandle,
	Seat_Message *pSeatMessage)
IncrementalUpdate	void	See CompleteUpdate
	ProcessUpdateRequest( )	message above.
Payment	bool	Applies the provided
	PreparePayment(	payment information to
	CONTEXTHANDLESTRUCT	the specified order.
	*pContextHandle,
	Seat_Message *pSeatMessage,
	ID *OrderID)
Refund	bool	Processes a refund
	PrepareRefund(	request to return
	CONTEXTHANDLESTRUCT	payment(s) to a customer
	*pContextHandle,	and update inventory (if
	Seat_Message *pSeatMessage)	needed).

[0507] Movie Viewing is a highly variable feature of the system. At the discretion of the airline, and subject to change from time to time, different video offerings are free to certain classes of passengers 117, while others are chargeable. The Movies Sales Service 483 controls this feature. The database tables affected by the VideoAnnouncementService Class are: Policy, Price, VideoMedium, VideoSegment, and VideoUse.

[0508] Derived from SalesService class, the MovieServiceClass provides the functions needed to process the sales of movies onboard. Like CabinService class, it provides its own ProcessRequest( ), GetMessage( ), PutMessage( ), etc. functions.

[0509] The following overcast functions are called by their corresponding CAPI calls 701: CancelOrder( ), CreateOrder( ), DeliverOrder( ), PayForOrder( ), and RefundOrder( ).

[0510] In addition to the CAPI support functions, IFE Message Support 718 also handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. Currently, all of the supported messages are supported using inline code that includes functions from the generic SalesService class along with the following:

[0511]


IFE Message	Function	Purpose

Order	CreateOrder( )	See CAPI Support

[0512] Nintendo Video Games are available for passengers to enjoy. To play them, a request must be made and often a payment is required. The Games Rental Service 482 uses the database tables GameDetail, Policy, and Price.

[0513] Derived from SalesService class, the GameServiceClass provides the functions needed to process the sales of movies onboard. Like CabinService class, it provides its own ProcessRequest( ) 715, GetMessage( ) 719, PutMessage( ) 720, etc. functions.

[0514] The following overcast functions are called by their corresponding CAPI calls: CancelOrder( ), CreateOrder( ), DeliverOrder( ), PayForOrder( ), and RefundOrder( ). See SalesService class for details.

[0515] In addition to the CAPI support functions 717, IFE Message Support 718 also handles incoming IFE Messages using its overcast ProcessRequest( ) thread 715. Currently, all of the supported messages are supported using inline code that includes functions from the generic SalesService class along with the following:

[0516]


IFE Message	Function	Purpose

Order	CreateOrder( )	See CAPI Support

[0517] Package Entertainment is a hybrid of Games and Movies Sales and is maintained within the MoviesSales class. It involves a one-time purchase to all entertainment services onboard. The Package Entertainment Functions may be used to control this capability, but currently the SEAT NAU and CAPI.CPP calls 701 route Package products to either the Game Service or the Movie Service, based on the product code that is used. The PackageDetail table is used to identify the components of a “Package”.

[0518] Purchasing goods through an electronic catalog is an enhancement provided by the system 100. All functions that control it are kept in the Catalog Sales Service 484. The following tables support the feature: Address, Order_, and ShippingRate.

[0519] Ordering drinks through the In-Flight Entertainment system 100 is provided. All functions that control it are kept in the Drinks Sales Service 485. The following table supports the feature: Product

[0520] Purchasing onboard duty-free goods through the In-Flight Entertainment system 100 is provided. All functions that control it are kept in the Duty Free Sales Service 486. The following tables support the feature: Cart, CartInventory, Commitment, and InventoryLog.

[0521] All the application-level database functions are directly accessible via calls to the CAPI functions. These calls are available directly, or via the RPC server. Thus, any service as well as any RPC client can access the CAPI calls.

[0522] CAPI.CPP 701 contains the actual commands that interface to the database 493 and perform the application duties (such as CreateOrder( ), GetOrder( ), etc.). CAPI_S.C 702 is the RPC server whose functions are made available to RPC clients (via CAPI_C.C). The server functions use the CAPI.CPP 701 calls to perform application duties. They are used together to make up this set of routines. In addition, the PAT GUI 426 can also access CAPI.CPP via APIINT.CPP and CAPI_S.C in the RPCCLNT.DLL.

[0523] The cabin file server database 493 stores the following types of information. This information is utilized by both the cabin file server application and the PAT GUI 426 and is described in greater detail below.

[0524] The cabin file server database 493 stores other line replaceable units in the IFE system 100, the products and services available to the passengers 117, revenue due to the sales of products and services, system usage due to the flight attendants and passengers 117, surveys offered to passengers 117, the state of the cabin file server application, video announcements, and global attributes of the IFE system 100.

[0525] The cabin file server database 493 provides storage for line replaceable unit information. This enables the cabin file server application to communicate with and/or control these other devices. Some line replaceable unit information is provided by the two data files that are generated by the ACS tool. Line replaceable unit information is stored in the following tables: LRU, Member, PA_Volume, PassengerMap, Set_, and VideoPlayer.

[0526] All purchased goods and services, purchase summary information, complimentary service assignments, and movie lockout information is stored on a per passenger basis. This information may be swapped from one seat 123 to another seat to accommodate the occasion when a passenger 117 must be moved during a flight. Each passenger 117 is represented in a PassengerMap table by a single record. This record contains the following pertinent information:

[0527]


	Field Name	Purpose

	SeatNumber	Passenger seat
		number
	PassengerID	Passenger Identifier

[0528] When a passenger 117 changes seats, the SeatNumber fields of the two records involved are swapped. Thus, all the information associated with the passenger 117 is not with the seat 123, but with their PassengerID.

[0529] The viewing of any movie and/or the playing of any game can be locked out at any seat, usually at the request of a parent to prevent a child from seeing a certain movie or excessive game play. Each passenger 117 is represented in the PassengerMap table by a single record. This record contains the following pertinent information:

[0530]


	Field Name	Purpose

	SeatNumber	Passenger seat
		number
	MovieLockoutMap	Movie lockout bit map
	GameLockoutMap	Game lockout bit map

[0531] The MovieLockoutMap and GameLockoutMap fields are bit map fields whose bits correspond to individual movie and game titles, respectively. A movie or game is locked out when it's corresponding bit in this field is set to one.

[0532] Loss of communication with a seat display unit 122a is also recorded in the PassengerMap table.

[0533]


	Field Name	Purpose

	SeatNumber	Passenger seat number
	SeatCommSuccessCount	# Successful communications
	SeatCommFailCount	# Unsuccessful
		communications

[0534] At the beginning of each flight, the SeatCommFailCount and SeatCommSuccessCount fields for each seat are initialized to zero. The SeatCommFailCount field is incremented for each first-time-failure encountered for the corresponding seat 123 (i.e., increment if fail <= success). The SeatCommSuccessCount field is incremented for each first-time-success encountered for the corresponding seat (i.e., increment if success < fail). These rules are enforced through triggers on these database fields. The seat 123 is considered bad if the SeatCommSuccessCount is less than the SeatCommFailCount.

[0535] The cabin file server database 493 provides storage for product and service information (e.g., movie titles, viewing times, movie audio languages, game titles, audio entertainment titles, audio channels, etc.). This information is sent by the cabin file server application to the Seat Display Unit 122a for each flight. This enables up-to-date information to be presented to the passengers 117 so they can know which products and services are available to them and at what cost on a per flight basis. Product and Service information is stored in the follow MovieCycleing tables: AudioDetail, Cart, CartInventory, GameDetail, IFE_Service, InventoryLog, MovieCycleDetail, PackageDetail, Price, Product, ProductEffectivity, Route, ShippingRate, Store, VideoMedium, VideoPlayer, VideoSegment, and VideoUse.

[0536] Video Game information is maintained in the GameDetail table, one record per Title/EffectiuityDate combination:

[0537]


Field Name	Purpose

Title	The Game Title that is displayed on the seat display unit
	122a
EffectivityDate	The date on or after which this game information is
	effective.
RouteType	The flight route type during which this game is available.
ProductCode	Corresponds to a product code in the Price table for price
	lookups.

[0538] Video Game information is maintained in the VideoMedium table, one record per video program, one record per MediaTitle:

[0539]


Field Name	Purpose

MediaTitle	The Game Title that is displayed on the seat display
	unit 122
ProductCode	Corresponds to a product code in the Price table for
	price lookups.

[0540] The IFE system 100 can inhibit the selectability of these video programs based on the date stored in the EffectivityDate of the VideoSegment table. Movie titles are associated with a specific flight route through the RouteType field of the VideoUse table. Prices are controlled via these fields in the Price table, one per ProductCode/RouteType combination:

[0541]


Field Name	Purpose

ProductCode	Corresponds to Game or Movie Products for sale
RouteType	The flight route type during which this price applies
FreeMap	Identifies which zones (identified in bitmap) offer this
	product free of charge
Pricing1	Pricing structure for zone 1 during this flight route
Pricing2	Pricing structure for zone 2 during this flight route
Pricing3	Pricing structure for zone 3 during this flight route
Pricing4	Pricing structure for zone 4 during this flight route

[0542] The database tables used in Movie Cycle are: Member, MovieCycle, Set_, Videomedium, VideoPlayer, VideoSegemnt, and VideoUse.

[0543] Video sources such as video cassette player 227 or video reproducers (VR) 227 are assigned to a movie cycle through the Member and Set_tables. Each VCP or VR 227 is stored in the Member field of the Member table. Each movie cycle is stored in the SetName field of the Set_table. The following movie cycle information is stored in the database.

[0544] A movie cycle type is a predefined grouping of video reproducers 227 and movie titles. Movie titles are assigned to video reproducers 227 through the VideoMedium and VideoUse tables. The database 493 can store up to eight different movie cycle types. Information about each movie cycle type is stored in the MovieCycle table. A movie cycle can include from one to fifteen video reproducers 227 (i.e., one to fifteen records of the Member table can be associated with a single movie cycle in the Set_table).

[0545] The start time for a movie cycle is stored in the RelativeStartTime field of the MovieCycle table. It is stored in minutes relative to the time since movie cycle initiation at the primary access terminal 225. A between-cycle intermission time is stored in the IntermissionLength field of the MovieCycle table. It is stored in minutes and must exceed the time required to prepare the video reproducer 227 containing the longest playing tape for the next cycle (e.g., tape rewind).

[0546] The end time of a movie cycle is the time in which the final viewing of a particular movie cycle ends. The number of viewings that can be scheduled for each movie cycle depends upon the length of a single viewing of the movie cycle and the flight duration. The length of a single viewing of the specific movie cycle can be calculated by adding the IntermissionLength field of the MovieCycle table to the SegmentRunTime field of the VideoSegment table for the movie with the longest run time in the specific movie cycle. The expected flight duration is stored in the FlightDuration field of the Flight table.

[0547] Information about the state of a particular Video Reproducer 227 is stored in the State field of the VideoPlayer table. This information includes whether or not the video reproducer 227 is operational, whether or not the video reproducer 227 contains a tape, etc.

[0548] The number of minutes before the start of each cycle can be calculated using the RelativeStartTime field of the MovieCycle table, the calculated length of the single viewing of the movie cycle, and the IntermissionLength field of the MovieCycle table. The number of minutes before intermission for the current cycle is stored in the RemainingViewingTime of the MovieCycle table.

[0549] The number of minutes until the next viewing of a specific movie cycle is stored in the NextViewingTime of the MovieCycle table. The number of minutes remaining on the current viewing of the specific movie cycle is stored in the RemainingViewingTime of the MovieCycle table. The number of minutes elapsed into the current viewing of the specific movie cycle is stored in the ElapsedViewingTime of the MovieCycle table.

[0550] A predetermined set of movies and/or games can be assigned to an airline-defined package. Package information is stored in the PackageDetail table.

[0551] Audio programming (entertainment) can be distributed on a maximum of 83 mono audio channels, controlled by the AudioDetail table, one record per program. The title of each audio program is stored in the AudioTitle field. The channel of each Audio program is stored in the AudioChannel field.

[0552] The VideoMedium table stores up to four different languages for a particular video tape (e.g., movies). These languages are displayed on the display screen 122 for passenger selection. The languages are stored in the LanguageCode1, LanguageCode2, LanguageCode3, and LanguageCode4 fields of the VideoMedium table. Each video tape must have one language designated as the default primary language (i.e., LanguageCode1 must not be empty) but it can have up to three other languages. The relationship of the output configuration of the video players and available language configuration is stored in the VideoPlayer table.

[0553] Information about each video reproducer 227 is stored in the VideoPlayer table. In order to “preview” the output of a particular video player on the primary access terminal screen, both primary access terminal tuners (audio and video) must be tuned to the proper channels. Video channel information for each video reproducer 227 is stored in the VideoRF_Channel field. Audio time-slot information is stored in the various time slot fields (i.e., LeftTimeSlot1, RightTimeSlot1, LeftTimeSlot2, etc.).

[0554] A video reproducer 227 can be reassigned for use during a video announcement. The MediaType field in the VideoMedium table distinguishes a video announcement from a movie. The VideoUse table tracks which movie or video announcement is assigned to which video reproducer 227. When a video reproducer 227 is reassigned, the PlayerName field in the VideoUse table is modified. The playing status of each video reproducer 227 is stored in the State field of the VideoPlayer table.

[0555] Overhead monitors 162 can be assigned to a video source (i.e., video player 227) for movies. This information is stored in the OverheadAudioMap and OverheadVideoMap fields of the MovieCycleDetail table.

[0556] The cabin file server database 493 provides storage for revenue information (e.g., credit card data, cash collection data, etc.) concerning the sales of products (e.g., duty free) and services (e.g., movies and games). When a passenger 117 uses a credit card to pay for movies or games, this information must be stored in the database so that it can be transferred to the credit card company. Likewise, when a passenger 117 uses cash to pay for movies or games, this information must be stored in the database 493 so that the IFE system 100 has a record of how much cash should be collected by the flight attendant.

[0557] Revenue information is stored in the following tables: Address, BadCreditCards, Commitment, CreditCard, Currency_, Exchange, Flight, Order_, OrderHistory, PassengerMap, PAT_History, Policy, Price, Product, ProductEffectivity, ShippingRate, and ValidCardData.

[0558] The purpose of transaction processing is to maintain a record of monetary transactions for service and products. When a flight attendant is involved with an order placed by a passenger 117 (e.g., order refunded, order placed at the PAT, etc.), then the flight attendant ID is stored in the FlightAttendant field of the Order_table.

[0559] Information about each product and service is stored in the Product table. Information about each package of goods or services is stored in the PackageDetail table. The pricing information for each product, service, and package is stored in the Price table. Prices can be altered according to the policy stored in the PolicyDescription field of the Policy table. For example, the policy may specify different service price data for movies and games offered in each seat class zone (e.g., first class) in the aircraft 111.

[0560] Services and products may be paid by cash, credit card, or a combination of the two. Cash and credit card payments are respectively stored in the CashTotal and CreditTotal fields of the Order_table. Orders are comprised of sets of products or services of the same type. If the passenger 117 uses a credit card, the credit card information (e.g., passenger name, account number, etc.) is stored in the CreditCard table.

[0561] Cash transactions may be represented in up to 30 different currency types. Information about each currency type is stored in the Currency_table. Each aircraft 111 has associated with it a base currency that is stored in the BaseCurrencyCode field of the Aircraft table.

[0562] Passengers 117 may pay for products and services using any single card from the credit card types accepted by the airline. Information about each valid credit card type is stored in the ValidCardData table. The credit card payment made on a given order is stored in the CreditTotal field of the Order_table. This payment is recorded in the base currency type as specified in the BaseCurrencyCode field of the Aircraft table.

[0563] Credit card numbers are validated against the standard number format and range for that particular credit card type. This standard number format is stored in the ValidationPattern field of the ValidCardData table. Also, credit card transactions are validated against the credit limit specified by the passenger 117 for that particular credit card type. This credit limit is stored in the CreditLimit field of the ValidCardData table. In addition, each credit card is compared against the credit card numbers in the BadCreditCards table. This table may contain up to 10,000 records, for example.

[0564] All transactions (i.e., service orders, product orders) processed by the system are stored in the Order_table. The state of an order (open, paid, canceled, refunded) is stored in the State field of the Order_table. For refunded orders, a duplicate order record is created with the AmountDue field, the CashTotal field, the CreditTotal field, and the Quantity field all set to negative amounts. Orders that are placed at the primary access terminal 225 also have a corresponding entry in the PAT_History table. A new record is generated for the OrderHistory table for each change to the State field or the Delivered field.

[0565] The following information is maintained for each order:

[0566]


Table	Field	Description

PassengerMap	SeatNumber	seat number
Product	ProductDescription	service or product ordered
Order_—	Quantity	quantity of service or product
		ordered
CreditCard	all fields	credit card information for credit
		card orders
Price	UnitPrice	unit cost of service or product
		ordered
Order_—	AmountDue	total cost of service or product
		ordered

[0567] Prior to shutdown of the IFE system 100, a message is displayed on the primary access terminal 225 if the database 493 contains any open transactions from the current flight. The number of open orders for the current flight is always displayed in the status window on the primary access terminal 225. This is calculated by counting each order in the Order_table (for the current flight) whose associated State field is set to “Open”.

[0568] A running tabulation of all expenses incurred for each passenger during the current flight can be displayed on the seat display unit 122a or seat display 122. Each order is associated with a specific passenger 117 via the PassengerID field of the Order_table. The total cost of each order is stored in the AmountDue field of the Order_table. Total expenses incurred for a particular passenger 117 is the sum of the total cost of each order placed by the specific passenger 117.

[0569] The following subsections describe selected database interactions that occur when the corresponding functions in the SalesServiceClass classes are executed.

[0570] Upon cancellation of any cash passenger product and/or service order that has not been paid, the State field of the Order_table is changed from “Open” to “Cancelled”. If the service (i.e., video game or movie) is revoked from the passenger 117, then the ProductRevoked field in the Order_table is set to TRUE.

[0571] A list of orders can be generated for which cash collection is to be made in-flight. Information related to each order is as follows:

[0572]


Table	Field	Description

PassengerMap	SeatNumber	seat number
Product	ProductDescription	product or service
		ordered
Order_—	AmountDue	amount due

[0573] Orders can be listed by service type and/or by general service zone. The service type of an order (i.e., game, movie, package) is stored in the ServiceType field of the Product table. The general service zone of the passenger 117 that placed the order is stored in the SetName field of the Set_table.

[0574] A list of orders can be generated for which delivery is to be made in-flight. Information related to each order is as indicated above. Orders can be listed by service type and/or by general service zone.

[0575] Complimentary service for movies, games, and/or entertainment packages may be offered to individual passengers or to the entire aircraft 111. For individual passengers, an order is placed in the Order_table for each passenger 117 receiving a service that is complimentary, the PayCurrencyCode field is set to “Free” and the State field is set to “Paid”. The order is then associated with the record in the PassengerMap table where the SeatNumber corresponds to the specific passenger 117.

[0576] To provide complimentary service for the entire aircraft 111, all entertainment (movies, games, packages) must be complimentary. A single order is placed in the Order_table: The PayCurrencyCode field is set to “Free” and the State field is set to “Paid”. The order is then associated with the record in the PassengerMap table where the SeatNumber field is set to “Allseats”. The FreeServicesMode field of the Aircraft table is set to TRUE.

[0577] The system 100 can support up to thirty forms of currency. Currency information is stored in the Currency_table. Exchange rate information is stored in the Exchange table. Currency exchange rate calculations can be performed that support a display with up to four decimal places. The number of decimal places to display is stored in the DisplayPrecision field of the Currency_table.

[0578] Each currency is associated with a Policy table entry to specify how to convert from one currency to another. For example, the policy for converting to US dollars might be to round to the nearest penny, or nearest whole dollar if the airline does not wish to deal with change. The policy actually points to the applicable stored procedure to perform this function.

[0579] The cabin file server database 493 provides storage for system usage by both the flight attendants and passengers 117.

[0580] The cabin file server database 493 keeps track of each time the flight attendant logs on and off. Additionally, the flight attendants may also enter flight identification information (e.g., flight number, destination, etc.) which is stored in the cabin file server database 493. Flight attendant activity is stored in the following tables: Access, Flight, and Personnel.

[0581] Each time a user (i.e., employee) logs in to the IFE system 100, this login information is stored in the Access table. It is also added to the Personnel table (once for each user) if a predefined set of valid users does not already exist. If a predefined set of valid users is preloaded into the Personnel table, then each user that tries to login can be validated against this pre-defined set of valid users.

[0582] An access level for each user is stored in the AccessLevel field of the Personnel table. This access level can be used to direct the user's access throughout the system 100, effectively controlling what they can see or do. For example, a Service Person should not have access to Revenue Modification functions.

[0583] When users are required to insert a magnetically encoded card during the logon process, the card is encoded with the user ID (EmployeeNumber field), pin number (PIN field), and grade level (AccessLevel). This information is stored in the Access table for each login. This information is also added to the Personnel table (once for each user) if a pre-defined set of valid users does not already exist. If a predefined set of valid users is preloaded into the Personnel table, then each user that tries to login can be validated against this predefined set of valid users.

[0584] In the case where the card read is not successful, the user must manually enter the user ID, pin number, and grade level. This information is stored in the Access table for each login. This information is also added to the Personnel table (once for each user) if a predefined set of valid users does not already exist. If a predefined set of valid users is preloaded into the Personnel table, then each user that tries to login can be validated against this predefined set of valid users.

[0585] The cabin file server database 493 also logs system activity (i.e., passenger usage of the system 100 from the seat display unit standpoint). The database 493 stores how much time each seat spent on each movie, on each game, and on each audio selection. This allows the airline to see how passengers 117 are using the system 100.

[0586] Passenger activity is stored in the following tables: PassengerStatistics.

[0587] The following passenger statistic information is stored in the database 493:

[0588]


Table(s)	Field(s)	Definition or Comment.

PassengerMap	SeatNumber	Each passenger is associated with
	PassengerID	their seat number.
Member Set_—	Member	Each seat number is associated with
	SetName	one class (e.g., first class, coach,
		etc.). The seat number is stored in
		the Member field of the Member
		table. The class is stored in the
		SetName field of the Set_—
		table.
PassengerStatistics	StatImage	Time spent viewing movies by title:
		Each movie watched and length of
		time spent watching each movie is
		stored here as a Binary Large OBject
		(BLOB) which can hold up to
		2GBytes of data if disk space allows.
PassengerStatistics	StatImage	Time spent listening to entertainment
		audio by title: Each audio
		entertainment listened to and the
		length of time spent listening to
		each audio entertainment is
		additionally stored here (BLOB).
PassengerStatistics	StatImage	Time spent playing games by title:
		Each game played and length of
		time spent playing each game is
		additionally stored in the here
		(BLOB).

[0589] The cabin file server database 493 provides storage of passenger survey information. Passengers 117 at each seat 123 can elect to participate in the survey. The database 493 records each result (i.e., passenger's answer) to each survey taken so that this information can be made available to the airline. Passenger survey information is stored in the following tables: Survey, SurveyAnswer, SurveyAnswerKey, and SurveyQuestion.

[0590] The results of each survey taken (or same survey taken multiple times) by each passenger are stored in the SurveyAnswer table. Survey results may be off-loaded using the Data Offload approach discussed above. The name of the survey is stored in the Survey table. The corresponding questions contained in the survey are stored in the SurveyQuestion table. All possible answers (i.e., six multiple choice answers) for each survey question are stored in the SurveyAnswerKey table.

[0591] The cabin file server database 493 provides storage for application state information. This is useful in cases where there is an interruption of aircraft power while the application is running. Storing this information in the database 493 allows the system to resume operation where it left off. There may be over 100 processes running at any given time. Each process can store as much information as needed in the Data field of the PowerRecovery table in order for the process to know where it should continue once power is resumed. The Data field is defined as a Binary Large OBject (BLOB).

[0592] The state (e.g., start, pause, stop, init) of the IFE system 100 is stored in the IFE_State field of the Aircraft table. Products and/or services ordered by the passenger 117 are stored in the Order_table (as well as at the seat display unit 122a for backup). This enables the IFE system 100 to start from where it left off once passenger entertainment and interactive services are resumed.

[0593] The cabin file server database 493 provides storage for Video Announcement information. This information may include attributes such as video announcement titles, overhead audio, overhead video, and whether in-seat displays 122 are overridden. Video Announcement information is stored in the following tables: VA_Distribution, VideoMedium, VideoSegment, VideoPlayer, and VideoUse.

[0594] Video Announcement information is stored in the VideoMedium table. Examples include boarding announcements, safety announcements, short subject programs, etc. Each Video Announcement has more specific information stored in the VideoSegment table.

[0595] Attributes for each Video Announcement are stored in the VA_Distribution table. Attributes include, but are not limited to: if the announcement is heard on the overhead audio and in which zone (OverheadAudioMap field, where each bit in the field represents a zone), if the announcement is viewed on the overhead video and in which zone (OverheadVideoMap field, where each bit in the field represents a zone), if the announcement (audio and video) overrides whatever is currently being viewed at the seat (InseatOverrideMap field, where each bit in the field represents a zone), or be available for in-seat viewing (default) and in which zone.

[0596] Video Announcements (audio and video) are available for in-seat viewing (default). This means that the passenger 117 has the option to select the video channel on which the video announcement is being played. Video Announcements can also be set to override in-seat viewing. In this case, the IFE system 100 causes the overridden in-seat displays in a specified zone to select the video channel on which the video announcement is being played, and the passenger 117 is unable to turn off the in-seat video display 122.

[0597] Each Video Announcement is assigned to a particular source (i.e., video player) through the VideoUse table. Attributes for each video player are stored in the VideoPlayer table. The default volume level for the PA speakers is stored in the DefaultPA_AudioLevel field of the Aircraft table. The volume level for the PA speakers can be different for each zone. This is stored in the AudioLevel field in the PA_Volume table.

[0598] Overhead monitors 162 can be assigned to a video source (i.e., video player 227) for video announcements. This information is stored in the OverheadAudioMap and Overhead VideoMap fields of the VA_Distribution table.

[0599] The cabin file server database 493 provides storage for global attribute information (i.e., information that can be accessed by any service). Examples may include the current state of the IFE system 100, the base currency, and the default PA audio. IFE system global attribute information is stored in the following tables: Aircraft, Airline, Airport, Country, Flight, and Route.

[0600] The following flight information is pre-loaded and stored in the Route table, one record per known route:

[0601]


	Field	Description

	FlightNumber	flight number assigned to this flight leg
	FlightDuration	estimated flight duration in minutes
	DepartureAirport	departure airport code
	ArrivalAirport	arrival airport code
	RouteType	route type to determine which services are
		available on this route

[0602] When the flight attendant enters a FlightNumber and RouteType at the primary access terminal 225, the corresponding flight information (i.e., FlightDuration, ArrivalAirport, and DepartureAirport) is found in the Route table and presented at the primary access terminal 225 and stored in the current record of the Flight table. The DepartureDate and DepartureTime are determined based on when the weight-off-wheels signal is received. This date and time is then stored in the WeightOffWheelTime field of the Flight table to calculate movie cycle and other sales times.

[0603] The following IFE data is configurable in order to tailor the IFE functionality for a particular airline. This tailoring is done using the IFE Tools software.

[0604] (a) IFE function data configuration ID: Version field of the DB_Version table.

[0605] (b) For each video game: (1) The cost of each video game is specified in the UnitPrice field of the Price table. This cost can be altered based on the PolicyDescription field of the Policy table. A video game can be offered for free in a given zone by setting the associated bit in the FreeMap field of the Price table to 1. (2) The type of video game is stored in the GameType field of the GameDetail table. (3) The activation date is stored in the EffectivityDate field of the GameDetail table.

[0606] (c) For each movie: (1) The cost of each movie is specified in the UnitPrice field of the Price table. This cost can be altered based on the PolicyDescription field of the Policy table. A movie can be offered for free in a given zone by setting the associated bit in the FreeMap field of the Price table to one. (2) The length of each movie is stored in the SegmentRunTime field of the VideoSegment table. (3) The activation date is stored in the EffectivityDate field of the VideoUse table.

[0607] (d) For each aircraft seat class zone: whether video games and movies are pay or free is addressed in items (b) and (c) above.

[0608] (e) For each aircraft seat class zone: which passenger survey is available.

[0609] (f) Logical seat groups (e.g., general service zones, duty free zones) are specified in the Member and Set_tables. Seat numbers are stored in the Member field of the Member table. Zones are stored in the SetType field of the Set_table.

[0610] (g) For each route type: Titles to appear in the video game menu, audio menu, and movie menu of the seat display unit 122a. Titles to appear in the video game menu can be limited according to route type. The titles are stored in the Title field of the GameDetail table. The route type is stored in the RouteType field of the GameDetail table. Titles to appear in the audio menu can be limited according to route type. The titles are stored in the AudioTitle field of the AudioDetail table. The route type is stored in the RouteType field of the AudioDetail table. Titles to appear in the movie menu can be limited according to route type. The titles are stored in the MediaTitle field of the VideoMedium table. The route type is stored in the RouteType field of the VideoUse table.

[0611] (h) Currency exchange rates are stored in the ExchangeRate field of the Exchange table.

[0612] (i) The primary access terminal display currency is stored in the PAT DisplayCurrency field of the Aircraft table.

[0613] (j) For each flight number: Arrival/departure city pairs, flight duration and route type. Each flight number is associated with a specific route. The route is specified by the FlightNumber and Leg fields of the Route table. The arrival/departure city pairs for a given route is respectively stored in the ArrivalAirport and DepartureAirport fields of the Route table. The scheduled flight duration for a given route is stored in the FlightDuration field of the Route table. The calculated flight duration (e.g., based on tail wind, etc.) for a given route is stored in the FlightDuration field of the Flight table. The route type of a given route is stored in the RouteType field of the Route table.

[0614] (k) Movie cycle attributes are specified in the Cabin File Server Executive Extensions Software Design Document.

[0615] (l) Video announcement titles are stored in the MediaTitle field of the VideoMedium table. Video announcement lengths are stored in the SegmentRunTime field of the VideoSegment table.

[0616] (m) The video announcement cabin speaker default volume is stored in the DefaultPA_AudioLevel field in the Aircraft table. This volume cannot be changed during a flight. During database initialization, a record for the PA_Volume table is created for every PA zone (as specified by the LRU table). The AudioLevel field in each record of the PA_Volume table is initialized to the DefaultPA_AudioLevel. The video announcement cabin speaker default volume can then be modified for each PA zone (e.g., passengers in the PA zone over the engine may need a louder default volume). The new volume is stored in the AudioLevel field of the PA_Volume table.

[0617] (n) The video reproducer 227 assigned to a particular video announcement is stored in the PlayerName field of the VideoUse table. The video reproducer 229 assigned to a particular movie is stored in the PlayerName field of the VideoUse table.

[0618] (o) Product pricing data is stored in the UnitPrice field of the Price table. Product effectivity data is stored in the EffectivityDate of the ProductEffectivity table.

[0619] (p) Accepted credit card types (i.e., VISA, DISCOVER, etc.) are stored in the CardName field of the ValidCardData table. Accepted charge limits are stored in the CreditLimit field of the ValidCardData table. This charge limit is defined by the airline.

[0620] (q) The airline name is stored in the AirlineName field of the Airline table.

[0621] (r) The number of movies in a particular package is stored in the MovieQuantity field of the PackageDetail table. The hours of game play is stored in the GameQuantity field of the PackageDetail table. Additional package details (e.g., which games/movies are in the package) are also stored in the PackageDetail table.

[0622] The primary access terminal 225 must perform certain coordinating functions prior to being able to operate with the cabin file server 268 successfully. A System Initializer establishes the cabin file server hard drives as shared devices with the primary access terminal 225, synchronizes its system date and time with the date and time of the cabin file server 268, and turns on the LCD's backlight so the user can see what's going on. The System Initializer, INITSYS.EXE, performs these functions at boot time. This program includes the source file INITSYS.CPP.

[0623] Primary access terminal Stand Alone Utilities are PAT-resident utilities that are needed between runtimes (i.e., between flights). They are used by Service Personnel to manage data and system behavior.

[0624] A Data Offloader is provides so that specific data is offloaded from the aircraft 111 for the purpose of revenue collection and system performance evaluation. At the end of each flight, the NT event logs are archived on the cabin file server hard disk. Passenger Statistics information, passenger survey results, and Transaction records are stored in the cabin file server database 493 for later retrieval.

[0625] This database information is stored for up to forty flight legs. The number of flight legs is stored in the FlightID field of the Flight table. FlightID is simply a counter which is incremented after each flight. The Data Offload approach discussed previously describes the Data Archival, Data Offload and Disk Space Management processes.

[0626] The following paragraphs describe the additional functionality associated with the Data Offload process, in the utility OLUTIL.EXE.

[0627] The flight number for a test flight always begins with a “9”. This enables a custom trigger, FLIGHT_ITRIG.SQL, to purge just test flight data (i.e., flights beginning with a “9”) from the database at the beginning of a subsequent flight. The purge is automatically performed at the beginning of the next flight rather than at the end of the test flight so that the information can remain in the database long enough to offload the data for trouble-shooting purposes but not so long that credit card data may be compromised. However, if the Data Offload process is manually initiated at the end of the test flight, then the test flight data is purged at this time.

[0628] Archived data (i.e., previous flight leg) can be off-loaded on a per-flight basis. All credit card transaction data is encrypted using PKZIP.EXE (an industry-standard third-party file-compression utility). PKZIP was chosen because it provides excellent file compression ratios and allows for password encryption of the compressed data.

[0629] At the start of each flight, the Offload field in the Flight table for the specific flight is initialized to one. Once a particular flight has been off-loaded, the Offload field in the Flight table is set to zero (i.e., flight data is tagged). It is possible to automatically specify the off-load of all non-tagged data (i.e., all flights with Offload field set to one). It is also possible to manually specify the off-load of data for a specific flight.

[0630] An operator is able to disable the Watchdog driver 410. DISWDOG.EXE is used to disable the hardware Watchdog by issuing an IOCTL Disable command to the Watchdog Driver 410.

[0631] Cabin file server Runtime Utilities 425 are programs that are used once per flight, either at the beginning or at the end. As a result, they are part of the application and are maintained along with the cabin file server Executive Extensions.

[0632] SDU_BLDR.EXE, the seat display unit database builder, is used to develop a download file to be downloaded to all seats 117. The download file is comprised of product and entertainment information that is subject to change based on the contents of the cabin file server database 493.

[0633] When flight information is entered by the Flight Attendants at the primary access terminal 225, the SDU_BLDR on the cabin file server 268 is initiated. The GUI 426 calls SDU Builder via the CAPI to extract the information from the cabin file server database 493 that is pertinent to the current flight. This information is used to create the download file (sdu_data.dnl) that is sent to each seat 123 on the aircraft 111.

[0634] The purpose of sdu_data.dnl is to provide current information (i.e., entertainment, pricing, etc.) from the database 493 to the passenger seats 123. The creation of the download file triggers the Seat NAU to notify each seat that a new download file exists. Each seat then requests the file and applies the portion of the download file that is applicable to their programming (i.e., first class seats don't read the information in the download file applicable to coach seats 123).

[0635] CFSLOGS.EXE is the main C++ executable associated with the archival of the event logs. It runs on the cabin file server 268 and is initiated during the data archive process. Cfslogs.exe is responsible for dumping the NT event logs of the cabin file server 268 to the hard disk using a unique archive file name. This file name is passed to cfslogs.exe as an input parameter.

[0636] DUMP_POS.EXE is the main C++ executable associated with offloading Point of Sales data. It runs on the cabin file server 268 and is initiated during the data offload process. Dump_pos.exe is responsible for writing the archived database information for a given flight to the various FLTSALES.CSV files on the hard disk. The flight ID is passed to dump_pos.exe as an input parameter.

[0637] PARCHIVE.EXE is the main C++ executable associated with the purging of archive data. It runs on the cabin file server 268 and is initiated as part of the effort to manage the disk space on the cabin file server 268. Parchive.exe is responsible for deleting both the Archive file and the Offload file from the hard drive. Both of these files are passed to parchive.exe as input parameters.

[0638] DUMPSTAT.EXE is the main C++ executable associated with offloading Passenger Statistic data. It runs on the cabin file server 268 and is initiated during the data offload process. Dumpstat.exe is responsible for writing the archived database information for a given flight to the paxstats.csv files on the hard disk. The flight ID is passed to dumpstat.exe as an input parameter.

Common Software Libraries

[0639] The following common software libraries of functions and utilities are used throughout the primary access terminal and cabin file server applications.

[0640] The Database Utilities, DBUTILS.CPP are commonly used by all database applications.

[0641] They use the SQL commands (recognizable as starting with db . . . ( ), such as dbexit( ), dbresults( ), etc.):

[0642]


Function	Purpose

CheckResults( )	Continuously loops calling dbresults( ) to get
	the results of the prior SQL call for this process
	until they have all been obtained. If there are
	errors, it displays function text for tracing.
UpdateStats( )	Updates the statistics of the given table for the
	given process.
FailureExit( )	Standard exit function, displays the error before
	calling dbexit( ).
TransactionLogControl( )
SelectIntoControl( )

[0643] The event logging functions, EVENTLOG.CPP, RETRYSYS.CPP, are used exclusively in SYSMON.EXE and POWERDWN.EXE. They each call EventLog's ProblemReport( ) subroutine (which is recursive!) which calls EventLog::WriteHAILog( ) which eventually uses NT's ReportEvent( ) to record the information.

[0644] The set SQL Error and Message Handlers, HANDLERS.CPP includes two routines used by functions such as ARCHIVE.CPP CREATEDB.CPP DUMP_POS.CPP, INITDB.CPP and SUD_BLDR.CPP to handle SQL informational and error messages: err_handler( ) and msg_handler( ). These functions are identified to the SQL code using dberrhandle(err_handler) and dbmsghandle(msg_handler) respectively.

[0645]


Function	Purpose

int err_handler(	Builds a DB-LIBRARY error message
input DBPROCESS *dbproc,	containing both a database error (dberr and
input int severity,	dberrstr) and an operating system error
input int dberr,	(oserr and oserrstr), echoes it to stdout
input int oserr,	and (if oserr is not DBNOERR) uses
input char *dberrstr,	UtilityClass::LogEvent( ) to put this info
input char *oserrstr)	into the event log. See
	UtilityClass::LogEvent( ) for severity
	definition.
	Returns INT_EXIT if the database
	process pointer dbproc is no good.
	Otherwise, INT_CANCEL.
int msg_handler(	If the severity is greater than zero, it logs
input DBPROCESS *dbproc	it to the event log, otherwise it simply
input DBINT msgno,	builds and displays the message. It always
input int msgstate	returns ZERO.
input int severity,
input char *msgtext)

[0646] Queues include QUEUE.CPP and QPAIR.CPP. A Queue is a dynamic list of pointers to elements of any type which must wait for sequential processing such as an output queue. The actual elements are not stored in the Queue. A QPair is a set of two Queues used for related purposes, for example one for Input and one for Output associated with a named pipe pair or a serial port.

[0647] This class is used to create and maintain all Queues in the Control Center software to buffer message traffic. The first or top or head position of the queue is identified as element number zero (0).

[0648] Queues made with this class are considered to be “thread safe”. That is, multiple threads can access these queues concurrently. These queues generate a signal when data is written to them. One can choose whether the queue should signal with only an event handle or with a semaphore as well. This class allows one to create and control the size of (or number of elements in) your queue, move elements in and out of the queue, and allow multiple users or readers to manipulate a single queue.

[0649] The following member functions are used to create and control the size of (or number of elements in) the queues.

[0650]


Queue class Function	Purpose

The Constructors:	Initialize the queue. If no Size (or if Size = 0) is
Queue( ),	given, then the Queue is not delimited and can
Queue (ULONG Size)	grow to the capacity of the system (defined by
	constant LONG_MAX). If Size is given, the
	queue is limited to contain no more than Size
	elements by having all Put functions display
	“Queue Overflow” to stdout and returning TRUE
	when an attempt is made to exceed the limit.
short	Returns the number of elements currently in the
GetCount( )	queue.
ULONG	Returns the preset maximum size of the queue. If
GetSize( )	the value returned is zero, the size is not
	delimited.
bool	Allows one to increase the maximum size of the
SetSize	queue. Returns FALSE if Queue was already
(ULONG Size)	defined as undelimited or if the new size is less
	than the previous size.

[0651] The Selective Style member functions are used when the priority of the queue elements is controlled.

[0652]


Queue class
Function	Purpose

void *	Removes and returns the Nth element from the
GetNth(	queue. Returns NULL if the Nth element does not
long N)	exist. If the queue is already locked, it waits for
	permission to access the queue. Therefore, it is
	important to lock( ) the queue prior to determining the
	Nth element (with PeekNth( ), for example) and then
	retrieving it with GetNth( ).
void *	Returns the contents of the Nth element of the list
PeekNth(	but doesn't remove it from the queue. If none,
long N)	returns NULL.
bool	Inserts the Element's pointer into the queue at
PutNth(	position N. If N + 1 is greater than the current number
void *Element,	of elements on the queue, then the Element's pointer
long N)	is placed at the end of the queue instead of at N.
	Returns FALSE if.

[0653] The FIFO Style member functions are used when a First-In-First-Out FIFO style queue is desired.

[0654]


Queue class
Function	Purpose

void *	Returns the element at the top of the list. If none,
Get( )	returns NULL. Same as GetNth(0).
void *	Returns the contents of the element at the top of the
Peek( )	list, but doesn't remove it from the queue. If none,
	returns NULL. Same as PeekNth(0).
bool	Places the Element's pointer at the end of the queue.
Put(	Same as PutNth(Element, −1). Returns FALSE if
void *Element)
bool	Places Element's pointer at the head or top of the
PutHead(	queue. Same as PutNth(Element, 0). Returns FALSE if
void *Element)

[0655] Allow multiple users or readers to manipulate a single queue.

[0656]


Queue class Function	Purpose

Constructor:	Set useSemaphore = TRUE if the queue is
Queue (	going to be referenced by more than
ULONG Size,	one ‘reader’ or thread.
bool useSemaphore =	Otherwise, set it to FALSE or don't supply it.
TRUE)	When set to TRUE, the constructor calls
	CreateSemaphore to establish the semaphore
	handle, and assigns a Resource Count equal to
	the Size, which means that if you specify a
	queue of 10, at most 10 threads can access it
	at once.
const HANDLE	Returns the signal handle for use primarily with
getEventHandle( )	WaitForSingleObject( ) to halt a thread until
	something is placed in the queue.
const HANDLE	Returns the semaphore handle for use primarily
getSemaphoreHandle( )	with WaitForSingleObject( ) to halt a thread
	until something is placed in the queue.
	Use only when useSemaphore is TRUE in
	constructor.
void	Locks the queue so other ‘readers’ can't alter
Lock( )	its contents. If the queue is already locked
	(in use), this call waits until it is no longer
	locked. The Queue member functions each
	perform a lock and unlock when they update
	the queue, but there are times when you need
	to perform several queue functions while
	keeping total control of the queue. In this
	case, use the Lock( ) function.
void	Releases control of the queue so others can add
Unlock( )	or remove elements. Use only if you previously
	used Lock( ) to isolate queue access.

[0657] The short class Queue Pairs maintains a set of two queues that are related. Typically one is used for Input and one is used for Output. Their names, however, are Lefty and Righty.

[0658]


Queue class Function	Purpose

The Constructors:	These constructors simply construct the two
Qpair(	Queues, Lefty and Righty.
ULONG Size,
bool bUseSemaphore),
Qpair(
ULONG Size)
Queue& Left( )	Returns a pointer to Queue Lefty.
Queue& Right( )	Returns a pointer to Queue Righty.

[0659] The RpcClientClass, RPCCLNTC.CPP contains all of the functionality needed for an application to communicate with the Fileserver RPC Server via the Cabin Application Programming Interface (CAPI). To use it, the Create( ) call should be executed. Then a call to GetContextHandle( ) provides the I/O handle for communications.

[0660]


RpcClientClass class Function	Purpose

bool	Creates and initializes an RPC
Create( )	Interface channel between an
	application and the RPC
	Server process using
	RpcNsBindingImportBegin( ).
	Returns TRUE if successful,
	FALSE otherwise.
bool	Terminates the RPC Session
Delete( )	with the server process.
	Returns TRUE if successful,
	FALSE otherwise.
bool	Retrieves a database context
GetContextHandle(	handle from the server process
output PPCONTEXT_HANDLE_TYPE	via an RPC channel
pphContext)	previously opened using
	Create( ). Calls the Capi_c.c
	InitializeInterface( )
	function to connect to RPC.
	Returns FALSE if none.
bool	Returns a database context
ReleaseContextHandle(	handle which was previously
output PCONTEXT_HANDLE_TYPE	obtained by a call to
phContext)	GetContextHandle( ).
	Returns FALSE if none.

[0661] The System Monitor Interface, SYSMNNTR.CPP is a set of routines that is used by any process that is under the control of SYSMON.EXE for shutdown purposes. This Constructors class has three constructors available for use: SysmonInterfaceClass( ) is not used, SysmonInterfaceClass(ParentProcess_id, EventHandle), SysmonInterfaceClass(ParentProcess_id, MessageQueue) SysmonInterfaceClass(ParentProcess_id).

[0662] ParentProcess_id is used to identify the process in all communications with SysMon (see WriteToSysMon( )). The other parameters are used to control the method of shutdown for the given process. If the process prefers to hear about it using an event, it can pass the EventHandle to be used when shutdown is needed. If the process prefers to hear about it via a message queue, it can pass the Queue ID in.

[0663] Each Initialization process must first create a SysmonInterfaceClass object and then register communications with Sysmon using SysmonInterfaceClass::Register( ). This calls ConnectSystemMonitor( ) to create handles to two Named Pipes (input and output) to use to talk to the System Monitor. It then creates an IFE_Message and sends it to Sysmon via WriteToSysMon( ). Finally, Register( ) launches two threads to manage the named pipes with CreateSystemMonitorThreads( ).

[0664] CreateSystemMonitorThreads( ) launches two communication threads who in turn call the actual I/O function: InputThreadInterface( ) calls ReadFromSysMon( ), OutputThreadInterface( ) calls HeartBeatSysMon( ). ReadFromSysMon( ) continuously reads from Sysmon, calling ProcessRequest( ) when any message is received.

[0665] HeartBeatSysMon( ) continuously issues a pulse message to Sysmon, to let it know that this process is alive.

[0666] WriteToSysMon( ) is used to send any message to the System Monitor via the output named pipe. It uses IFE_Message::PutData( ) to do it.

[0667] Anytime a message is received in ReadFromSysMon( ), ProcessRequest( ) is called. This simply parses out any ProcessStop message and calls Shutdown( ) to continue. All other messages are ignored.

[0668] Shutdown( ) cares about how this class was constructed. If an event handle was given, it sets this event to announce the shutdown to the host process. If a message queue was given, it forwards the ProcessStop message to the queue so the host can shutdown in a more orderly fashion. If neither of these was given, it halts the process with a ProcessExit( ).

[0669] A Timer Utilities file, TMDCLLBC.CPP, contains a class timedCallback that is used to schedule activity in regular intervals. The user first creates a function to be called when a ‘timeout’ occurs by declaring it as long (*timedCallbackFun) (timedCallback *Entry); This function must return the number of ticks to wait until the next call should be invoked, or Zero to stop the re-queueing.

[0670]


Public timedCallback Functions	Purpose

timedCallback( )	Constructs a callback using a default
	‘do-nothing’ function. This allows
	one to create arrays of timedCallback
	objects and define the callback
	function later by use of member
	setFun( ).
timedCallback(	Constructs a real-time clock callback
input timedCallbackFun SomeFun)	to be used for later calls to queue( )
	and cancel( ). SomeFun is the user-
	defined function to call when a
	timeout occurs.
˜timedCallback( )	Cancels the callback before it goes
	out of scope.
void	Cancels ‘this’ callback if it is queued,
cancel( )	but retains the object for subsequent
	queueing.
int	Returns 1 if ‘this’ callback is queued,
isQueued( )	0 otherwise.
void	Queues the callback to be called after
queue(input long Delta)	the specified number of invocations
	of tick( ). Delta == 0 cancels the
	callback. Queue( ) is automatically
	called each time the user's
	timedCallbackFunction is invoked.
	queue( ) can be used to change the
	interval of an already queued
	callback.
void	Redefines the callback function to be
setFun(input timedCallbackFun	used for ‘this’ callback as what's
SomeFun)	contained in SomeFun.
static void	Advances the time by one tick. As a
tick( )	result, queued callbacks may time-out
	and are then invoked from within
	tick( ). Normally not used externally,
	this is maintained by the timer thread
	that was launched by the constructor.

[0671] The General Utilities include UTLTYCLS.CPP. The UtilityClass Class provides a general interface to the following generic utility functions. Many of these functions are declared as STATIC, which means that you can use them without creating an object of UtilityClass, just by calling them with the class name in front, such as UtilityClass::bin2Ascii(0x2f, &Hi, &Lo).

[0672]


UtilityClass Public Function	Purpose

static void	Converts a binary hex value into a two
bin2Ascii	byte ASCII character representation.
(input unsigned char Hex,	e.g., Hex = 0x2F, Hi = ‘2’ Lo = ‘F’.
output unsigned char*Hi,
output unsigned char*Lo)
unsigned char	Receives a character buffer of input
BuildNetworkAddress	data and creates a network address,
(input unsigned char *cpBuffer,	returning it as an unsigned character.
output unsigned char	DeviceHandler defines whether the data
*cpNetworkAddress,	is from ARCNET or RS-422.
input DeviceHandlerType DeviceHandler)	The length of the address is returned.
	If ZERO, no address was made.
bool	Connects the WINDOWS NT Network
ConnectNetworkResource	Resource specified by RemoteName to
(input char *LocalName,	the drive specified by LocalName.
input char *RemoteName)	Returns FALSE if any errors are
	encountered and connect fails.
static unsigned short	Takes 2 ASCII characters and returns
ConvertAsciiToBin	them as unsigned binary.
(input unsigned char*byAscii)	e.g., by ASCII = “2F”, returns 0x2F.
static unsigned char	Takes a single ASCII char and returns a
ConvertAsciiToBin	single unsigned binary char.
(unsigned char AsciiChar)	e.g., AsciiChar = ‘F’, returns 0x0F.
static bool	Initializes the IfeIdMap data structure.
CreateIfeIdConversionMap( )	For each entry in the IfeId Type
	definition, a corresponding text string is
	written to the map. This data structure
	is used in conversions between process
	enumeration values and text values.
	Always returns TRUE.
static bool	Initializes the IfeFuncMap data
CreateIfeFuncConversionMap( )	structure. For each entry in the
	IfeFunction Type definition, a
	corresponding text string is written to
	the map. This data structure is used in
	conversions between process
	enumeration values and text values.
	Always returns TRUE.
bool	Retrieves the name and data associated
GetFirstRegistryValue	with the first value contained in the NT
(input char *pszKeyName,	Registry that matches the registry
output char *pszValueName,	keyname.
input LPDWORD dwValueNameLen,	Returns FALSE if unsuccessful.
output LPDWORD lpdwType,
output LPBYTE lpbData,
output LPDWORD lpcbData)
bool	After calling GetFirstRegistryValue( ),
GetNextRegistryValue	this function can be called to retrieve
(output char *pszValueName,	subsequent registry value names and
output LPDWORD dwValueNameLen,	data.
output LPDWORD lpdwType,	Returns FALSE if unsuccessful.
output LPBYTE lpbData,
output LPDWORD lpcbData)
bool	Retrieves a DWORD value from the
GetRegistryDWord	Registry into lpdwValue.
(input char *lpszKeyName,	Returns FALSE if unsuccessful.
input char *lpszValueName,
output DWORD *lpdwValue)
bool	Retrieves all registry information by
GetRegistryInfo	iterating through the registry key
(output CStringArray *RegValueArray)	values, returning it in an array of
	strings.
	Returns FALSE if unsuccessful.
bool	Retrieves a string in lpbData
GetRegistryString	corresponding to the input parameter
(input char *lpszValueName,	ValueName.
output LPBYTE lpbData,	Returns FALSE if unsuccessful.
output LPDWORD lpcbData)
static bool	Converts the IFE Function Message
IfeFuncToText	identifier contained in the nIfeFunction
(input IfeFunctionType nIfeFunction,	input argument into a text string
output PGENERIC_TEXT pszIfeFuncText)	representing the same enumeration
	name.
	Returns FALSE if unsuccessful.
static bool	Converts the IFE Process/Thread
IfeIdToText	identifier contained in the nIfeId input
(input IfeIdType nIfeId,	argument into a text string representing
output PGENERIC_TEXT pszIfeIdText)	the same enumeration name.
	Returns FALSE if unsuccessful.
static IfeFunctionType	Returns the corresponding
IfeTextToFunc	Enumeration value for the Text String
(input PGENERIC_TEXT pszIfeFuncText)	contained in pszIfeIdText from the
	IfeFunctionType Type definition.
	If none, returns NoDestination.
static IfeIdType	Returns the corresponding
IfeTextToId	Enumeration value for the Text String
(input PGENERIC_TEXT pszIfeIdText)	contained in pszIfeIdText from the
	IfeIdType Type definition.
	If none, returns NoDestination.
static void	This is the call-level interface to the
LogEvent	WINDOWS NT event log. This takes the
(input IfeIdType nProcessId,	passed variables and develops a series
input WORD wCategory,	of strings using printf(pszFormat, arg,
input DWORD dwErrorCode,	arg, arg) style, then forwards the
input char *pszFormat, input . . . )	developed string to ReportEvent( ).
bool	This function is used by a process to
SetRegistryConfigValue	register its Unit Id, Part Number, and
(input char *ModuleName,	Revision number to the WINDOWS NT
input REGCONFIGINFO *ConfigInfo)	Registry.
	Returns FALSE if any errors are
	encountered.
bool	Writes specified value and string data
SetRegistryString	into specified registry key under
(input char *lpszKeyName,	HKEY_LOCAL_MACHINE.
input char *lpszValueName,	Returns FALSE if any errors are
input char *szString)	encountered.

[0673] The Discrete Library, DISCRETE.LIB, contains the UTILITY.LIB Library plus the following. The WinRUtilClass class contains simple utilities for use with WinRT drivers:

[0674]


WinRTUtilClass Functions	Purpose

void	Returns the full WinRT
BuildWinRTDeviceName	device name from a null-
(output LPSTR szDeviceName,	terminated device
input LPSTR szDeviceNumber	number.
DWORD	Uses null-terminated
GetWinRTDeviceNumber	DriverName to look-up
(input LPSTR szDriverName,	WinRT device number
output PUCHAR szDeviceNumber,	string in the registry.
input LPDWORD lpdwDeviceNumberBufSize)	Returns the value
	returned by its called
	RegQueryValueEx( )
	function.

[0675] DSCRTDRV.RT replaces DSCRTDRV.CPP and is the name of the Discrete Driver code. It is fed into the WinRT Preprocessor to create DISCRETE.CPP, which is compiled into the DISCRETE.LIB library. The DiscreteDriverClass controls the system discretes, which are used to control peripherals such as LED indicators.

[0676]


DiscreteDriverClass Public
Function	Purpose

void	Closes the Discrete WinRT device if it
CloseDiscretes( )	is open.
UCHAR	Returns the Enumerated LRU ID. If 0,
GetId( )	LRU ID has not yet been obtained.
	May be called after ReadId( ).
bool	Returns the state of the LCD backlight
GetLCDbacklight( )	(on or off).
bool	Returns the state of the specified LED.
GetLED
(LED_TYPE LEDchoice)
bool	Returns the state of the specified VTR
GetVTRDiscrete	discrete.
(VTR_DISCRETE_TYPE
VTRdiscreteChoice)
bool	May be called after ReadId( ).
IsPAT( )	Returns TRUE if this LRU is a PAT,
	FALSE if this LRU is a CFS.
DWORD	Opens the Discrete WinRT device.
OpenDiscretes( )
DWORD	Reads discrete input I/O port to obtain
ReadId( )	this LRU id and stores it in the form:
	0110fijk where f = 1 if CFS, f = 0 if
	PAT; ijk is the LRU id 000-111 (0-7).
	In this form the byte may be used as an
	ARCNET address.
	If successful, ERROR_SUCCESS
	is returned.
UCHAR	Returns a byte representing the state of
ReadInputDiscretes( )	the input discretes.
UCHAR	Returns a byte representing the state of
ReadOutputDiscretes( )	the output discretes.
bool	Turns the LCD backlight on or off.
SetLCDbacklight	Returns the state of the backlight prior
(bool bOnOff)	to this function call.
bool	Turns the specified LED on or off.
SetLED	Returns the state of the LED prior to
(LED_TYPE LEDchoice,	this function call.
bool bOnOff)
bool	Asserts or de-asserts the specified VTR
SetVTRDiscrete	discrete. Returns the state of the discrete
(VTR_DISCRETE_TYPE	before this function call.
VTRdiscreteChoice,
bool bOnOff)
UCHAR WriteOutputDiscretes	Sets the output discretes according to
(UCHAR ucOutputMask)	the specified mask. Returns the state
	of the output discretes before they
	were changed by this function.

[0677] A message library MESSAGE.LIB provides the means of moving data from one place and format to another without needing detailed understanding of the protocols involved. In general, all messages transmitted within the control center are of the type IFE_Message. Therefore, a class called IFE_Message is used to translate information into and out of this message type. Similarly, many messages enter the control center from the ARCNET devices, so to support them the ARCNET_Message Class is made. Instead of requiring the user to start with an ARCNET_Message and convert it to an IFE_Message, the ARCNET_Message is a superset of IFE_Message. In this way, the ARCNET_Message contains the additional functions to manage the translations, and the migration from one form to another is nearly transparent.

[0678] For example, when raw data is read into MP.EXE from ARCNET, it is put into a new ARCNET_Message object and passed to MessageToPipeProcessor( ) that treats this message as an IFE_Message to send it to the appropriate NAU. The NAU uses its own flavor of IFE_Message (Seat_Message, for example) to read the data (via its own NAUGetMP( )) and from that point forward, the IFE_message is treated more specifically. No special handling is needed to affect this change. By the time the message finally reaches its ultimate destination process, the message class functions are used to deal with the actual bytes of the messages. These functions are described below.

[0679] The IFE_Message class IFMSSAGE.CPP is the base class for all IFE message processing. A hierarchy exists such that each derived class implements specifics for its data processing. This makes translating data formats transparent to application programmers.

[0680]


IFE_Message Public Function	Purpose

IFE_Message	This constructor prefills the local
(IFE_MESSAGE_DATA	IfeMessageData with the raw
*pIfeMessageData)	pIfeMessageData.
virtual void	Returns the Address data,
GetAddress	(e.g., “SDU 001A”), from the Address
(char *pAddress)	member found in the IfeMessageData.
bool	Initializes the IfeMesageData structure
GetData	of an IFE_Message object with data
(Queue *pInputQueue)	from the Queue. The address of an
	IfeMessageData structure is read from
	the specified queue, the data is copied
	into the IFE_Message class. The
	IfeMessageData structure read from the
	input queue is then Deleted.
	Returns FALSE if fails to get data.
bool	Does a ReadFile( ) on the specified
GetData	handle and uses the data read to
(HANDLE hInPipe,	populate the IfeMessageData structure
ULONG *pBytesRead)	contained in this instance of the
	IFE_Message class.
	Returns FALSE if fails to get data from
	Pipe.
virtual IfeIdType	Returns the Destination data found in
GetDestination( )	the IfeMessageData data member.
IfeFunctionType	Returns the IfeFunction element of the
GetIfeFunction( )	IFE_MESSAGE_DATA structure
	associated with this IFE_Message.
void	Returns the LRU information from the
GetLruInfo	IFE_Message.
(char *pLruInfo)
bool	Copies the data contained in the
GetLruType	LRUType field of the IfeMessageData
(char *pszLruType)	structure contained in this
	IFE_Message into the location
	specified by the input argument
	pszLruType.
	Returns FALSE if pszLruType is a null
	pointer.
void	Copies the data field of this
GetMessageData	IFE_Message object into the pData
(BYTE *pData,	argument. The number of bytes copied
WORD *wDataLen)	is written to the wDataLen argument.
virtual long	Returns the MessageLength data
GetMessageLength( )	member value.
CString	Retrieves the network address from the
GetNetworkAddress( )	raw data buffer of an IFE Message.
	GetNetworkAddress determines the
	location of address information in
	the Raw Data buffer based on the
	destination ID. Address information
	is converted from Binary to ASCII if
	necessary then placed into a CString
	which is returned to the calling
	function.
virtual IfeIdType	Returns the Source data found in the
GetSource( )	IfeMessageData data member.
UnsolicitedMessageType	Returns the value contained in the
GetUnsolicitedMessage( )	UnsolicitedMessage field of this
	IFE_Message object.
void	Formats a text string containing
Log(int nMessageDirection,	pertinent message information and
IfeIdType nProcessId,	writes it to standard output.
char *pszDataFormat)	MessageDirection can be set to
	LogInpMsg or any other value to
	indicate whether the log should
	say ‘Received’ or ‘Transmitted’,
	respectively. ProcessId is simply
	added to the Log string along with
	the IFE_Message data. The
	DataFormat is used to determine
	which fields are used. If null,
	only the Process Id, Function,
	Destination Id, Source Id and
	Address are output to stdout.
	Otherwise the actual message
	data also prints.
bool	Allocates sufficient memory to hold a
PutData	copy of the IfeMessageData structure
(Queue *pOutputQueue)	associated with a message. The
	IfeMessageData is copied from the
	Class data area to the newly allocated
	memory. The pointer to the copied data
	is then placed on the specified queue.
	Returns FALSE if fails to create a new
	IFE_Message object.
bool	Copies the contents of the
PutData	IfeMessageData class variable to the
(HANDLE hOutPipe,	pipe specified by hOutPipe. The
ULONG *pBytesWritten)	number of bytes actually written to
	the pipe are returned in the
	pBytesWritten argument.
	Returns FALSE if fails to output
	to the pipe.
virtual void	Updates the IfeMessageData Address
SetAddress	data field with pAddress info.
(char *pAddress)
virtual void	Updates the Destination field in the
SetDestination	IfeMessageData data member.
(IfeIdType DestinationId)
void	Copies the IfeFunctionType input
SetIfeFunction	argument into the IfeFunction element
(IfeFunctionType nIfeFunction)	of the IFE_MESSAGE_DATA
	structure associated with this
	IFE_Message.
void	Saves information about the host LRU.
SetLruInfo
(char *pLruInfo)
bool	Fills the LRUType field in the
SetLruType	IfeMessageData structure for this
(char *pszLruType)	IFE_Message with the data contained
	in the input argument pszLruType.
	Returns FALSE if input LruType
	is too big to store.
void	Copies the specified data block to the
SetMessageData	MessageData field of this
(BYTE *pData,	IFE_Message object.
WORD wDataLen)
void	Sets the MessageLength local data
SetMessageLength	member to Length.
(long Length)
void	Converts the Network Address in
SetNetworkAddress	csNetworkAddress as necessary and
(CString csNetworkAddress)	writes the resulting data to the Raw
	Message Data buffer. The type of
	conversion required as well as the
	location of data in the Raw Message
	data buffer is determined by the
	identifier of the process that sent
	the message (i.e., Message Source Id).
virtual void	Updates the Source field found in the
SetSource	IfeMessageData data member with
(IfeIdType SourceId)	SourceId.
void	Sets the UnsolicitedMessage field for
SetUnsolicitedMessage	this IFE_Message object with the
(UnsolicitedMessageType	value contained in Message.
Message)

[0681] The ARCNET_Message class ARCNTMSS.CPP is a derived class from IFE_Message. It is used to carry and process ARCNET data from the Message Processor to an appropriate Network Addressable Unit (e.g., Seat NAU, Backbone NAU). It is used as a base class to any ARCNET devices, such as the Seat_Message, PESCA_Message, and PESCV_Message classes.

[0682] Some of the virtual functions defined in IFE_Message have been overridden within ARCNET_Message.

[0683]


ARCNET_Message Class Public
Functions	Purpose

ARCNET_Message(	This constructor fills the
IFE_MESSAGE_DATA	IfeMessageData data member
*pIfeMessageData)	with the message data structure.
ARCNET_Message(	This constructor takes what must
BYTE *pMessageData,	be a valid message and parses
CMapStringToPtr& LookUpTable)	it to fill the local structure.
bool	This method builds the
BuildArcnetMessage(	MessageData into an ARCNET
CMapStringToPtr& LookUpTable,	message. The first two bytes
char *pLRUName,	of the output message buffer
BYTE *pOutBuf)	are set to the length of the
	message (as read from the
	MessageLength field of the
	IfeMessageData structure. The
	remainder of the output buffer is
	populated with the raw
	ARCNET data from the
	MessageData field of the
	IfeMessageData structure.
	Returns FALSE if failure.
BYTE	Returns the value of the
GetCommand( )	Command Byte in the
	ARCNET MessageData.
IfeIdType	Extracts the Destination bytes
GetDestination(	from the ARCNET
CMapStringToPtr LookUpTable,	MessageData, attempts to
char *pAddress)	map the raw data and returns
	the Enumerated IfeIdType
	and Mapping address.
	Returns NoDestination
	if none found.
IfeFunctionType	Returns the IfeFunction
GetIfeFunction( )	data member.
long	Processes the raw
GetMessageLength(	ARCNET data to determine
BYTE *pMessageData)	the message length, update
	the local data member
	and return the value.
bool	Determines whether or not this
IsTestPrimitive(	IFE_Message is a test
BYTE byTestPrimitive)	primitive by comparing the
	command byte with the constant
	TP_COMMAND. A value of
	TRUE is returned if the
	command byte equals
	TP_COMMAND.
	A value of FALSE is returned
	otherwise.
bool	Overloaded ARCNET PutData( )
PutData(	method. Completes the Message
HANDLE hOutPipe,	Header and calls the
ULONG *pBytesWritten)	IFE_Message function.
	Returns FALSE if write to
	OutPipe fails.
bool	Overloaded ARCNET PutData( )
PutData(	method. Completes the Message
Queue *pOutputQueue)	Header and calls the
	IFE_Message function.
	Returns FALSe if no data was
	found to put into Queue.
bool	This method is an override of
SetAddress(	the IfeMessage SetAddress( ).
CMapStringToPtr LookUpTable,	It takes in a mapping table
char *pAddress)	and an Address. The address is
	looked-up in the mapping table
	and if a match is found the
	Address data member is
	updated.
	Returns FALSE if unsuccessful.
void	This method takes a Command
SetCommand(	Byte and update the
BYTE Command)	MessageData member.
void	Simply calls the same
SetDestination(	IFE_Message function to
IfeIdType DestinationId)	set the Destination data member.
void	Parses the
SetDestination(	DestinationNetworkAddress
BYTE *pDestinationNetworkAddress)	for the IFE_Message
	Destination.
bool	Looks up the pAddress in the
SetDestination(	specified LookUpTable to
CMapStringToPtr& LookUpTable,	determine the corresponding
char *pAddress)	Destination and stores it
	in the IFE_Message
	Destination member.
	Returns FALSE if lookup fails.
void	Updates the IFE Function with
SetIfeFunction(	the given value.
IfeFunctionType Function)
bool	Cross-references the Address,
SetSource(	(e.g., ‘SDU 01A’) in the
CMapStringToPtr LookUpTable,	LookUpTable. If a match,
char *pAddress)	updates the Source bytes of
	MessageData with
	corresponding value.
	Returns FALSE if failure.
void	This method takes the BYTE
SetSource(	parameter and update the
BYTE *pSourceNetworkAddress)	MessageData data member
	for source.

[0684] The following are virtual functions that may be used in classes derived from this class:

[0685]


ARCNET_Message Class
Virtual Functions	Purpose

virtual void	To finish up the message for shipment. Base
CompleteMessageHeader( )	version simply calls SetMessageLength( ).
virtual void	Base version simply calls the IFE_Message
GetAddress(	version.
char *pAddress)
virtual IfeIdType	Base version simply calls the IFE_Message
GetDestination( )	version.
virtual IfeIdType	Base version simply calls the IFE_Message
GetSource( )	version.
virtual void	Base version simply calls the IFE_Message
SetAddress(	version.
char *pAddress)
virtual void	Base version simply calls the IFE_Message
SetDestination(	version.
IfeIdType DestinationId)
virtual void	Handles ARCNET messages that do not have
SetMessageLength( )	sub-functions (i.e., 1F messages). Base
	version does nothing.
virtual void	Base version simply calls the IFE_Message
SetSource(	version.
IfeIdType SourceId)

[0686] ARCNET Simulation class ARCSMCLS.CPP contains similar functions to the runtime ARCNET_Message class, except that instead of communicating with the actual ARCNET Driver, this simulates data I/O for test purposes.

[0687] PESC-A_Message class PSCMSSGE.CPP is derived from the ARCNET_Message class to implement the functions needed to support the PESC-A devices.

[0688]


PESC-A_Message Function	Purpose

bool	Returns indication of whether landing gear
IsGearDown( )	is down and locked.
bool	Returns indication as to whether landing
IsGearCompressed( )	gear is compressed (weight on wheels).

[0689] PESCV_Message class PSCVMSSG.CPP is derived from the ARCNET_Message class to implement the functions necessary to format and transmit interface messages between the Cabin Control Center and the PESC-V 224b.

[0690]


PESC-V_Message Function	Purpose

void	Initializes the data portion of this
WriteVideoControlData	PESCV_Message with all information
(BYTE *byData)	necessary for a Video Control Message
	(0xE9). byData must contain the Video
	Control Data bytes.

[0691] The Seat_Message class SETMSSGE.CPP is derived from the ARCNET_Message class to process Seat data between the Seat NAU and the Services. Methods and data relating to all seat sessioning and sales services, along with some cabin services, are provided.

[0692]


Seat_Message Function	Purpose

void	Finishes up the message for shipment,
CompleteMessageHeader( )	adds message length, et. al.
BYTE	Retrieves the Application ID from the
GetApplicationId( )	IFE_Message data.
double	Retrieves the Cash Total from the
GetCashTotal( )	IFE_Message data.
BYTE	Returns the Command ID found in the
GetCommandId( )	IFE_Message data.
BYTE	Returns the Control Identifier found in
GetControlIdentifier( )	the IFE_Message data.
void	Retrieves the Credit Card Data from the
GetCreditCardAccountNumber	IFE_Message data.
(BYTE *pCreditCardAccount)
void	Retrieves the Credit Card Customer
GetCreditCardCustomerName	Name from the IFE_Message data.
(char *pCustomerName)
void	Retrieves the Credit Card Expiration
GetCreditCardExpirationDate	Date from the IFE_Message data.
(BYTE *pExpirationData)
double	Retrieves the Credit Total from
GetCreditTotal( )	IFE_Message data and returns
	it as a floating point value.
short	Retrieves the Flags from the
GetFlags( )	IFE_Message data.
void	Retrieves the Flight Attendant Id
GetFlightAttendantId	from the IFE_Message data.
(char *pAttendantId)
BYTE	Returns the Message ID found in the
GetMessageId( )	IFE_Message data.
ID	Returns the Order ID from the
GetOrderId( )	IFE_Message data.
void	Returns the Product Code from the
GetProductCode	IFE_Message data.
(char *pProductCode)
long	Returns the Product Map from the
GetProductMap( )	IFE_Message data.
BYTE	Returns the Quantity from the
GetQuantity( )	IFE_Message data.
BYTE	Returns the Retry Count from the
GetRetryCount( )	IFE_Message data.
void	Returns the Seat from the
GetSeat(	IFE_Message data.
char *pSeat)
void	Transfers the seat identifiers from the
GetSeatTransferData	data area of this IFE_Message object
(CString &csSeat1,	into the two output arguments.
CString &csSeat2)
WORD	Returns the value of the Sequence
GetSequenceNumber( )	Number data member.
BYTE	Retrieves the session status from the
GetSessionStatus( )	message
BYTE	Retrieves the Transaction Status from
GetTransactionStatus( )	the IFE message.
BYTE	Retrieves the Update Type from the IFE
GetUpdateType( )	message.
void	Initializes the LengthMap array with
InitializeSeat( )	seat Ids once per flight.
void	Copies the Address info into the
SetAddress(	IFE_Message data member.
char *pAddress)
void	Copies the Amount into the
SetCashTotal	IFE_Message data.
(double Amount)
void	Copies the ID info into the
SetControlIdentifier	IFE_Message data.
(BYTE ID)
void	Writes the value contained in byFlags
SetCPMSFlags	to the Flags location in the CPMS
(BYTE byFlags)	Status message.
void	Copies the CreditCardAccount data
SetCreditCardAccountNumber	into the IFE_Message data.
(BYTE *pCreditCardAccount)
void	Copies the CustomerName data into the
SetCreditCardCustomerName	IFE_Message data.
(char *pCustomerName)
void	Copies the ExpirationDate data into the
SetCreditCardExpirationDate	IFE_Message data.
(BYTE *pExpirationDate)
void	Formats as a dollar amount and copies
SetCreditTotal	Amount into the IFE_Message data.
(double Amount)
void	Writes the value in wBuildId to the
SetDBBuildId(	Database Build ID field position in the
WORD wBuildId)	IFE_Message data.
void	Formats elapsed time 0-999 into
SetElapsedTime	IFE_Message data. Values greater
(TIME tmElapsed)	than 999 are reduced to 999.
void	Copies the High Speed Download
SetHSDLQueueStatus	Queue Status into the IFE_Message
(BYTE *pHSDLQueueStatus)	data.
void	Copies the IFE State value into the
SetIfeState(	IFE_Message data.
BYTE IfeState)
void	Copies the Message Id into the
SetMessageId	IFE_Message data.
(BYTE MessageId)
void	Sets the length of the IFE_Message
SetMessageLength( )	data based on the raw data message
	length.
void	Copies the MessagesProcessed into the
SetMessagesProcessed	IFE_Message data.
(short MessagesProcessed)
void	Copies the MovieCycleId into the
SetMovieCycleId	IFE_Message data.
(BYTE MovieCycleId)
void	Copies the MovieCycleStatus into the
SetMovieCycleStatus	IFE_Message data.
(BYTE MovieCycleStatus)
void	Copies the MovieNumber into the
SetMovieNumber	IFE_Message data.
(BYTE MovieNumber)
void	Copies the ChannelNumber into the
SetNewVideoChannelNumber	IFE_Message data.
(BYTE ChannelNumber)
void	Copies the RecordNumber into the
SetNewVideoRecordNumber	IFE_Message data using LanguageId
(BYTE RecordNumber,	to pad the text field appropriately.
BYTE LanguageId)
void	Copies the OrderId into the
SetOrderId	IFE_Message data.
(ID OrderId)
void	Copies the ProductCode into the
SetProductCode	IFE_Message data.
(char *pProductCode)
void	Copies the ProductMap into the
SetProductMap	IFE_Message data.
(long ProductMap)
void	Copies the Quantity into the
SetQuantity	IFE_Message data.
(BYTE Quantity)
void	Copies the QueuePosition into the
SetQueuePosition	IFE_Message data.
(short QueuePosition)
void	Copies the seats identified by the
SetSeatTransferData	two input arguments into the
(CString &csSeat1,	IFE_Message data.
CString &csSeat2)
void	Sets IFE_Message data to
SetSEBMessagingOff( )	SEB-Messaging Off.
void	Sets IFE_Message data to
SetSEBMessagingOn( )	SEB-Messaging On.
void	Copies SeatAddress into the
SetSEBMessageSeatAddress	IFE_Message data.
(char *SeatAddress)
void	Copies SequenceNumber into the
SetSequenceNumber	IFE_Message data.
(WORD SequenceNumber)
void	Copies the SessionStatus into the
SetSessionStatus	IFE_Message data.
(BYTE SessionStatus)
void	Sets the Message ID to
SetSIBacklightCmd	SI_BACKLIGHT_CTL and the
(bool bBacklightOn)	first data byte 1 (ON) or 0 (OFF)
	based on bBacklightOn.
void	Copies StoreStatus into the
SetStoreStatus	IFE_Message data.
(BYTE *StoreStatus)
void	Copies tmRemaining into the
SetTimeLeftOnCurrentCycle	IFE_Message data.
(TIME tmRemaining)
void	Copies tmNextShow into the
SetTimeUntilNextShowing	IFE_Message data.
(TIME tmNextShow)
void	Copies TransactionStatus into the
SetTransactionStatus	IFE_Message data.
(BYTE TransactionStatus)
void	Copies UpdateType into the
SetUpdateType	IFE_Message data.
(BYTE UpdateType)

[0693] The TestPort_Message class TSTPRTMS.CPP is derived from ARCNET_Message to communicate with the test port of the file server.

[0694]


TestPort_Message Class Function	Purpose

void	Extracts data from an
GetBiteResults	BIT_BITE_STATUS (op_status)
(DWORD *pdwErrorCode,	and returns it to the calling function
DWORD *pdwTestID,	for inclusion in the Application
DWORD *pdwWitnessType,	event log.
DWORD *pdwSuspectType,
DWORD *pdwSuspectID,
DWORD *pdwTSData,
DWORD *pdwErrorClear)
void	Extracts the source address field
GetRawSourceAddress	from the IFE_Message data and
(BYTE *pszSrcAddrs)	copies it into pszSrcAddrs.
BYTE	Returns the SubCommand byte from
GetSubCommand( )	the IFE_Message data.
bool	Parses the text contained in the
SetRevInfo	pszRevInfo string and formats the
(BYTE *pbyRevInfo)	data into the IFE_Message data.
void	Sets the SubCommand byte in the
SetSubCommand	IFE_Message data with command.
(BYTE command)

[0695] StandardProtocol class STNDRDPR.CPP is derived from the IFE_Message class and is the base class that supports the Hughes standard start-stop protocol as described in the, which is used in communications with PATMessage class, PIMessage class, PATSEBMessage class.

[0696]


StandardProtocol Class Functions	Purpose

bool	Decode data from Hughes standard
Decode( )	start-stop data into just plain data.
	Returns FALSE if decoding failed.
void	Encodes the data into the Hughes
Encode( )	standard start-stop format.
BYTE	Returns the Command Byte from the
GetCommand( )	IFE_Message data.
bool GetData	Reads data from the hInPipe into the
(HANDLE hInPipe,	IFE_Message data. Returns the
ULONG *pBytesRead)	number of bytes read in pBytesRead.
	Returns FALSE if read failed.
bool	Reads and encodes the data from the
GetData	InputQueue into the IFE_Message
(Queue *pInputQueue)	data. Returns FALSE if no data or if
	pointer is NULL.
BYTE	Returns the Command Length from
GetLengthOfCommand( )	IFE_Message data.
bool	Returns FALSE if Command in
IsValidCommand( )	IFE_Message is not recognized as
	one of the Standard Protocol
	commands.
bool	Outputs encoded data from
PutData	IFE_Message data to the OutPipe,
(HANDLE hOutPipe,	reporting the number of
ULONG *pBytesWritten)	BytesWritten.
	Returns FALSE if failed the written.
bool	Decodes the data from the
PutData	IFE_Message data and puts it on the
(Queue *pOutputQueue)	OutputQueue. Returns FALSE if
	message could not be decoded.
void	Sets the Message Length and
SetLength( )	Destination Address of the
	IFE_Message.

[0697] The PATMessage PATMSSGE.CPP is derived from StandardProtocol to support communication with the primary access terminal's 225 PI board.

[0698]


PATMessage Function	Purpose

void	Converts binary format card data in
ConvertCardDataToASCIIFormat	pCardData to ASCII format in
(unsigned char *pCardData,	IFE_Message data. Requires
long lCardDataLength)	CardDataLength to set the length of
	the IFE_Message data field.
void	Converts PrinterStatus to ASCII
ConvertPrinterStatusToASCII	format and stores in IFE message
(long lPrinterStatus)	data.
void	Stub.
DerivedDecode( )
void	Stub.
DerivedEncode( )
void	Stub.
GetAudioChannel
(BYTE *LeftTimeSlot,
BYTE *RightTimeSlot)
long	Copies magcard data
GetCardDataBinaryFormat	(MagCardReadData Command is
(unsigned char *pCardData)	first byte) in the original binary
	format into pCardData. Size of
	user-supplied buffer should be
	MAXMESSAGEDATASIZE.
	Returns adjusted message length.
	Returns 0 if unable to copy data.
BYTE	Returns the control byte from the
GetControlByte( )	IFE_Message data.
BYTE	Returns address of destination device
GetDestinationDevice( )	from IFE_Message data.
BYTE	Returns address of source device
GetSourceDevice( )	from IFE_Message data.
void	Returns the Preview Channel info
GetVideoPreviewChannel	from the IFE_Message data
(BYTE *Channel,	into Channel and AudioSel.
BYTE *AudioSel)
void	Stub.
GetVideoPreviewSource
(char *Source)
void	Simply calls the IFE_Message
SetAddress	version.
(char *Address)
void	Develops the Audio Channel info in
SetAudioChannel	the IFE_Message data based on the
(BYTE LeftTimeSlot,	LeftTimeSlot and RightTimeSlot
BYTE RightTimeSlot)	values.
void	Develops the Audio Volume info in
SetAudioVolume	the IFE_Message data based on the
(BYTE LeftVolume,	LeftVolume and RightVolume
BYTE RightVolume)	values.
void	Sets up request to PI to dump the
SetCardData(	most recent magcard buffer into
unsigned char *pCardData)	CardData.
void	Sets address of destination device in
SetDestinationDevice	IFE_Message data to
(BYTE byDstDeviceAddr)	byDstDeviceAddr.
void	Set address of source device in
SetSourceDevice	IFE_Message data to
(BYTE bySrcDeviceAddr)	bySrcDeviceAddr.
void	Copies the Channel and AudioSel
SetVideoPreviewChannel	data into IFE_Message data.
(BYTE Channel,
BYTE AudioSel)
void	Stub.
SetVideoPreviewSource
(har *Source)

[0699] The PIMessage class PIMSSAGE.CPP is derived from the StandardProtocol class to handle the specifics of the primary access terminal's 225 PI board.

[0700]


PIMessage Class Function	Purpose

void	Massages the data in IFE_Message data
DerivedDecode( )	for local usage.
void	Massages the data in IFE_Message data
DerivedEncode( )	for output to the PI board.
BYTE	For testing only.
fooGetCommand( )
BYTE	For testing only.
fooGetLengthOfCommand( )
bool	For testing only.
foolsValidCommand( )
bool	Stub. Always returns FALSE. See
GetCardData	PATMessage for this functionality.
(unsigned char *CardData)
bool	If the current command was a Channel
GetCurrentChannelResponse	Request, this returns the Channel and
(BYTE *Channel,	AudioSel.
BYTE *AudioSel)	Otherwise returns FALSE.
BYTE	Returns the Command Byte from last
GetMsgCommandByte( )	PIMessage.
bool	If current command was a Part&Revision
GetPartAndRevisionData	command, copies the data from
(BYTE *PartAndRevision)	IFE_Message data into PartAndRevision.
	Otherwise returns FALSE.
bool	If current command was a Status Request
GetStatusResponse	command, copies the data from
(BYTE *Response)	IFE_Message data into Response.
	Otherwise returns FALSE.
bool	If current command was a Video Preview
GetVideoPreviewVCP	VCP command, returns the current VCP
(char *VCPName)	assigned to Video Preview screen,
	persisted by PIInterface VLRU into
	VCPName.
	Otherwise returns FALSE.
bool	Returns TRUE only if the current
IsCardReaderCommand( )	Command is one from the card reader.
bool	Returns TRUE only if the current
IsTunerCommand( )	Command is one from or for the Tuner.
bool	Stub. Always returns FALSE.
IsUnsolicated( )
void	Builds a Part&Revision Request into
PartAndRevisionRequest( )	the IFE_Message data.
void	Stub. See PATMessage for this
PutCardData	functionality.
(unsigned char *CardData)
void	Builds a Current Channel Request into
RequestCurrentChannel( )	the IFE_Message data.
void	Builds an Ack-by-Current-Command into
SetAck(	the IFE_Message data.
BYTE byCmdToBeAcked)
void	Copies byMsgCmd into the Message
SetMsgCommandByte	Command Byte class member data.
(BYTE byMsgCmd)
void	Builds a NAK-by-Current-Command into
SetNak	the IFE_Message data.
(BYTE byCmdToBeNaked)
void	Stub.
SetVideoPreviewToVCP(
char *VCPName)
void	Builds a Software Reset Command into
SoftwareReset( )	the IFE_Message data.
void	Builds a Status Request Command into
StatusRequest( )	the IFE_Message data.
void	Builds a Switch Tuner Type Command
SwitchTunerType	into the IFE_Message data.
(BYTE TunerType)
void	Builds a Tune Channel Command into the
TuneChannel	IFE_Message data using Channel and
(BYTE Channel,	AudioSel as part of the command.
BYTE AudioSel)

[0701] The PATSEBMessage class PTSBMSSG.CCP is derived from StandardProtocol but currently none of its functions are implemented. Therefore, it behaves exactly like StandardProtocol.

[0702]


PATSEBMessage Class Function	Purpose

void DerivedDecode( )	Stub.
void DerivedEncode( )	Stub.
BYTE GetLengthOfCommand( )	Stub. Returns Zero.
bool IsValidCommand( )	If Command is recognized by
	GetLengthOfCommand( ), returns
	TRUE.
	Currently returns FALSE.

[0703] The Serial_Message SRLMSSGE.CPP is derived from IFE_Message. It is used to carry and process Serial data from the Message Processor to any serial I/O devices NAU. Currently, it is the base class for VCP_Message. The pure virtual functions defined in IFE Message is implemented within Serial Message.

[0704]


Serial_Message Function	Purpose

bool	Local version reads data into IFE_Message
GetData	data from InPipe, returning the number of
(HANDLE hInPipe,	BytesRead. Returns FALSE if no data read
ULONG *pBytesRead)	from InPipe.
bool	Local version fills IFE_Message data
GetData	structures with data contained in input
(IfeIdType idSource,	arguments.
IfeIdType idDestination,	Always returns TRUE.
BYTE *pData,
DWORD dwDataLen)
bool	Simply calls the IFE_Message version.
GetData
(Queue *pInputQueue)
bool	Local version copies the data and length
PutData	elements from an IFE_Message to the
(BYTE *byData,	specified arguments.
DWORD *pDataLen)	Always returns TRUE.
bool	Simply calls the IFE_Message version.
PutData
(HANDLE hOutPipe,
ULONG *pBytesWritten)
bool	Simply calls the IFE_Message version.
PutData(Queue
*pOutputQueue)

[0705] The VCP_Message class VCPMSSGE.CPP is derived from Serial_Message (which is derived from IFE_Message) to communicate with the Video Players. It is used between the Message Processor and the VCP NAU.

[0706]


VCP_Message Class Function	Purpose

void	Stub.
Format
(VCPMessageFormat nMessageFormat)
CString	Overrides the one in the
GetAddress( )	IFE_Message base class.
	Returns the contents of the
	IFE_Message data Address
	field in a CString.
void	If a valid VCP PlayerCommand,
GetCommandData	parses out the Command Bytes
(PLAYERCOMMANDS	from the IFE_Message data,
*pPlayerCommand,	returning it in byData.
BYTE *byData,	Returns the number of bytes in
int *pDataLen)	DataLen, Zero if invalid
	command.
CString	Overrides the one in the
GetLruInfo( )	IFE_Message class.
	This version creates a CString
	from the data contained in
	the LruInfo field of the
	IfeMessageData structure
	and returns it to the function.
void	Stub
GetPlayerResponse
(PlayerCommands *pPlayerCommand,
PLAYERSTATE *pPlayerState,
BYTE *pData,
BYTE *pDataLen)
void	Parses data from IFE_Message
GetResponseData	data into byData, returning the
IfeFunctionType *pResponseCommand,	DataLen size of the data.
BYTE *byData,	Returns responses Ack or
int *pDataLen)	Nak in ResponseCommand.
PLAYERSTATE	Returns the enumerated state
GetState( )	of the VCP (e.g., Playing,
	FastForward, etc.)
void	Retrieves state information from
GetStateInfo	this IFE Message object.
(PLAYERSTATE *pState,	Assumes that state information
DWORD *pTime)	was writing using the
	SetStateInfo member function.
bool	Returns FALSE if checksum
IsValidChecksum( )	test.
void	Overrides SetAddress in
SetAddress	IFE_Message base class.
(CString csAddress)	Address field of the
	IfeMessageData structure for
	this message is populated using
	the CString input argument.
void	Calculates and writes a
SetChecksum( )	checksum to the IFE Message.
	Then stores the full length
	of the message in the
	MessageLength field of the
	message.
void	Overrides the function in the
SetLruInfo(	IFE_Message base class.
CString csLruInfo)	This version copies the
	csLruInfo data to the LruInfo
	field of IFE_Message data.
void	Converts enumerated internal
SetPlayerCommand	PlayerCommand into the actual
(PlayerCommands nPlayerCommand,	command byte to go to the VCP.
BYTE *byData,	Returns any associated data from
BYTE byDataLen)	IFE_Message data into byData
	and returns its length in
	DataLen.
void	Writes VCP State and Time
SetStateInfo	information to the IFE
(PLAYERSTATE nState,	Message data. State information
DWORD dwTime)	is retrieved using
	GetStateInfo( ).
void	Writes the UnitId into the
SetUnitId	IFE Message data.
(PGENERIC_TEXT pszUnitId)

[0707] Thus, systems, methods and articles of manufacture have been disclosed that provide for a networked passenger entertainment system that integrates audio, video, passenger information, product ordering and service processing, communications, and maintainability features, and permits passengers to selectively order or request products and services, receive video, audio and game data for entertainment purposes, and communicate with other passengers and computers on- and off-board the aircraft, and which thereby provides for passenger selected delivery of content over a communication network. It is to be understood that the above-described embodiments are merely illustrative of some of the many specific embodiments that represent applications of the principles of the present invention. Clearly, numerous and other arrangements can be readily devised by those skilled in the art without departing from the scope of the invention.

Claims

1. A complete implemented method for enabling a computer to manage communication over a network between the computer and a plurality of physical devices, comprising the steps of:

interfacing the plurality of physical devices with one or more device drivers within the computer;

managing communications between the plurality of physical devices and the computer through the device drivers with one or more virtual line replaceable unit objects within one or more network address unit objects for each of the plurality of physical devices; and

moving messages between the one or more network addressable unit objects and the one or more device drivers with a message processor, said message processor including an input/output handler for providing communications between the message processor and the one or more device drivers, and said message processor further including a pipe processor for moving common format messages to and from the one or more network addressable unit objects.

2. The method as recited in claim 1, further comprising the step of receiving messages containing network routing addresses from the one or more device drivers.

3. The method as recited in claim 2, wherein the message processor further performs the steps of utilizing the network routing address and a physical device type to access a line replaceable unit (LRU) table and of determining an appropriate network addressable unit for the message.

4. The method as recited in claim 3 wherein the message processor further performs the step of translating messages from a first format to a second format utilizing the LRU table.

5. The method as recited in claim 4, wherein the message processor further performs the step of moving messages between the pipe processor and the one or more network addressable unit objects with an input named pipe and an output named pipe.

6. The method as recited in claim 1, wherein the message processor further performs the step of interfacing the device drivers with the input/output handler.

7. The method as recited in claim 6 wherein the message processor further performs the step of creating a device handler for each device driver.

8. A system for controlling a passenger entertainment system, including a computer for managing communication over a network between the computer and a plurality of physical devices to control one or more aspects of the passenger entertainment system, said computer comprising:

one or more device drivers for interfacing the plurality of physical devices;

one or more network addressable unit objects having virtual line replaceable unit objects therein for each of the plurality of physical devices, said virtual line replaceable unit objects configured to manage communications between the plurality of physical devices and the one or more aspects of the passenger entertainment system; and

a message processor for moving messages between the one or more network addressable unit objects and the one or more device drivers, said message processor including an input/output handler for providing communications between the message processor and the one or more device drivers, said message processor further including a pipe processor for moving common format messages to and from the one or more network addressable unit objects.

9. The system as recited in claim 8, wherein the message processor receives messages containing network routing addresses from the one or more device drivers.

10. The system as recited in claim 9, wherein the message processor further comprises a LRU table and utilizes the network routing address and a physical device type to access the LRU table and determine an appropriate network addressable unit for the message.

11. The system as recited in claim 10, wherein the message processor utilizes the LRU table to translate messages from a first format to a second format.

12. The system as recited in claim 8, wherein the pipe processor further comprises a network addressable unit server having an input named pipe and an output named pipe coupled to the network addressable unit objects for moving messages therebetween.

13. The system as recited in claim 8, wherein the I/O handler further comprises a plurality of device handlers to interface the device drivers.

14. The system as recited in claim 13, wherein the message processor creates a device handler for each device driver.

15. A passenger entertainment system comprising a plurality of line replaceable units for performing entertainment and passenger and operator control functions, a primary access terminal for providing an operator interface to the passenger entertainment system, and a cabin file server for processing passenger transactions, said primary access terminal and said cabin file server each having a control center common executive, said control center common executive further comprising:

a message processor for moving messages to and from the line replaceable units and for translating messages from the line replaceable units into a common format, wherein the message processor includes an input/output (I/O) handler for providing communications between the message processor and the plurality of line replaceable units, said message processor further including a pipe processor for moving common format messages to and from the message processor;

one or more network addressable units connected to the pipe processor for routing common format messages to and from the message processor, said one or more network addressable units having a virtual line replaceable unit for each of the plurality of line replaceable units; and

a transaction dispatcher connected to the one or more network addressable units for managing communication to and from the network addressable units.

16. The passenger entertainment system of claim 15 wherein the I/O handler interfaces the line replaceable units through a plurality of device drivers, and wherein said I/O handler comprises:

a plurality of device handlers, wherein the device handlers include MessageFromDrivers that read messages from a device driver and MessageToDrivers that send messages to a device driver;

a ToDriverQueue connected to a MessageToDriver associated with a serial NT device driver for sending serial messages to the MessageToDriver; and

an ArcnetHandler FIFO Out connected to a MessageToDriver associated with an ARCNET device driver for sending ARCNET messages to the MessageToDriver.

17. The passenger entertainment system of claim 16 wherein the pipe processor comprises a network addressable unit (NAU) server, said NAU server further comprising:

a plurality of named pipes including InPipeProcessors and OutPipeProcessors coupled to the one or more network addressable units through a plurality of pipes for sending and receiving messages to and from the one or more network addressable units; and

NAU out queues for sending messages to the OutPipeProcessors.

18. The passenger entertainment system of claim 17 wherein the message processor further comprises a plurality of routers, said routers comprising:

a MessageToHandler coupled to the InPipeProcessors for receiving messages from a network addressable unit, coupled to the ToDriverQueue and the ArcnetHandler FIFO Out for moving messages to a MessageToDriver and then to an appropriate device driver;

a MessageToPipeProcessor coupled to the MessageFromDrivers for receiving messages from the device drivers;

an AddMessageToOutQueue coupled to the MessageToPipeProcessor and to the NAU out queues for moving messages to the NAU out queues; and

a line replaceable unit (LRU) table connected to MessageToHandler and to the AddMessageToOut Queue for translating messages.

19. The passenger entertainment system of claim 18 wherein the LRU table comprises an entry for every LRU in the system, said entry comprising a network routing address and a physical device type.

20. The passenger entertainment system of claim 18 wherein a message from the serial NT driver and the associated MessageFromDriver is in a serial message format, and a message from the ARCNET driver and the associated MessageFromDriver is in an ARCNET message format, said serial message format and said ARCNET message format messages being received by said MessageToPipeProcessor and sent to the NAU out queues as an in-light entertainment (IFE) format message from the AddMessageToOut Queue.

Patent Citations (151)

Patent	Date	Inventor	Cited By
US3602891(A)	1971-08-01	Clark et al.	Applicant
US3811127(A)	1974-05-01	Griffee et al.	Applicant
US3860932(A)	1975-01-01	Hochbrueckner	Applicant
US3868497(A)	1975-02-01	Vietor	Applicant
US3972045(A)	1976-07-01	Perret	Applicant
US3997718(A)	1976-12-01	Ricketts et al.	Applicant
US4047175(A)	1977-09-01	Taira et al.	Applicant
US4058837(A)	1977-11-01	Muntz	Applicant
US4099780(A)	1978-07-01	Schmidhuber	Applicant
US4118733(A)	1978-10-01	Sarson et al.	Applicant
US4187760(A)	1980-02-01	Holt	Applicant
US4281352(A)	1981-07-01	Hoffman	Applicant
US4283740(A)	1981-08-01	Okada	Applicant
US4290083(A)	1981-09-01	Collender	Applicant
US4352200(A)	1982-09-01	Oxman	Applicant
US4393329(A)	1983-07-01	Lehnert	Applicant
US4427038(A)	1984-01-01	Oesterle et al.	Applicant
US4428078(A)	1984-01-01	Kuo	Applicant
US4433344(A)	1984-02-01	Gardin et al.	Applicant
US4465907(A)	1984-08-01	Minear et al.	Applicant
US4472607(A)	1984-09-01	Houng	Applicant
US4475196(A)	1984-10-01	La Zor	Applicant
US4490117(A)	1984-12-01	Parker	Applicant
US4513315(A)	1985-04-01	Dekker et al.	Applicant
US4521021(A)	1985-06-01	Dixon	Applicant
US4521806(A)	1985-06-01	Abraham	Applicant
US4554579(A)	1985-11-01	Citta	Applicant
US4554993(A)	1985-11-01	Houng	Applicant
US4573072(A)	1986-02-01	Freeman	Applicant
US4584603(A)	1986-04-01	Harrison	Applicant
US4591906(A)	1986-05-01	Morales-Garza et al.	Applicant
US4630821(A)	1986-12-01	Greenwald	Applicant
US4647980(A)	1987-03-01	Steventon et al.	Applicant
US4649570(A)	1987-03-01	Terbrack et al.	Applicant
US4684981(A)	1987-08-01	Toyoshima et al.	Applicant
US4692569(A)	1987-09-01	Winner	Applicant
US4765481(A)	1988-08-01	Walsh et al.	Applicant
US4787027(A)	1988-11-01	Prugh et al.	Examiner
US4835604(A)	1989-05-01	Kondo et al.	Applicant
US4853555(A)	1989-08-01	Wheat	Applicant
US4853764(A)	1989-08-01	Sutter	Applicant
US4866515(A)	1989-09-01	Tagawa et al.	Applicant
US4866787(A)	1989-09-01	Olesen	Applicant
US4868577(A)	1989-09-01	Wingard	Applicant
US4896209(A)	1990-01-01	Matsuzaki et al.	Applicant
US4918535(A)	1990-04-01	Grabis et al.	Applicant
US4945563(A)	1990-07-01	Horton et al.	Applicant
US4975696(A)	1990-12-01	Salter, Jr. et al.	Applicant
US4997233(A)	1991-03-01	Sharon	Applicant
US4999729(A)	1991-03-01	Stifter	Applicant
US5001555(A)	1991-03-01	Park	Applicant
US5024398(A)	1991-06-01	Riedinger et al.	Applicant
US5035005(A)	1991-07-01	Hung	Applicant
US5051822(A)	1991-09-01	Rhoades	Applicant
US5179447(A)	1993-01-01	Lain	Applicant
US5181107(A)	1993-01-01	Rhoades	Applicant
US5193208(A)	1993-03-01	Yokota et al.	Applicant
US5208590(A)	1993-05-01	Pitts	Applicant
US5214505(A)	1993-05-01	Rabowsky et al.	Applicant
US5218167(A)	1993-06-01	Gasque, Jr.	Applicant
US5220419(A)	1993-06-01	Sklar et al.	Applicant
US5289272(A)	1994-02-01	Rabowsky et al.	Applicant
US5301245(A)	1994-04-01	Endoh	Applicant
US5319452(A)	1994-06-01	Funahashi	Applicant
US5363433(A)	1994-11-01	Isono	Applicant
US5370306(A)	1994-12-01	Schulze et al.	Applicant
US5373324(A)	1994-12-01	Kuroda et al.	Applicant
US5374104(A)	1994-12-01	Moore et al.	Applicant
US5404567(A)	1995-04-01	DePietro et al.	Applicant
US5425516(A)	1995-06-01	Daines	Applicant
US5430492(A)	1995-07-01	Dambacher	Applicant
US5437464(A)	1995-08-01	Terasima et al.	Applicant
US5440337(A)	1995-08-01	Henderson et al.	Applicant
US5442652(A)	1995-08-01	Jacobson	Applicant
US5463656(A)	1995-10-01	Polivka et al.	Applicant
US5465384(A)	1995-11-01	Bejan et al.	Applicant
US5480158(A)	1996-01-01	Schulze et al.	Applicant
US5481478(A)	1996-01-01	Palmieri et al.	Applicant
US5481757(A)	1996-01-01	Mihara et al.	Applicant
US5510900(A)	1996-04-01	Shirochi et al.	Applicant
US5524272(A)	1996-06-01	Podowski et al.	Applicant
US5526035(A)	1996-06-01	Lappington et al.	Applicant
US5532753(A)	1996-07-01	Buchner et al.	Applicant
US5532760(A)	1996-07-01	Inoue	Applicant
US5537152(A)	1996-07-01	Ishikawa	Applicant
US5539449(A)	1996-07-01	Blahut et al.	Applicant
US5539657(A)	1996-07-01	Utsumi et al.	Applicant
US5546050(A)	1996-08-01	Florian et al.	Applicant
US5547248(A)	1996-08-01	Marechal	Applicant
US5555021(A)	1996-09-01	Igarashi	Applicant
US5565908(A)	1996-10-01	Ahmad	Applicant
US5568484(A)	1996-10-01	Margis	Applicant
US5581270(A)	1996-12-01	Smith et al.	Applicant
US5584047(A)	1996-12-01	Tuck	Applicant
US5596647(A)	1997-01-01	Wakai et al.	Applicant
US5596745(A)	1997-01-01	Lai et al.	Applicant
US5600717(A)	1997-02-01	Schneider et al.	Applicant
US5608535(A)	1997-03-01	Yoshida et al.	Applicant
US5610822(A)	1997-03-01	Murphy	Applicant
US5617331(A)	1997-04-01	Wakai et al.	Applicant
US5641319(A)	1997-06-01	Stoel et al.	Applicant
US5651050(A)	1997-07-01	Bhagat et al.	Applicant
US5757796(A)	1998-05-01	Hebb	Applicant
US5808661(A)	1998-09-01	Infiesto et al.	Applicant
US5854591(A)	1998-12-01	Atkinson	Applicant
US5973722(A)	1999-10-01	Wakai et al.	Applicant
US6002758(A)	1999-12-01	Ely et al.	Examiner
US6014381(A)	2000-01-01	Troxel et al.	Applicant
US6049819(A)	2000-04-01	Buckle et al.	Examiner
US6058288(A)	2000-05-01	Reed et al.	Applicant
US6098112(A)	2000-08-01	Ishijima et al.	Examiner
US6131119(A)	2000-10-01	Fukui	Applicant
US6163823(A)	2000-12-01	Henrikson	Applicant
US6201797(B1)	2001-03-01	Leuca et al.	Applicant
US6499027(B1)	2002-12-01	Weinberger	Applicant
DE3426893	1986-01-01		Applicant
EP230280	1987-07-01		Applicant
EP277014	1988-08-01		Applicant
EP457673	1991-11-01		Applicant
EP569225	1993-11-01		Applicant
EP647914	1995-04-01		Applicant
EP671861	1995-09-01		Applicant
FR2652701	1991-04-01		Applicant
FR2716764	1995-09-01		Applicant
JP1291281	1988-05-01		Applicant
JP63202194	1988-08-01		Applicant
JP63208995	1988-08-01		Applicant
JP63209333	1988-08-01		Applicant
JP63215287	1988-09-01		Applicant
JP1257640	1989-10-01		Applicant
JP1300719	1989-12-01		Applicant
JP1301430	1989-12-01		Applicant
JP1301431	1989-12-01		Applicant
JP2013490	1990-01-01		Applicant
JP2148927	1990-06-01		Applicant
JP2149196	1990-06-01		Applicant
JP2155853	1990-06-01		Applicant
JP2171399	1990-07-01		Applicant
JP2179567	1990-07-01		Applicant
JP2304791	1990-12-01		Applicant
JP6111124	1994-04-01		Applicant
JP7135500	1995-05-01		Applicant
JP7202918	1995-08-01		Applicant
JP9074551	1997-03-01		Applicant
WO90/15508	1990-12-01		Applicant
WO93/16558	1993-08-01		Applicant
WO94/13105	1994-06-01		Applicant
WO94/28679	1994-08-01		Applicant
WO95/12853	1995-05-01		Applicant
WO96/19897	1996-06-01		Applicant
WO9811686(A2)	1998-03-01		Applicant

Non-Patent Literature (1)

Hasegawa, network connection device, Jan. 23, 1998.Examiner