iFIDS.com Information Distribution

The diagram above demonstrates our typical method of data collection and display output distribution. Note that per this diagram a “FIDS Display” can be a FIDS, BIDS or GIDS output and the physical display can virtually any display type including LCD, Plasma, CRT as well as LED signs.

While the diagram is self-explanatory we would like to describe one key component of our in-airport display system, which is the iFIDS.com Custom Browser.

iFIDS.com Custom Browser

The Custom Browser is a piece of iFIDS.com proprietary software installed on each Display Controller PC that is responsible for communicating with the iFIDS.com Host. The Custom Browser continually monitors the health of the communication link between itself the iFIDS.com Host, and is the component that will determine if a given Display Controller PC is to communicate with the iFIDS.com Host via either the primary or secondary iFIDS.com ISP. The iFIDS.com Display Controller is designed to be ‘dumb’, which is to say it is not much more than a communication health monitor and display manager, and it is not at all responsible for determining how a given display output should look or behave. All instruction regarding display output look or behavior is sent from the iFIDS.com Host and can be managed and manipulated through the iFIDS.com on-line browser-based tools. The purpose of this strategy is to reduce the need for maintenance of software on individual Display Controller PC’s and to remove the need for human interaction at the Display Controller PC level when display changes need to be implemented.

Figure 1: iFIDS Custom Browser Instance Console

Figure 2: Typical Custom Browser Output

The iFIDS.com Custom Browser is necessary for in-airport display management only, where the display is intended to operate continuously unattended. Aside from continuous unattended displays, FIDS and Operational displays can be made available to your users’ on their individual PC’s via any web-browser provided they know an appropriate URL.

In Figure 1 we see a Custom Browser ‘instance’ configured to retrieve a display layout called ArrivalsDemo from either ifids.com or ifids.net (primary and secondary servers). The display output will be displayed in a screen area that is located at 0,800 relative to the 0,0 screen coordinates of the Controller PC, and the display output is set to be 800 pixels wide by 600 pixels tall. Figure 2 demonstrates that output

Figure 3: FIDS Screen from within Internet Explorer

There can be any number of Custom Browser instances running on a Controller PC, each potentially retrieving different information and displaying that information in different screen areas.

The iFIDS.com Custom Browser can be implemented in a number of ways and to some degree is designed to allow the customer to determine thier own costs because the rate structure for FIDS and Operational Displays is based on traffic, or the amount of data retrieved from the iFIDS.com Host. For the sake of demonstration assume a single Display Controller PC driving three different physical displays, and using that as an example a few different setup scenarios can be implemented.

Scenario 1, Same display information on each physical display: The assumption here is each physical display is intended to display identical information. In this case you can implement a single instance of the iFIDS.com Custom Browser, retrieving a single display profile from the iFIDS.com Host, and daisy chain (or split) the video output among the three physical displays. The number of displays you can daisy chain is not limited by iFIDS.com and because the rate structure is based on traffic the customer in this scenario is chanrged the equivalent of a single display output.

Scenario 2, Different display information on each physical display: The assumption in this scenario is each physical display is intended to display different information. In this case you can implement three different instances of the iFIDS.com Custom Browser, each retrieving a different display profile from the iFIDS.com Host. The video output is not daisy chained, rather each display output is driven to the physical display via a dedicated PC video output (for example, each output is directed to a specific video card in the PC, and in this case the PC would require three video cards). In this scenario the customer is charged the equivalent of three display outputs.

As previously mentioned the Custom Browser communicates regularly with the iFIDS.com Host for the sake of reporting and/or determining the health of communication between the Controller PC and the iFIDS.com Host. Embedded in this communication is the ability for the iFIDS.com Host to send various commands the Controller PC, including:

1. Refresh: Will retrieve changed screen layouts from the iFIDS.com Host.
2. Reboot: Will reboot the Controller PC in situations where Controller PC reboot is required.
3. Parameter Pull: Will retrieve browser instance display settings from the Controller PC and save them to the iFIDS.com Host.
4. Parameter Push: Will send browser instance display settings to the Controller PC, thus allowing administrative control of the Controller PC’s from an on-line user interface.
5. Suspend Health Monitoring due to Controlled Shut Down: Will cause the iFIDS.com Host to suspend health monitoring of a Custom Browser instance where the instance has been purposely taken off-line. In this case health monitoring will resume once the instance is re-started.
6. Suspend Health Monitoring due to Testing: Will cause the iFIDS.com Host to suspend health monitoring of a Custom Browser. In this case status monitoring will not resume once the instance is re-started, and is useful in situations where ongoing testing of an instance may be underway.
7. Application Version Update: Will cause the existing version of the Custom Browser to be overwritten with an updated version, downloaded from the iFIDS.com Host.