[Go Up], [Go Back]. [Go On].

1.3.2. Generic SSI Software

SSI has been designed to be data-driven with a generic program operating on rules held in a `geographic' database. These data configure each SSI installation differently, and define the specific interlocking functions (although the more primitive functions are directly supported by the software). The relationship between generic program and the data is one in which the former acts as an interpreter for the latter---for this reason we usually refer to the generic software as the control interpreter in the sequel. The Motorola 6800 microprocessors used in SSI have a 16-bit address space: 60---80k bytes are EPROM which hold the generic program (about 20k bytes), and the Geographic Data; 2k bytes are RAM, and the rest is used for input and output devices. The modest RAM is used, mainly, to hold the system's record of the state of the railway---generally referred to as the image of the railway, or the internal state in the sequel.

All SSI software is organised on a cyclic basis with the major cycle determining the rate at which track-side equipment receive fresh commands, and the rate at which the image of the railway is updated. During one minor cycle the generic program: performs all redundancy management, self-test and error recovery procedures; updates system (software) timers and exchanges data with external devices such as panel processors; decodes one incoming data telegram and processes an associated block of Geographic Data; and processes the data associated with one outgoing command telegram. The latter phase is the most computational intensive part of the standard minor cycle because it is through these data that the Interlocking calculates the correct signal aspects.

The SSI minor cycle has a minimum duration of 9.5 ms, and a minimum major cycle time of 608 ms. However, SSI can operate reliably with a major cycle of up to 1,000 ms, with an individual minor cycle extensible to 30 ms. This flexibility is needed for handling panel requests. If the required minor cycle processes mentioned above can be completed in under the minimum minor cycle time, the control interpreter will process one of any pending panel requests (which are stored in a ring buffer). The data associated with a panel request must not require more than a further 20 ms of processing time---the data are structured such that accurate timing predictions can be made at compile time. If the minor cycle is too long the track-side functional modules will interpret the gaps between messages as data link faults, and will drive the equipment to the safe state in error.

The initialisation software compares the internal state of each of the three interlocking processors to determine the required start up procedure. When power is first applied a `mode 1' startup is necessary: this sets the internal state to a (designated) safe configuration, forces all output telegrams to drive the track-side equipment to the safe state and disables processing of panel requests; after a suitable delay so that TFM inputs can bring the internal state up to date, the Interlocking can be enabled under supervision from the technician's console. After a short power failure much of the contents of RAM will have been preserved and a `mode 2' or `mode 3' start up is appropriate. A `mode 2' start up resets the internal state to the safe configuration but preserves any restrictions that had been applied through the technician's console---the system is disabled for a period long enough for all trains to come to a halt, and allowed to restart normal operation automatically. A `mode 3' start up involves a similar reset but the status of routes is also preserved, and the system restarts immediately.

Validation of the generic SSI program has been described by Short [85] who points out the need for extensive testing to validate the final hardware and software combination because the software performs safety checks (redundancy management, etc.) on the hardware. Short also notes the difficulty (i.e., the intractability) of performing correctness proofs at the level of the semantics of 6800 assembler---yet when one considers that there are of the order of twenty megabytes of control and monitoring software on board the A340 [5] airliners, for example, the 20 thousand bytes of machine code that constitute the safety critical software in SSI is quite modest.

The validation effort that Short describes is rigorous and very thorough. The analysis has been aided by the fact that the SSI software is highly modular, and because the control flow is not complicated by the use of interrupts---polling mechanisms, as opposed to preemption mechanisms, have been used throughout. The analytic framework described includes functional, structural, information flow, and semantic analysis. These techniques have been applied in top down fashion through the modular structure of the software. Functional analysis checks the design against the (informal) requirements specification and identifies the requirements for each program module. Structural analysis checks the design and code for conformance to certain structured programming standards, and is intended to prove accessibility of every line of code. Information flow analysis detects illegal or omitted reference to variables. Given the control flow graph obtained by structural analysis, a semantic analysis assembles the individually validated modules into a validated whole, with a check that derived input/output relations correspond to the requirements. A detailed timing analysis is performed in the final review stage, prior to extensive online testing.

It seems that a completely formal treatment of the design path from high level system requirements to detailed timing analysis of the SSI generic program would present a major engineering challenge if conducted in a formal manner. Interesting though it would be to conduct a reappraisal of the correctness of the SSI software given the current state of the art, it is not what this thesis sets out to achieve (although see Chapter 5). Instead we consider an issue not mentioned by Short, nor even by Cribbens [24]---namely, the validation of the Geographic Data. Cribbens hints at the need for a ``knowledge based approach to scheme design'', but it was only later that proposals for formally based tools for Geographic Data preparation and analysis emerged [25]. The work reported in this thesis started from early consultations with Mitchell [66], but has progressed independently of British Rail's own research [48].


[Go Up], [Go Back]. [Go On].
Matthew Morley, Edinburgh. Date: 29 November, 1998