Logic Manager

The logic manager is the invariant code that processes the interlocking controls by performing the safety checks and, if these are satisfactory, generates controls for the equipment out in the field.

From a software point of view, it is a ‘safe interpreter’ of a byte-code generated off-line from object-oriented language sources.

Object-oriented language is used to describe the signalling devices as objects belonging to a certain context class which, according to events (field indications, events from other objects, operator or automatic controls), develop their own state. The language also provides the possibility of defining, for each context class, several connections to the object controllers to make the safety logic for the signalling devices independent from the control and indication method. The peculiar characteristics of the ObjRail language, and types of variables in the context classes, are described in separate documents.

For each process cycle of the central interlocking unit, the logic manager processes the byte-code of the context classes, defined by the safety-logic software design engineer. The characteristics of each instance are always extracted during the execution phase from the configuration database.

Execution of the class byte-code produces an update of the class dynamic variables which represent the state of the logic entity, and an update of the interface variables which generate the control messages to the object controllers.

Variant software databases

Two application-dependent databases – interlocking rules database and configuration database – are included in the central interlocking unit software. These databases are managed by the invariant code described in the previous section.

The interlocking rules database contains the specific application’s safety logic which configures the HMR CBI so that it is in line with the signalling principles of the specific country.

The configuration database contains the site-specific data for a particular geographical application. This data defines the actual points, track circuits, signals and so on that are to be used with each of the processes defined in the interlocking rules database.

Data Preparation Process

The data preparation process (DPP) includes all tasks needed to produce the central interlocking unit’s data system files from source documents (the Signalling Scheme Plan and the Control Tables).

The scope includes preparing the safety logic and application-specific geographic data (all elements of application data used by the central interlocking unit). System file generation is a key step of the data preparation process in which the safety logic and geographic data are brought together to be loaded onto the central interlocking unit’s independent processing sections.

The data translation tools used in the data preparation process for the generic application and specific application phases are:

Plan Editor

Control Tables Generator

The data preparation process is in compliance with CENELEC EN 50128 Norm Railway applications - Communications, signalling and processing systems - Software for railway control and protection systems, in separate documents.