3. Hardware Configurations:


The following pages explain 6 hardware configurations that are available for standalone sites.

All of the below hardware configurations except the Standalone DVC style configurations are taken from existing examples..


Standard configuration for small sites. 4 CCM (Channel Control Module) cards with 2 outputs each can be fitted to any one PC for a maximum of 4 channels. Each channel can support 2 monitors or more monitors by looping.

Any RCIS configuration can support sound by inclusion of the DRA (Digital Recorded Announcements) module. The small station configuration shown here will also support DRA without an external processor but larger sites may require an additional DRA processor.

3.1.2. CCM CRATE:

As preceding but uses an external CCM Crate allowing up to 16 CCM or VDA (Video Distribution Amplifier) Cards. Configuration options are as above. This has the advantage on small to medium size stations that the monitor wiring loom only need extend back to the equipment room.


Uses external stand-alone DVCís (Digital Video Converter) each with internal PSU, optional mains loop through, watch dogs, etc. Typically mounted in the monitor. Fast and effective way of addressing many channels. Not recommended for large stations as health check polls are restricted. Multidrop is a simple but less reliable means of transmission which is unsuitable for poll health monitoring and is losing popularity. Supportable by QSL if requested but otherwise not recommended.



As above but data is regenerated in each DVC allowing greater distances, improved data integrity, efficient health check polling. A default bypass relay connects input to output in the event of power failure. Messages are sent both ways around the loop for high fault tolerance.

QSL supports this type of device with the same CCM card as used in previous configurations.


Showing a standard dual RCIS configuration with a single CCM crate. The user terminals use file mirroring to effect an instant "hot" standby. This method allows a defective terminal to be diagnosed and replaced without service disruption.

Crate design is modular and can be cascaded to support virtually any combination or quantity of channels including Flap and LCD drivers. The crate design can support animation (integrated with standard output if necessary) using a higher specification processor and the appropriate software.


As per standard dual RCIS but utilises dual DVC Crate hardware. Allows the user to change over the display hardware using a key switch thereby virtually eliminating any system critical points.

For larger sites, the DVCís would be stand-alone (with a DVC in each monitor) or a dispersed crate configuration. In such a configuration, the dual DVC Crate hardware would be replaced by Communications Servers and would again be changeable by use of a key switch.


RCIS provides extensive integration options allowing external connection to other RCIS systems for centralised control or to any defined information highway for full automation. The RCIS database engine is a generic building block that will function locally, remotely or automatically.

3.2.1. WAN RCIS:

WAN (Wide Area Network) RCIS is where an RCIS building block system is connected to a Wide Area Network. An example system is as follows:

Example Data Flow Layout for Long Line RCIS (Woking):

 Hardware Notes:
  • Each Site consists of one or more standard PC's (4 U rack occupancy) optionally including a PC expansion Crate (3 U rack case for use with or without a rack).
  • All display hardware cards are housed within the above PCs or Crates.

Communication Path Notes:

  • Bi-directional (for alternate data path in event of failure)
  • Typically Async (2 standard UARTS per PC) @ 9600 Bd, 8 Data bits, 2 stop bits, No parity.

(Full duplex async modems usually not included, 2 required per site).

The above demonstrates the principle of the bi-directional loop. Any single part of the loop may be broken and, as proven in practice, no messages are lost and no affect is noticed other than a warning message.

A key factor to WAN RCIS is the simplicity of use. The user terminal is very similar in appearance to a standalone RCIS system. The main difference is that changes are semi automatically applied up or down the path (after user confirmation).

The system employs automation as a means of allowing the user to guide operation rather than the user attempting manual control of all train movements. Minimal user interaction is required to set up and monitor train movements. For example, the user can mark a train as late running (using the same procedure for putting a late running remark on a standalone system) which will automatically make that train depart later by the specified amount all throughout the wide area system. The user can log into any single site for checking, notice display or other.

Configuration flexibility is almost unlimited. The system may be controlled at any site and any site may contain more than one terminal. Each site may have internal or external CCM cards or a combination of both (although such combinations are not recommended). The system can include DRA (Digitally Recorded Announcements).

By using translation modules, RCIS can use any input (eg: serial interface or network card) to nudge the database.

RCIS isolates it's own database engine from any external database. By maintaining it's own database engine and controlling kernel, RCIS can adapt to any protocol (eg: serial interface) or PC compatible interface (eg: network card) using translation modules.


Any of the previous configurations of RCIS can be connected to any defined electronic highway of train information (such as Railtrack's TD, TSDB, TRUST) to allow automation.

External control is linked to the RCIS database engine via protocol translation modules allowing external information to nudge the existing data for fully controlled automation. Any external connection takes the form of another "user" connected to the central database. In this way the RCIS controlling kernel can monitor changes and display the data as it would for a user.

In order to understand how RCIS adapts, it is necessary to preview the RCIS software structure. The central kernel, called the CRON (Chronological Module), provides the logic and control for the timetable driven database. The CRON monitors the database, controlling order, timed events and checking conflicts. The input devices interface to the database only and do not directly access the output drivers.

For example, if the user or an external influence changes a platform number, the GUI interface module changes the platform field in the relevant record only. The CRON is notified of the change and does a complete check for display and announcement continuity and conflicts. In the case of a platform change, this might involve removing the display from the original platform, putting another queued train onto the original platform, removing any other record from the target display (and pushing it back to queue), displaying it on the target and regenerating the summary of arrivals and summary of departures.

This structure is inherently robust. It contrasts with other structures that act more directly on the kernel and output drivers making expansion and software management difficult. The RCIS structure allows expansion to a number of users or external influences on the database, each potentially acting independently of the other.

External control can also be connected to WAN RCIS (Wide Area Network system previously described) which only needs connecting at one point.