Wallboard Driver System - WDS

Home > Products > Display Software > Wallboard Driver System

Wallboard Driver System

The Wallboard Driver System (WDS), supplied by Telefax and installed at both the Chicago Board of Trade's (CBOT) and New York Mercantile Exchange’s
(NYMEX/COMEX) premises, acts as the mechanism by which information sourced from the exchanges' trading support systems and third party data vendors can be assimilated, formatted and displayed on the TransLux Datawall II display systems installed around their trading floors.

Each system consists of three software applications, a database server, a display driver and an administration terminal. These applications run on Intel type processor based PCs connected by an ethernet network and communicate using TCP/IP and UDP multicast protocols. Additionally there are multi-port data changeover switches (MDCS), commonly referred to as SmartSwitches, controlled by the display driver application.

data wall for data display The purpose of each component may be summarized as follows. The database servers receive the information sent to them by each data source, reformat it, store it in a database table and transmit changes to the other WDS components in Telefax's proprietary data format. They also store the configuration files and display layout files essential to the system's operation, forming essentially the 'hub' of the system. The display drivers retrieve the display layout files from the databases and use them to determine how to process the update information transmitted by the database. If they receive an update message relevant to them, they use the information in the layout files to reformat the data and transmit it in serial form for display on the DataWalls. The administration terminals are used to create and manipulate the display layout files held on the database servers. They are also used to control and monitor the operation of the other system elements.

The Trans-Lux DataWall displays are connected by serial data cabling to the MDCSs, which in turn are connected, by serial data cabling, to the wallboard drivers. The serial data is transmitted using the RS 422 transmission standard.

As the WDS was designed to provide redundancy, the two applications in the critical data path, the database and wallboard driver, are duplicated on separate PCs with one active as the 'main' or 'master' and the other passive in a hot standby role. Which database is 'main' and which is 'standby' is purely arbitrary in normal operation and determined by the order of startup. The standby database constantly monitors multicast 'heartbeat' transmissions from its partner that contain information relating to the inputs to the main database. Should the transmission of these 'heartbeat' multicasts cease for a configurable period, or the standby database determine that it has a more complete (or higher priority) set of inputs, the standby database will assert itself as 'master' and completely assume the role of the former 'main' database. The former 'main' database, should it not have failed, will then assume the role of 'standby'. All other WDS components running at the time this 'fail-over' occurs will detect the change of role and re-connect themselves to the new 'main' database.

Similarly each wallboard driver has a hot standby partner, in this case one is specifically configured as 'main' and the other 'standby'. The 'main' driver has control of the MDCS to which it is connected and normally holds it in such a position that its own serial outputs are directed to the wallboards. Should the control signal from the main driver fail, the MDCS will automatically 'fail-over' and switch the serial outputs from the standby driver through to the wallboard displays.

The administration terminals are not on the critical data path and the WDS will function without a single instance running on the network, so these are not included in the redundancy scheme.

Although the information provided to the WDS comes from multiple sources it is received by the databases in a common format, regardless of source, in the form of discrete messages transmitted over a TCP/IP streamed connexion initiated by the data source. The format of these messages was defined by the exchanges in consultation with Telefax. From the point of view of the WDS the format of these messages is defined in a series of configuration files held in the 'home' directory of the database server application. This enables simple changes to the message format to be accommodated without the need for software modification.

Once received the information is stored in database tables whose record format is defined by a series of configuration files held in the 'home' directory of the database server application. This enables simple changes to the record format to be accommodated without the need for software modification. Where (and if) the data in each incoming message field is stored in the relevant database record is determined by a series of 'action-map' configuration files held in the 'home' directory of the database server application.

The information is then reformatted and forwarded to the other WDS component applications by means of UDP multicast messages in a proprietary format. Other communication between WDS components takes the form of API messages transmitted over TCP/IP stream connexions to the database, and which may then, if necessary, be multicast on to other WDS components. These messages, which are exclusively concerned with system operation and not data throughput, are in a proprietary format that has not been published. This format is largely defined within the source code for each application, particularly the databases, which act as the 'hub' of the system.