Skip to main content

Efficient verification of railway infrastructure designs against standard regulations


In designing safety-critical infrastructures s.a. railway systems, engineers often have to deal with complex and large-scale designs. Formal methods can play an important role in helping automate various tasks. For railway designs formal methods have mainly been used to verify the safety of so-called interlockings through model checking, which deals with state change and rather complex properties, usually incurring considerable computational burden (e.g., the state-space explosion problem). In contrast, we focus on static infrastructure models, and are interested in checking requirements coming from design guidelines and regulations, as usually given by railway authorities or safety certification bodies. Our goal is to automate the tedious manual work that railway engineers do when ensuring compliance with regulations, through using software that is fast enough to do verification on-the-fly, thus being able to be included in the railway design tools, much like a compiler in an IDE. In consequence, this paper describes the integration into the railway design process of formal methods for automatically extracting railway models from the CAD railway designs and for describing relevant technical regulations and expert knowledge as properties to be checked on the models. We employ a variant of Datalog and use the standardized “railway markup language” railML as basis and exchange format for the formalization. We developed a prototype tool and integrated it in industrial railway CAD software, developed under the name RailCOMPLETE®. This on-the-fly verification tool is a help for the engineer while doing the designs, and is not a replacement to other more heavy-weight software like for doing interlocking verification or capacity analysis. Our tool, through the export into railML, can be easily integrated with these other tools. We apply our tool chain in a Norwegian railway project, the upgrade of the Arna railway station.


Railway construction projects are heavy processes that integrate various fields, engineering disciplines, different companies, stakeholders, and regulatory bodies. When working out railway designs a large part of the work is repetitive, involving routine checking of consistency with regulations, writing tables, and coordinating disciplines. Many of these manual checks are simple enough to be automated. The repetition comes from the fact that even small changes in station layout and interlocking may require thorough (re-)investigation to prove that the designs remain internally consistent and still adhere to the rules and regulations of the national (and international) rail administration agencies. Automating these types of checks can eliminate a lot of the busywork required to make and change railway designs, and helps with the cross-discipline coordination by allowing engineers from one discipline to check that they are not violating other disciplines’ regulations when making their changes.

With the purpose of increasing the degree of automation, we present results on integrating formal methods into the railway design process by the following means:

  • Formalizing rules governing track and signalling layout, and interlocking.

  • Using the standardized “railway markup language” railMLFootnote 1 as representation basis and exchange format for the formalization.

  • Modeling the concepts that describe a railway design in the declarative logic programming language Datalog; and using an appropriate off-the-shelve inference engine.

  • Developing an automated generation of the formal model from the railML representation.

  • Developing a prototype tool and integrating it in existing railway CAD software.

We illustrate the logical representation of signalling principles and show how they can be implemented and solved efficiently using the Datalog style of logic programming [53]. We also show the integration with existing railway engineering workflow by using CAD models directly. This enables us to verify compliance with regulations continuously as the design process changes the station layout and interlocking. Based on railML [40] as intermediary language, our results can be easily adopted by anyone who uses this international standard.

The approach presented in this paper could be applied also to other engineering disciplines, such as catenary power lines, track works, and others, which have similar design regulations and often make use of a similar CAD environment. However, this paper uses the signalling and interlocking design process and shows how it can be improved by automation using formal methods.

The work uses as case study the software and the design used in the Arna-Fløen upgrade project,Footnote 2 a major infrastructure activity of the Norwegian railway system, with planned completion in 2020. The Arna train station is located on Northern Europe’s busiest single-track connection (between Arna and Bergen), which is being extended to a double-track connection. Thus, the train station is currently undergoing an extensive overhaul, including significant new tunnel constructions and specifically a replacement of the entire signalling and control system. The case study is part of an ongoing project in Anacon AS (now merged with Norconsult AS), a Norwegian signalling design consultancy. It is used to illustrate the approach, test the implementation, and to verify that the performance of our tool is acceptable for interactive work within the railway engineers’ CAD software.

The paper is organized as follows. Section 2 presents aspects of the railway domain relevant for this work. Section 3 presents our approach to extending CAD programs with domain-specific data, in our case for railway signalling based on the railML format. Section 4 presents our formalization of the rules and concepts of railway design as logical formulas amenable for the Datalog implementation and checking. Section 5 proposes a tool chain that extends CAD with formal representations of signalling layout and interlocking. Section 6 provides information about our tool implementation, including details about counterexample presentation and empirical evaluation using the case study. Section 7 describes our results of performing verification in an incremental manner to achieve faster running time and thus a more seamless integration with interactive design tools of the engineers. We conclude in Sect. 8 with related and future work.

The railway signalling design process

Railways require thoroughly designed control systems to ensure safety and efficient operation. The railway signals are used to direct traffic, and the signalling component layout of a train station is crucial to its traffic capacity. Another central part of a railway infrastructure, e.g., of a single railway station, is the so-called interlocking, which refers, generally speaking, to the ensemble of systems tasked to establish safe, conflict-free routes of trains through stations. A more narrow interpretation of “interlocking” are the principles, the routes, the signalling and movements of trains have to follow to ensure safe operation (cf. [42]).

The signalling design process results in a set of documents which can be categorized into (a) track and signalling component layout, (b) interlocking specification, (c) automatic train control specification. The first two categories are considered in this paper.

Track and signalling component layout

Railway construction projects rely heavily on computer aided design (CAD) tools to map out railway station/infrastructure layouts. The various disciplines within a project, such as civil works, track works, signalling, or catenary power lines, work with coordinated CAD models. These CAD models contain a major part of the work performed by engineers, and are a collaboration tool for communication between disciplines. The signalling component layout is worked out by the signalling engineers as part of the design process. Signals, train detectors, switches (also known as points), etc., are drawn using symbols in a 2D geographical CAD model. An example of a layout drawing made by Anacon AS engineers from a CAD model is given in Fig. 1.

Track layout details, which are input for the signalling design, are often given by a separate division of the railway project. At an early stage and working at a low level of detail, the signalling engineer may challenge the track layout design, and an iterative process may be initiated.

Fig. 1
figure 1

a Example of a schematic construction drawing. b Cut-out from a 2D geographical CAD model (construction drawing) of a preliminary design of the Arna station signalling

Interlocking specification

An interlocking is an interconnection of signals and switches to ensure that train movements are performed in a safe sequence [42]. Interlocking is performed electronically so that, e.g., a green light (or, more precisely, the proceed aspect) communicating the movement authority required for a train to travel through a station can only be lit by the interlocking controller under certain conditions. Conditions and state are built into the interlocking by relay-based circuitry or by computers running interlocking software. Most interlocking specifications use a route-based tabular approach, which means that a train station is divided into possible routes, which are paths that a train can take from one signal to another. These signals are called the route entry signal and route exit signal, respectively. An elementary route contains no other signals in-between. The main part of the interlocking specification is to tabulate all possible routes and set conditions for their use. Typical conditions include:

  • Switches must be positioned to guide the train to a specified route exit signal.

  • Train detectors must show that the route is free of any other trains.

  • Conflicting routes, i.e., routes which share a track element, must not be in use (Table 1).

Table 1 Example of a tabular interlocking, showing available routes and their conditions

Semantic CAD

Civil engineering construction projects, such as railway projects, make heavy use of computer-aided design tools to model the geometric aspects of the construction project and its product. The origins of CAD tools are in the computerizing of traditional drafting, which produces human-readable technical drawings that are used as plans and documentation for the construction process. Mainstream CAD tools are mainly concerned with manipulating databases of geometrical objects constituting 2D or 3D representations of spatial properties, and the production of human-readable drawings which depict these geometrical structures.

The DWG file formatFootnote 3 created for the Autodesk AutoCAD software is a de facto standard in many engineering disciplines, and this format has also been adopted by several other CAD software packages.

Grouping geometry into blocks

Grouping together several geometrical features into a single unit is in CAD terminology called “making a block”. This allows the CAD user to create models more efficiently, by reusing commonly used components.

The blocks, which may represent things such as chairs, doors, or railway signals, also create the opportunity to store higher-level information in a CAD model, other than the purely geometrical description. For example, if one uses a railway signal block to model a signal in a railway station, a program can count the number of signals in a CAD model.

This idea can be extended by adding any number of attributes to a block. For a railway signal, we can add attributes that describe, e.g., to which track it signals, along with its type, function, and direction. The CAD object database does then not only contain the geometrical objects, such as lines, curves, triangles, cubes, etc., but groups these primitives into higher-level concepts which are closer to the representation that one uses to reason about the actual working of the railway infrastructure.

With a good library of blocks (which we call a symbol library), the engineer can more efficiently build the geometric CAD models which lead to human-readable drawings, but they are also building a machine-readable model of high-level railway concepts. We call this semantic CAD. While this concept is also a part of building information modeling (BIM), BIM also includes many other concepts such as 3D visualization, time (“4D”), and cost (“5D”).

The verification of signalling and interlocking rules requires information about properties and relations between objects, e.g., which signals and signs are related to which track, and their identification, capabilities, and use. This information is better modelled by the railway-specific hierarchical object model railML [40]. In the CAD industry-standard DWG file format, each geometrical object in the database has an associated extension dictionary, where add-on programs may store any data related to the object. Our tool uses this method to store the railML fragments associated with each geometrical object or symbol, see Fig. 2 . Thus, we can compile the complete railML representation of the station from the CAD model.

Object type descriptions

It is necessary to decide which objects in the CAD model should be associated with which data types, i.e. what attributes should be stored in the symbols. (This is similar to specifying an object’s class in an object-oriented programming language.) To do this, we create an object type description which augments the symbol library with class information. Whenever the user adds a symbol, its data editor is determined by the assigned class, and vice versa: when e.g. a railML object is imported into CAD, its corresponding symbol is inserted in the graphical model.

Fig. 2
figure 2

railML integrated into a CAD database

Interlocking and train protection systems

Besides the CAD model layout, the design of a railway station’s signalling consists also of specifications for the interlocking and train protection (speed control) systems. These specifications are used to build the interlocking controllers and speed controllers, and they model the behavior of the signalling equipment and its interaction with trains. These systems are tightly linked to the station layout.

Fig. 3
figure 3

Semantic CAD document organization including interlocking specification

A formal representation of the interlocking and train protection specifications is embedded in the CAD document in a similar way as for the railML infrastructure data, using the document’s global extension dictionary. Thus, the single CAD document showing the human-readable, geographical layout of the train station also contains a machine-readable model which fully describes both the component layout and the functional specification of the interlocking and train protection systems. This allows analysis of the operational aspects of the train station directly in a familiar editable CAD model. See Fig. 3 for an overview of this architecture.

Logic programming and knowledge-base systems

We have shown how to associate semantic information with CAD symbols, but in order to automatically verify rules and regulations on this railway infrastructure model, we need a computer program which can check each property for violations with the given model as input.

A straight-forward approach to making such a program could be to create some search function on the graph implicit in the track network. This procedure should allow, for example, to find the nearest object of a given type, or to find all paths between two points. Then we would describe a checking procedure for each rule. Consider for example, the home signal regulation from Property 1, which says “A home main signal shall be placed at least 200 m in front of the first controlled, facing switch in the entry train path.”. Checking such a property can be done by iterating over tracks, locating station boundaries, starting a search function to locate the relevant facing switches, starting another search backwards to check that there is a home signal, and so on. The amount of code required to do this in a mainstream programming language can become large, and this code is often very specific to a given railway administration.

Better suited to manage the large amounts of code required for a large number of rules, is logic programming, which allows rule descriptions that are much closer to the original specifications than in a mainstream programming language.

Logic programming

Logic programming [41] is a family of programming languages based on formal logic. Logic programs are declarative, i.e., they describe properties of the solution of a problem rather than a calculation procedure for finding the solution. This separates the concerns of expressing rules about railway systems from the algorithms required to do automatic analysis. This separation allows one to systematically maintain a large set of rules, and decouple the tool implementation from the set of concepts, rules and expert knowledge that is specific to a railway administration.

We have successfully used the Datalog language [53], a subset of the more well-known Prolog language, for verifying many properties given as technical rules and expert knowledge. It allows concise formulations of railway concepts, and queries can be efficiently calculated.

Ideally, we would like the railway engineers themselves, without much programming education, to be able to create and maintain the set of rules which is used for the verification. This separation of logic and algorithm is a step in this direction, because non-IT experts can work on the rules without considering how the calculations are implemented. However, the strict formalism and subtle semantics of logic programming are still a challenge for an inexperienced programmer. Still, some parts of the maintentance work on the railway properties can be performed without deep knowledge of logic programming, for the following reasons:

  1. 1.

    The most basic concepts, such as connectedness, distances, directions, etc., rarely need to be redefined, and may be specified by an expert programmer, and then reused.

  2. 2.

    Naming or documenting the basic concepts in a way that is understandable by railway engineers allows them to use these concepts without considering the actual definitions.

  3. 3.

    Rule formulations are often so succinct that they can be understood even without knowledge of the logic programming syntax.

  4. 4.

    Modification (updating) of rules, for example following a change in regulation from the railway administration, often preserves the structure of the specification, adding only a similar clause or the change of a numeric constant.

  5. 5.

    Templates for common rule structures can be given, so that implementing some types of rules becomes a matter of specifying e.g. only object types, directions, and distances.

We do, however, concede that Datalog programming in general (specifically, at the level required for writing regulation properties from scratch) is outside the competence of a railway engineer. A higher-level domain-specific language including relevant constructs for a railway signalling design knowledge base could improve the likelihood of railway engineers being successful in creating and maintaining the regulations. Even more, this language could allow each company and each engineer to experiment with encoding different design heuristics and expert knowledge to see the effects on the verification and the design. Our planned future work (see Sect. 8.2) includes defining such a language and also on using a controlled natural language syntax to improve ease of comprehension [30].

We envision that a common rule base would be exchanged between all engineers working with a railway administration, and that the rule base would be worked out partly by software experts, partly by railway experts. Also, the rule base should be fairly constant, like the regulations, requiring an update frequency of perhaps once per year.


Declarative logic programming is a programming language paradigm which allows clean separation of logic (meaning) and computation (algorithm). This section gives a short overview of Datalog concepts. See [1, 41, 53] for more details. In its most basic form Datalog is a database query, as in the SQL language, over a finite set of atoms which can be combined using conjunctive queries, i.e. expressions in the fragment of first-order logic which includes only conjunctions and existential quantification.

Conjunctive queries alone, however, cannot express the properties needed to verify railway signalling. For example, given the layout of the station with tracks represented as edges between signalling equipment nodes, graph reachability queries are required to verify some of the rules. This corresponds to computing the transitive closure of the graph adjacency relation, which is not expressible in first-order logic [28, Chap. 3]. Extending conjunctive queries by allowing recursive predicate definitions is a common way to mitigate the above problem while preserving decidability and polynomial time complexity.

The Datalog language is a fragment of first-order logic extended with recursive predicate definitions, which are evaluated by computing least fixed points. We define the Datalog language as follows: Terms are either constants (atoms) or variables. Literals consist of a predicate p with a certain arity n, along with terms corresponding to the predicate arguments, forming an expression like \(p({\overrightarrow{a}})\), where \({\overrightarrow{a}} = (a_1,a_2,\ldots ,a_n)\). Clauses consist of a head literal and one or more body literals, such that all variables in the head also appear in the body. Clauses are written as

$$\begin{aligned} r_0({\overrightarrow{x}})\ \,\text { :-- }\,\ \exists {\overrightarrow{y}} : r_1({\overrightarrow{x_{1}}}, {\overrightarrow{y_{1}}}),r_2({\overrightarrow{x_{2}}}, {\overrightarrow{y_{2}}}),\ldots ,r_k({\overrightarrow{x_{k}}}, {\overrightarrow{y_{k}}}), \end{aligned}$$

with \(\bigcup _{1\le i \le k}{\overrightarrow{x_{i}}} = {\overrightarrow{x}}\) and \(\bigcup _{1\le i \le k}{\overrightarrow{y_{i}}} = {\overrightarrow{y}}\). Datalog uses the Prolog convention of interpreting identifiers starting with a capital letter as variables, and other identifiers as constants, e.g., the clause

$${\mathrm {a}}(X,Y) \,\text { :-- }\,{\mathrm {b}}(X,Z),~{\mathrm {c}}(Z,Y)$$

has the meaning of

$$\begin{aligned} \forall x,y : \left( \left( \exists z : \left( b(x,z) \wedge c(z,y) \right) \right) \rightarrow a(x,y) \right) . \end{aligned}$$

Clauses without body, which cannot then contain any variables, are called facts, those with one or more literals in the body are called rules. No nesting of literals is allowed. However, recursive definitions of predicates are possible. For example, let edge(ab) be a graph edge relation between vertices a and b. Graph searches can now be encoded by making a transitive closure over the edge relation:

In the railway domain, this can be used to define the connected predicate, which defines whether two objects are connected by railway tracks:

Here, the connection predicate contains switches and other connection types. Further details of relevant predicates are given in the sections below.

The Datalog logic in its simplest form does not contain any notion of negation, which is often crucial for practical applications. A common feature of Datalog implementations is to extend the logic with negation using negation as failure semantics. This means that negation of predicates in rules is allowed with the interpretation that when the satisfiability procedure cannot find a model, the statement is false. To ensure termination and unique solutions, the negation of predicates must have a stratification, i.e. the dependency graph of negated predicates must have a topological ordering. This means that whenever a rule with a negated predicate is evaluated, the negated predicate must already be completely evaluated, so that the absense of a term from the predicate can be known definitely (see [53, Chap. 3] for details). In practice, this requirement is often easy to fulfill.

Datalog is sufficiently expressive to describe static rules of signalling layout topology and interlocking. For geometrical properties, it is necessary to take sums and differences of lengths, which requires extending Datalog with arithmetic operations. For our prototype tool, we have used XSB Prolog as the logic programming system, which supports both Datalog with negation-as-failure, and arithmetic. A more expressive language is required to cover all aspects of railway design, e.g. capacity analysis and software verification, but for the properties in the scope of this paper, a concise, restricted language which ensures termination and short running times has the advantage of allowing tight integration with the existing engineering workflow.

Knowledge-base system

With Datalog as specification language, we build a knowledge-base system to perform the verification. A knowledge-base system consists of a set of facts and rules, along with an inference engine which answers queries by applying logical inference rules. For an introduction to knowledge-base systems in general, see [53, Chap. 3] or [46, Chap. 8 and 12]. We give here an overview of how we encode railway signalling properties as Datalog predicates, which in turn may be automatically checked for consistency. In our verification tool, we organize our knowledge base in the following manner:

  1. 1.

    Input documents Predicate representation of input document, i.e. track layout and interlocking, are represented as facts which are converted from the railML representation stored and maintained in the CAD database by our CAD plug-in program.

  2. 2.

    Derived concepts Predicate representation of derived concept rules, such as object properties, topological properties, and calculation of distances. A library of general railway concepts and administration-specific concepts and definitions are kept in a rule base which is re-used between projects.

  3. 3.

    Technical rules and expert knowledge Predicate representation of technical rules or expert knowledge as logic programming rules, which encode the administration-specific rules and expert knowledge that is checked and errors reported to the user by the verification tool.

  4. 4.

    Inference engine A Datalog evaluation engine is used as inference engine; in our case the XSB Prolog tabled logic programming system [52].

Each of these aspects are described in more detail below.

Input documents

Each of the XML elements and attributes is translated into a corresponding predicate. An example of translating a railML switch element into predicate representation is given below.

figure a

Track and signalling objects layout in the railML format

Given a complete railML infrastructure document, we consider the set of XML elements in it that correspond to identifiable objects (this is the set of elements which inherit properties from the type tElementWithIDAndName). The set of all IDs which are assigned to XML elements form the finite domain of constants on which we base our predicates (IDs are assumed unique in railML).

$$\begin{aligned} {{\mathrm {Atoms}}} := \left\{ a \mid {{\mathrm {element}}}.{{\mathtt {ID}}} = a \right\} . \end{aligned}$$

We denote a railML element with \(\textit{ID}=a\) as \({\mathrm {element}}_a\). All other data associated with an element is expressed as predicates with its identifying atom as one of the arguments, most notably the following:

  • Element type (also called class in railML):

    $$\begin{aligned} \begin{aligned} {\mathrm {track}}(a)&\leftarrow {\mathrm {element}}_a \text { is of type } {\mathtt {track}}, \\ {\mathrm {signal}}(a)&\leftarrow {\mathrm {element}}_a \text { is of type } {\mathtt {signal}}, \\ {\mathrm {switch}}(a)&\leftarrow {\mathrm {element}}_a \text { is of type } {\mathtt {switch}}. \\ \end{aligned} \end{aligned}$$
  • Element name:

    $$\begin{aligned} {\mathrm {name}}(a,n) \leftarrow ({\mathrm {element}}_a.{\mathtt {name}} = n). \end{aligned}$$
  • Position and absolute position (elements inheriting from tPlacedElement):

    $$\begin{aligned} {\mathrm {pos}}(a,p)&\leftarrow ({\mathrm {element}}_a.{\mathtt {pos}} = p),\quad a \in {\mathrm {Atoms}}, p \in \mathbb {R},\\ {\mathrm {absPos}}(a,p)&\leftarrow ({\mathrm {element}}_a.{\mathtt {absPos}} = p),\quad a \in {\mathrm {Atoms}}, p \in \mathbb {R}. \end{aligned}$$

    The position pos of an object, as used in the railML format, is the distance from the start of the track object to which it belongs. The tracks in railML have a beginning and an end, which implies that one of the travel directions is seen as the positive direction. This is related to the definition of direction below.

  • Geographical coordinates (for elements inheriting from tPlacedElement):

    $$\begin{aligned} {\mathrm {geoCoords}}(a,q) \leftarrow ({\mathrm {element}}_a.{\mathtt {geoCoords}} = q),\quad a \in {\mathrm {Atoms}}, q \in \mathbb {R}^3. \end{aligned}$$
  • Direction (for elements inheriting from tOrientedElement):

    $$\begin{aligned} {\mathrm {dir}}(a,d) \leftarrow ({\mathrm {element}}_a.{\mathtt {dir}} = d),\quad a \in {\mathrm {Atoms}}, d \in {\mathrm {Direction}}, \end{aligned}$$

    where \({\mathrm {Direction}} = \left\{ up, down, both, unknown \right\} \), indicating whether the object is visible or functional in only one of the two possible travel directions, or both.

    The unknown value for the direction stems, in most contexts, from inconsistent or incomplete data. Rules which disallow unknown direction can be used to indicate to the user that their input document is invalid. For other uses of direction, such as in the definition of the distance predicate below, we use instead the set of strict directions, as defined by railML: \({\mathrm {StrictDirection}} = \left\{ up, down\right\} \).

    The up and down directions are defined by the positioning system of the track (see the position predicates above). Objects in the up direction are relevant when the train is travelling in the direction of increasing pos, as defined above, which is determined by a track’s beginning and end nodes, and correspondingly, the down direction is the direction of decreasing track position. These directions are typically related to some origin point given by the infrastructure manager organization. For example, for Norwegian railways, the tunnel opening on track 7 of Oslo Central Station defines the origin point, and absolute positions increase away from this point.

  • Signal properties (for elements of type tSignal):

    $$\begin{aligned}&{\mathrm {signalType}}(a,t) \leftarrow ({\mathrm {element}}_a.{\mathtt {type}}=t), t\in \left\{ \text {main, distant, shunting, combined} \right\} ,\\&{\mathrm {signalFunction}}(a,f) \leftarrow ({\mathrm {element}}_a.{\mathtt {function}} = f),\\&\phantom {{\mathrm {signalFunction}}(a,f) \leftarrow } a \in {\mathrm {Atoms}}, f \in \left\{ \text {home, intermediate, exit, blocking} \right\} . \end{aligned}$$

    Consistency axioms would impose that predicates signalType and signalFunction be applied only to signal elements:

    $$\begin{aligned}&{\mathrm {signalType}}(a,t) \Rightarrow signal(a),\\&{\mathrm {signalFunction}}(a,f) \Rightarrow signal(a). \end{aligned}$$

These are only a few examples of predicates that are extracted from the railML document. The translation from railML to predicate form works on the XML structure, translating element names into unary predicates and properties into binary predicates, treating only the ID property specially, by using it as a Datalog term to identify an object. The complete structure of railML as such is carried over directly to the logic programming environment.

The switch element is the object which connects tracks with each other and creates the branching of paths, see Fig. 4. A switch belongs to a single track, but contains connection sub-elements which point to other connection elements, which are in turn contained in switches, crossings or track ends. For connections, we have the following predicates:

  • Connection element and reference:

    $$\begin{aligned} {\mathrm {connection}}(a)&\leftarrow {\mathrm {element}}_a \text { is of type } {\mathtt {connection}},\\ {\mathrm {connection}}(a,b)&\leftarrow ({\mathrm {element}}_a.{\mathtt {ref}} = b). \end{aligned}$$
  • Connection course (also known as switch position) and orientation:

    $$\begin{aligned} {\mathrm {connectionCourse}}(a,c)&\leftarrow ({\mathrm {element}}_a.{\mathtt {course}} = c), c\in \left\{ \text {left, straight, right} \right\} \\ {\mathrm {connectionOrientation}}(a,o)&\leftarrow ({\mathrm {element}}_a.{\mathtt {orientation}} = o),\\&a \in {\mathrm {Atoms}}, o \in \left\{ \text {outgoing, incoming} \right\} . \end{aligned}$$
Fig. 4
figure 4

Switches give rise to branching paths

Connection course (switch position) is often represented as a binary value (normal/reverse) in the implementation of a control system, but we keep the railML termonology here, and also allow for three-way switches.

To encode the hierarchical structure of the railML document, a separate predicate encoding the parent/child relationship is added.

This is required because the predicate representation does not implicitly contain the hierarchy of the XML representation, where elements are declared inside other elements.

  • Object belongs to (e.g. a is a signal belonging to track b):

    $$\begin{aligned} \begin{aligned} {\mathrm {belongsTo}}(a,b)&\leftarrow b\text { is the closest XML ancestor of } a\text { whose element}\\&\quad \text {type inherits from }{\mathtt {tElementWithIDAndName}}. \end{aligned} \end{aligned}$$


An XML schema for tabular interlocking specifications is described in [6], and this format is used here, anticipating that it will become part of the railML standard schema in the future. We give some examples of how this schema is translated into predicate form:

  • Train route with given direction d, start point a, and end point b (\(a,b \in {\mathrm {Atoms}}\), \(d \in {\mathrm {Direction}}\)):

    $$\begin{aligned} \begin{aligned} {\mathrm {trainRoute}}(t)&\leftarrow {\mathrm {element}}_t \text { is of type } {\mathtt {route}} \\ {\mathrm {start}}(t,a)&\leftarrow ({\mathrm {element}}_t.{\mathtt {start}} = a)\\ {\mathrm {end}}(t,b)&\leftarrow ({\mathrm {element}}_t.{\mathtt {end}} = b) \\ \end{aligned} \end{aligned}$$
  • Conditions on detection section free (a) and switch position (sp):

    $$\begin{aligned} \begin{aligned} {\mathrm {detectionSection}}{\mathrm {Condition}}(t,a) \leftarrow&(a \in {\mathrm {element}}_t.{\mathtt {sectionConditions}}), \\ {\mathrm {switchPositionCondition}}(t,s,p) \leftarrow&((s,p) \in {\mathrm {element}}_t.{\mathtt {switchConditions}}). \end{aligned} \end{aligned}$$

Derived concepts representation

Derived concepts are properties of the railway model which can be defined independently of the specific station. A library of these predicates is needed to allow concise expression of the rules to be checked.

Object properties

Derived object properties are properties related to specific object types which are not explicitly represented in the layout description, such as whether a switch is facing in a given direction, i.e. if the path will branch when you pass it:

  • Switch facing or trailing (\(a \in {\mathrm {Atoms}}\), \(d \in {\mathrm {Direction}}\)):

    $$\begin{aligned} {\mathrm {switchFacing}}(a,d)&\leftarrow \exists c,o : {\mathrm {switch}}(a) \wedge {\mathrm {switchConnection}}(a,c) \wedge \\&{\textit{switchOrientation}}(c,o) \wedge {\textit{orientationDirection}}(o,d). \\ {\mathrm {switchTrailing}}(a,d)&\leftarrow \lnot {\mathrm {switchFacing}}(a,d) \end{aligned}$$

Topological and geometric layout properties

Predicates describing the topological configuration of signalling objects and the train travel distance between them are described by predicates for track connection (predicate \({\mathrm {connected}}(a,b)\)), directed connection (predicate \({\mathrm {following}}(a,b,d)\)), distance (predicate \({\mathrm {distance}}(a,b,d,l)\)), etc. The track connection predicate is defined as:

  • There is a track connection between object a and b (\(a,b \in {\mathrm {Atoms}}\)):

    $$\begin{aligned} \begin{aligned} {\mathrm {directlyConnected}}(a,b) \leftarrow \exists t :&{\mathrm {track}}(t) \wedge {\mathrm {belongsTo}}(a, t) \wedge {\mathrm {belongsTo}}(b,t), \\ {\mathrm {connected}}(a,b) \leftarrow&{\mathrm {directlyConnected}}(a,b) \vee ( \exists c_1,c_2 : {\mathrm {connection}}(c_1,c_2) \\&\wedge {\mathrm {directlyConnected}}(a,c_1) \wedge {\mathrm {connected}}(c_2, b) ). \end{aligned} \end{aligned}$$
  • There is a directed connection between object a and b (\(a,b \in {\mathrm {Atoms}}\), \(d \in {\mathrm {StrictDirection}}\), \(p_a, p_b \in \mathbb {R}\)):

    $$\begin{aligned} \begin{aligned} {\mathrm {directlyFollowing}}(a,b,d)&\leftarrow {\mathrm {directlyConnected}}(a,b) \wedge \\&\quad {\mathrm {position}}(a,p_a) \wedge {\mathrm {position}}(b, p_b) \wedge \\&\quad ((d={\mathrm {up}} \wedge p_a < p_b) \vee (d={\mathrm {down}} \wedge p_a > p_b)) \\ {\mathrm {following}}(a,b,d)&\leftarrow {\mathrm {directlyFollowing}}(a,b,d) \vee \\&\quad \exists c_1,c_2 : {\mathrm {connection}}(c_1, c_2) \wedge {\mathrm {directlyFollowing}}(a,c_1,d) \\&\quad \wedge {\mathrm {following}}(c_2,b,d) \end{aligned} \end{aligned}$$
  • The distance (along track) in a given direction between object a and b (\(a,b \in {\mathrm {Atoms}}\), \(d \in {\mathrm {StrictDirection}}\), \(p_a, p_b, l \in \mathbb {R}\)):

    $$\begin{aligned} \begin{aligned} {\mathrm {directDistance}}(a,b,d,l)&\leftarrow {\mathrm {directlyFollowing}}(a,b,d) \wedge \\&\quad {\mathrm {position}}(a, p_a) \wedge {\mathrm {position}}(b, p_b) \\&\quad \wedge l = |p_b - p_a|\\ {\mathrm {distance}}(a,b,d,l)&\leftarrow {\mathrm {directDistance}}(a,b,d,l) \vee \\&\quad \exists c_1,c_2,l_1,l_2 : {\mathrm {connection}}(c_1, c_2) \\&\quad \wedge {\mathrm {directDistance}}(a,c_1,d,l_1) \\&\quad \wedge {\mathrm {distance}}(c_2,b,d,l_2) \wedge l = l_1 + l_2 \end{aligned} \end{aligned}$$

    The distance predicate represents a possible train movement and the corresponding traveling distance. This means that the distances should fulfill the following consistency axiom: Consider the solutions to \({\mathrm {distance}}(a,b,d_1,l_1) \wedge {\mathrm {distance}}(b,a,d_2,l_2)\). The set of distances \(l_1\) is equal to the set of distances \(l_2\), and the direction \(d_1\) is the opposite direction of \(d_2\).

  • Object is located between a and b (\(a,x,b \in {\mathrm {Atoms}}\), \(d \in {\mathrm {StrictDirection}}\)):

    $$\begin{aligned}&{\mathrm {between}}(a,x,b,d) \leftarrow {\mathrm {following}}(a,x,d) \wedge {\mathrm {following}}(x,b,d)\\&{\mathrm {between}}(a,x,b) \leftarrow \exists d : {\mathrm {between}}(a,x,b,d) \end{aligned}$$
  • A path between a and b intersects a path between c and d (\(a,b,c,d \in {\mathrm {Atoms}}\)), meaning that some part of any path between a and b coincides with some part of any path between c and d:

    $$\begin{aligned} {\mathrm {intersect}}(a,b,c,d) \leftarrow \exists e : {\mathrm {between}}(a,e,b) \wedge {\mathrm {between}}(c,e,d) \end{aligned}$$

Interlocking properties

Predicates such as \({\mathrm {existsPathWithoutSignal}}(a,b)\) which defines the method for finding elementary routes, and \({\mathrm {existsPathWithDetector}}(a,b)\) for finding adjacent train detectors, will be used as building blocks for the interlocking rules. We show here a recursive rule used for finding elementary routes:

  • Signals a and b have a path between them without any other signals in between:

    $$\begin{aligned} \begin{aligned} {\mathrm {existsPath}}&{\mathrm {WithoutSignal}}(a,b,d) \leftarrow {\mathrm {following}}(a,b,d) \wedge \\&\quad (\lnot (\exists x : {\mathrm {signal}}(x) \wedge {\mathrm {between}}(a,x,b)) \vee \\&\quad (\exists x: {\mathrm {between}}(a,x,b) \wedge {\mathrm {existsPathWithoutSignal}}(a,x,d) \wedge \\&\quad {\mathrm {existsPathWithoutSignal}}(x,b,d)). \end{aligned} \end{aligned}$$

Rule violations representation

With the input documents represented as facts, and a library of derived concepts, it remains to define the technical rules to be checked. All technical rules presented herein are based on the Norwegian infrastructure manager’s regulations.Footnote 4

The goal of the consistency checking is to confirm that no inconsistencies exist, in which case no further information is required, or to find inconsistencies and present them in a way that allows the user to understand the error and to adjust their design accordingly. Rules are therefore expressed negatively, as rule violations, so that a query corresponding to the rule is empty whenever the rule is consistent with the design, or the query contains counterexamples to the rule when they exist.

Some examples of technical rules representing conditions of the railway station layout are given below.

Property 1

(Layout: Home signal) A home main signal shall be placed at least 200.0 m in front of the first controlled, facing switch in the entry train path.

figure b

Property 1 may be represented in the following way:

$$\begin{aligned} \begin{aligned} {\mathrm {isFirstFacingSwitch}}(b,s)&\leftarrow {\mathrm {stationBoundary}}(b) \wedge {\mathrm {facingSwitch}}(s) \wedge \\&\quad \lnot (\exists x : {\mathrm {facingSwitch}}(x) \wedge {\mathrm {between}}(b,x,s)),\\ \end{aligned} \end{aligned}$$

The stationBoundary predicate contains objects which represent the boundaries of a station model. For models which contain a single station, which is the common use case for our CAD prototype application, the stationBoundary can be taken to be the model boundary. Note that the station boundary is usually not the same as the station border, which is defined by regulations.

$$\begin{aligned} \begin{aligned} {\mathrm {ruleViolation}}_{1}(b, s)&\leftarrow {\mathrm {isFirstFacingSwitch}}(b,s) \wedge \\&\quad ( \lnot (\exists x : {\mathrm {signalFunction}}(x,{\mathrm {home}}) \wedge {\mathrm {between}}(b,x,s) ) \vee \\&\quad ( \exists x, d,l : {\mathrm {signalFunction}}(x,{\mathrm {home}}) \wedge \\&\quad \wedge {\mathrm {distance}}(x,s,d,l)\wedge l < 200.0).\\ \end{aligned} \end{aligned}$$

Checking for rule violations can be expressed as:

$$\begin{aligned} \exists b,s : {\mathrm {ruleViolation}}_{1}(b,s), \end{aligned}$$

which in Datalog query format becomes ruleViolation 1 (B,S)?.

Property 2

(Layout: Minimum detection section length) No train detection section shall be shorter than 21.0 m. I.e., no train detectors should be separated with less than 21.0 m driving distance.

This property is represented as follows:

$$\begin{aligned} \begin{aligned} {\mathrm {ruleViolation}}_{1}(a,b) \leftarrow&\exists d,l : {\mathrm {trainDetector}}(a) \wedge {\mathrm {trainDetector}}(b) \wedge \\&{\mathrm {distance}}(a,b,d,l) \wedge l < 21.0. \end{aligned} \end{aligned}$$

Property 3

(Layout: Exit main signal) An exit main signal shall be used to give the movement authority to exit a station.

This property can be elaborated into the following rules:

  • No path should have more than one exit signal:

    $$\begin{aligned} \begin{aligned} {\mathrm {ruleViolation}}_{1}(s) \leftarrow&\exists d : {\mathrm {signalType}}(s,{\mathrm {exit}}) \wedge {\mathrm {following}}(s,s_o,d) \wedge \\&{\mathrm {signalType}}(s_0,{\mathrm {exit}}).\\ \end{aligned} \end{aligned}$$
  • Station boundaries should be preceded by an exit signal:

    $$\begin{aligned} \begin{aligned} {\mathrm {exitSignalBefore}}(x,d) \leftarrow&\exists s : {\mathrm {signalType}}(s, {\mathrm {exit}}) \wedge {\mathrm {following}}(s,x,d)\\ {\mathrm {ruleViolation}}_{1}(b) \leftarrow&\exists d : {\mathrm {stationBoundary}}(b) \wedge \lnot {\mathrm {exitSignalBefore}}(b,d). \\ \end{aligned} \end{aligned}$$

A basic property of tabular interlockings is that each consecutive pair of main signals normally has an elementary train route associated with it, i.e.:

Property 4

(Interlocking: Elementary routes) A pair of consecutive main signals should be present as a route in the interlocking.

This can be represented as follows:

$$\begin{aligned}&\begin{aligned} {\mathrm {defaultRoute}}(a,b,d)&\leftarrow {\mathrm {signalType}}(a,{\mathrm {main}}) \wedge {\mathrm {signalType}}(b,{\mathrm {main}}) \wedge \\&\quad {\mathrm {direction}}(a,d) \wedge {\mathrm {direction}}(b,d) \wedge \\&\quad {\mathrm {following}}(a,b,d) \wedge {\mathrm {existsPathWithoutSignal}}(a,b,d), \end{aligned}\\&\begin{aligned} {\mathrm {rule}}&{\mathrm {Violation}}_{1}(a,b,d) \leftarrow {\mathrm {defaultRoute}}(a,b,d) \wedge \\&\lnot (\exists r: {\mathrm {trainRoute}}(r) \wedge {\mathrm {trainRouteStart}}(r,a) \wedge {\mathrm {trainRouteEnd}}(r,b)). \end{aligned} \end{aligned}$$

This type of rule is not absolutely required for a railway signalling design to be valid and safe. Some rules are hard constraints, where violations may be considered to be errors in the design, while other rules are soft constraints, where violations may suggest that further investigation is recommended. This is relevant for the counterexample presentation section below.

Property 5

(Interlocking: Track clear on route) Each pair of adjacent train detectors defines a track detection section. For any track detection sections intersecting the route path, there shall exist a corresponding condition on the activation of the route.

figure c

Property 5 can be represented as follows:

$$\begin{aligned} \begin{aligned} {\mathrm {existsPathWithDetector}}(a,b) \leftarrow&\exists d : {\mathrm {following}}(a,b,d) \wedge {\mathrm {trainDetector}}(x) \wedge \\&{\mathrm {between}}(a,x,b). \\ {\mathrm {adjacentDetectors}}(a,b) \leftarrow&{\mathrm {trainDetector}}(a) \wedge {\mathrm {trainDetector}}(b) \wedge \\&\lnot {\mathrm {existsPathWithDetector}}(a,b), \\ {\mathrm {detectionSection}}&{\mathrm {IntersectsRoute}}(r,d_a,d_b) \leftarrow {\mathrm {trainRoute}}(r) \wedge \\&{\mathrm {start}}(r,s_a) \wedge {\mathrm {end}}(r,s_b) \wedge \\&{\mathrm {adjacentDetectors}}(d_a,d_b) \wedge {\mathrm {intersect}}(s_a,s_b,d_a,d_b), \\ {\mathrm {detectionSection}}&{\mathrm {Condition}}(r,d_a,d_b) \leftarrow {\mathrm {detectionSectionCondition}}(c) \wedge \\&{\mathrm {belongsTo}}(c,r) \wedge {\mathrm {belongsTo}}(d_a,c) \wedge {\mathrm {belongsTo}}(d_b,c). \\ {\mathrm {ruleViolation_{5}}}&(r,d_a,d_b) \leftarrow \\&{\mathrm {detectionSectionIntersectsRoute}}(r,d_a,d_b) \wedge \\&\lnot {\mathrm {detectionSectionCondition}}(r,d_a,d_b). \\ \end{aligned} \end{aligned}$$

The train detectors in the trainDetectors predicate are in our prototype usually axle counters, as these are the preferred train detection method for newer construction projects. The most common alternative to axle counters are track circuits, which are delimited by isolated joints in the tracks. The property encoding above only assumes that detection section delimiters can be used to derive detection sections, and can thus be adapted to layouts using track circuits.

Property 6

(Interlocking: Flank protection) A train route shall have flank protection.

For each switch in the route path and its associated position, the paths starting in the opposite switch position defines the flank. Each flank path is terminated by the first flank protection object encountered along the path.

The following objects can give flank protection:

  1. 1.

    Main signals, by showing the stop aspect.

  2. 2.

    Shunting signals, by showing the stop aspect.

  3. 3.

    Switches, by being controlled and locked in the position which does not lead into the path to be protected.

  4. 4.

    Derailers, by being controlled and locked in the derailing state.

An example situation is shown in Fig. 5. While the indicated route is active (A to B), switch X needs flank protection for its left track. Flank protection is given by setting switch Y in right position and setting signal C to stop.

Fig. 5
figure 5

The dashed path starting in switch X must be terminated in all branches by a valid flank protection object, in this case switch Y and signal C. (Property 6)

Property 6 can be elaborated into the following rules:

  • All flank protection objects should be eligible flank protection objects, i.e. they should be in the list of possible flank protection objects, and have the correct orientation (the flankElement predicate contains the interlocking facts):

    $$\begin{aligned} {\mathrm {flankProtectionObject}}(a,b,d) \leftarrow&(({\mathrm {signalType}}(a,{\mathrm {main}}) \wedge {\mathrm {dir}}(a,d) ) \vee \\&({\mathrm {signalType}}(a,{\mathrm {shunting}}) \wedge {\mathrm {dir}}(a,d) ) \vee \\&{\mathrm {switchFacing}}(a,d) \vee \\&{\mathrm {derailer}}(a)) \wedge {\mathrm {following}}(a,b,d) . \\ {\mathrm {flankProtection}}{\mathrm {Required}}(r,x,d)&\leftarrow {\mathrm {trainRoute}}(r) \wedge {\mathrm {start}}(r,s_a) \wedge \\&{\mathrm {end}}(r,s_b) \wedge {\mathrm {switchOrientation}}(x,o) \wedge \\&{\mathrm {between}}(s_a,x,s_b) \wedge \\&{\mathrm {orientationDirection}}(o,o_d) \wedge \\&{\mathrm {oppositeDirection}}(o_d,d).\\ {\mathrm {flankProtection}}(r,e) \leftarrow&{\mathrm {flankProtectionRequired}}(r,x,d) \wedge \\&{\mathrm {flankProtectionObject}}(e,x,d).\\ {\mathrm {ruleViolation_{6}}}(r,e) \leftarrow&{\mathrm {flankElement}}(r,e) \wedge \\&\lnot {\mathrm {flankProtection}}(r,e). \\ \end{aligned}$$
  • There should be no path from a model/station boundary to the given switch, in the given direction, that does not pass a flank protection object for the route:

    $$\begin{aligned} {\mathrm {existsPath}}&{\mathrm {WithFlankProtection}}(r,b,x,d) \leftarrow \\&{\mathrm {flankElement}}(r,e) \wedge {\mathrm {flankProtectionElement}}(e,x,d) \wedge \\&{\mathrm {between}}(b,e,x). \\ {\mathrm {existsPath}}&{\mathrm {WithoutFlankProtection}}(r,b,x,d) \leftarrow \\&\lnot {\mathrm {existsPathWithFlankProtection}}(r,b,x,d) \vee \\&( {\mathrm {between}}(b,y,x) \wedge \lnot {\mathrm {flankProtectionElement}}(e,y,d) \wedge \\&{\mathrm {existsPathWithoutFlankProtection}}(r,b,y,d) \wedge \\&{\mathrm {existsPathWithoutFlankProtection}}(r,y,x,d) ).\\ {\mathrm {ruleViolation_{6}}}&(r,b,x) \leftarrow {\mathrm {stationBoundary}}(b) \wedge \\&{\mathrm {flankProtectionRequired}}(r,x,d) \wedge {\mathrm {following}}(b,x,d) \wedge \\&{\mathrm {existsPathWithoutFlankProtection}}(r,b,x,d). \\ \end{aligned}$$

Proposed railway signalling design tool chain

Next we describe the tool chain that we propose for automating the current manual tasks involved in the design of railway infrastructures (more details can be found in [31]). In particular, we are focused on integrating and automating those simple, yet tedious, rules and conditions usually used to maintain some form of consistency of the railway, and have these checks done automatically. Whenever the design is changed by an engineer working with the CAD program, our verification procedure would help, behind the scenes, verifying any small changes in the model and the output documents. Violations would either be automatically corrected, if possible, or highlighted to the engineer. Thus, we are focusing on solutions with small computational overhead when working with CAD tools (running on standard computers).

Figure 6 shows the overall tool chain. The software allows checking of rules and regulations of static infrastructure (described in this paper) inside the CAD environment, while more comprehensive verification and quality assurance can be performed by special-purpose software for other design and analysis activities.

Fig. 6
figure 6

Railway design tool chain. The CAD program box shows features which are directly accessible at design time inside the CAD program, while the export creates machine-readable (or human-readable) documents which may be further analyzed and verified by external software (shown in dashed boxes)

Generally, analysis and verification tools for railway signalling designs can have complex inputs, they must account for a large variety of situations, and they usually require long running times. Therefore, we limit the verification inside the design environment to static rules and expert knowledge, as these rules require less dynamic information (timetables, rolling stock, etc.) and less computational effort, while still offering valuable insights. This situation may be compared to the tool chain for writing computer programs. Static analysis can be used at the detailed design stage (writing the code), but can only verify a limited set of properties. It cannot fully replace testing, simulation and other types of analysis, and must as such be seen as a part of a larger tool chain.

Other tools, that are external to the CAD environment, may be used for these types of analysis, which are less automated or require heavier computation, such as:

  • Code generation and verification for interlockings is possible e.g. through the formal verification framework of Prover Technology.Footnote 5

    Railway infrastructure topology, signalling objects, and interlocking specifications should be automatically transferred to a code generation and verification tool to help automate interlocking implementation. The transfer of data from the CAD design model to interlocking code generation tools is possible by using standardized formats such as railML, which in the future will also include an interlocking specification schema [6].

  • Capacity analysis and timetabling can be performed using e.g. OpenTrack,Footnote 6 LUKS,Footnote 7 or Treno.Footnote 8

    The main export target for our use case was OpenTrack, which is a simulation tool that allows stochastic capacity analysis, running time analysis, and other types of analyses. By transferring data directly from a CAD model, such analyses can be performed at an early stage in the design process, greatly increasing the possibility for design decisions to be affected by capacity analysis. This allows a more agile and dynamic design process, so that the end goals of the railway administration can be met, and costs of re-designing and re-building can be minimized.

  • Building information modeling (BIM), including activities such as life-cycle information management and 3D viewing, is already well integrated with CAD, and can be seen as an extension of CAD.

    The object type definitions described in Sect. 3 may be used to associate 3D models to symbols in the 2D geographical layout. Semantic information can then be preserved when transferring information between 2D and 3D representations. 3D tools for design and presentation are now becoming widely used on new railway projects.Footnote 9

Tool implementation

In this section we describe the main aspects of our tool, which implements the verification and the integration into the CAD program, as described in Fig. 6.

The XSB Prolog interpreter [52] was used as a back-end for the implementation as it offers tabled predicates which have the same characteristics as Datalog programs, while still allowing general Prolog expressions such as arithmetic operations.

The translation from railML to Datalog facts assumes that the document is valid railML, which may be checked with general XML schema validators, or a specialized railML validator.

Counterexample presentation

When rule violations are found, the railway engineer will benefit from information about the following:

  • Which rule was violated (textual message containing a reference to the source of the rule or a justification in the case of expert knowledge rules).

  • Where the rule was violated (identity of objects involved).

Also, classification of rules based on e.g. discipline and severity may be useful in many cases. In the rule databases, this may be accomplished through the use of structured comments, similar to the common practice of including structured documentation in computer programs, such as JavaDoc (see Fig. 7 for an example of how we do this). A program parses the structured comments and forwards corresponding queries to the logic programming solver. Any violations returned are associated with the information in the comments, so that the combination can be used to present a helpful message to the user. We implemented a prototype CAD add-on program for Autodesk AutoCAD (see Fig. 8 for a screen-shot).

Fig. 7
figure 7

Structured comments on rule violation expression

Fig. 8
figure 8

Counterexample presentation within an interactive CAD environment

Case study results

The rules concerning signalling layout and interlocking from Jernbaneverket Footnote 10 described above have been checked against the model (i.e., railML representation) of the Arna-Fløen project, which is an ongoing design project in Anacon AS (now merged with Norconsult AS). Each object was associated with one or more construction phases, which we call phase A and phase B, which also corresponds to two operational phases. The model that was used for the work with the Arna station (phase A and B combined) included 25 switches, 55 connections, 74 train detectors, and 74 signals. The interlocking consisted of 23 and 42 elementary routes in operational phase A and B respectively.

The Arna station design project and the corresponding CAD model has been in progress since 2013, and the method of integrating railML fragments into the CAD database, as described in Sect. 5, has been in use for more than one year. Engineers working on this model are now routinely adding the required railML properties to the signalling components as part of their CAD modelling process.

This allowed a fully automated transfer of the railML station description to the verification tool. Several simplified models were made also for testing the correct functioning of the concept predicates and rule violation predicates.

The rule collection consisted of 37 derived concepts, 5 consistency predicates, and 8 technical predicates. Running times for the verification procedure can be found in Table 2.

Table 2 Case study size and running times on a standard laptop (Intel Core i7-5500U CPU, 8 GB RAM)

The tight integration into the CAD program and, as such, into the engineer’s design process, creates the demand for fast re-evaluation of all conclusions upon small changes to the railway designs.

Usually, engineers start with an empty or draft design and add/change one object at a time. The performance figures presented in Table 2 show that the current implementation is well acceptable for “one-shot” validation even for realistic designs with running times in the range of seconds. However, it is not fast enough to smoothly and transparently be integrated such that it can automatically rerun the complete verification for each small change. Running times below one second can change the user’s perception of the tool from being a separate verification process to a continuous background check. This level of performance requires other measures to be taken, especially when considering that station models can be larger than our case study, and that the regulations rule base would need to grow larger to become more useful.

An alternative approach that promises to be more efficient is incremental verification: instead of solving logic programs from scratch for each verification run, it tries to materialize all consequences of the base facts and then maintains this view under fact updates. Incremental verification is further discussed in Sect. 7 below.

Incremental verification

While the static infrastructure verification process as developed so far in this text certainly can improve on the current practice of railway signalling design as it is, the full potential of a “light-weight” verification is still unused because of the perceived separation of design activity and verification activity. A verification tool which runs invisibly alongside the design, giving feedback on the current state of the design at any time could have a higher impact on the design process.

The common use case for running the railway design CAD tool in general is that one performs a series of small changes. Indeed, we have found in the collaborations with railway engineers that large portions of the design phase have the goal of efficiently handling changes in track layouts, component capabilities, performance requirements, etc. The verification could, instead of being called whenever final version printouts are being made, instantly report potential problems in the design as soon as this information is available.

This requires lowering the running time of the verification, hopefully to less than one second, while keeping in mind that our prototype verification tool should eventually be able to scale up to much larger stations, projects spanning several stations, and significantly larger knowledge bases. Exploiting the fact that the design work is incremental, also evaluating the Datalog programs incrementally seems to be a promising solution to this challenge.

Most railway regulations, also in the signalling discipline, are of a local character, meaning that verification can be performed by looking only at data from a bounded radius around the object which is being verified. This suggests that the details of object placement at one station seldom influence the object placements at another station. Such locality of properties has been earlier exploited by other railway verification approaches, e.g., [23] or [4]. Bonacchi et al. [4], in particular use locality to split model checking problems into smaller pieces, and using topology data to optimize variable ordering in BDD-based verification. For incremental Datalog verification, locality of rules would mean that predicates which depend on graph connectedness would have a bound on the search depth needed to update results after a single object’s change.

In this section we give an overview of approaches and algorithms for incremental Datalog and the tools that are available. We study these from the viewpoint of our application domain and evaluate initial performance on our case study.

Incremental evaluation of Datalog

Datalog systems use rules to derive a set of consequences (intentional facts), from a given set of base facts (extensional facts). Typically, Datalog systems use a bottom-up (or forward-chaining) evaluation strategy, where all possible consequences are materialized [53, Chap. 3] [1, Chap. 13]. This simplifies query answering to just looking up values in the materialization tables. Any change to the base facts, however, will invalidate the materialization. Several approaches have been suggested to reduce the work required to find a new materialization after changing the base facts.

First, if considering only addition of facts to positive Datalog programs, i.e. without negation, then the standard semi-naive algorithm [53, Chap. 3] [1, Chap. 13] is already an efficient approach, as it correctly handles additions to the materialization in an incremental manner. The real challenge is due to non-monotonic changes, i.e., when removing facts appearing positively in rules or adding facts appearing negatively in rules. Non-monotonicity is essential in our railway infrastructure verification rules. Graph reachability is prominent in many of the regulations for railway signalling, so efficiently maintaining rules involving transitivity is also essential.

Some algorithms, such as truth maintenance systems [9], work by storing more information (in addition to the logical consequences) about the supporting facts for derived facts, so that removal of supporting facts may or may not remove a derived fact, depending on whether the support is still sufficient. This allows efficient removal of facts, at the cost of requiring more time and memory for normal derivations. Inspired by the truth maintenance systems of Doyle [9], the XSB Prolog system implements incremental tabling [51] by keeping such sets of supporting facts in memory. Figure 9 shows deduced facts for a graph reachability query. In this case, whenever there are several paths connecting a pair of vertices of the graph, the reach fact for the two vertices is deduced in several ways. In the approach taken in XSB Prolog, different sets of facts that independently prove a derived fact are stored in tables. Whenever changes are made to base facts, the sets of supporting facts can be removed, and as long as the set is not emptied, the derived fact still holds.

Fig. 9
figure 9

Edge relation and corresponding support sets for a reachability predicate (example from [47])

Another class of algorithms, working without additional “bookkeeping”, can be more efficient if the re-evaluation of sets of facts is relatively easy compared to re-materializing all facts. The Propagation-Filtering algorithm [19] works on each removed fact separately, propagating it through to all rules which depend on it, while also after each step of the propagation performing a query for alternative support which would end the propagation. In contrast, the Delete-Rederive (DRed) algorithm [18] is rule-oriented and works on sets of facts, first over-approximating all possible deletions that may result from a change in base facts, then re-deriving any still-supported facts from the over-deleted state before finally continuing semi-naive materialization on newly added facts.

An example where the DRed algorithm is less efficient is graph reachability, which can be encoded on the following form:

$$\begin{aligned} \begin{aligned} {\mathrm {path}}(x,y)&\leftarrow {\mathrm {edge}}(x,y), \\ {\mathrm {path}}(x,y)&\leftarrow {\mathrm {edge}}(x,z) \wedge {\mathrm {path}}(z,y). \end{aligned} \end{aligned}$$

Figure 10 shows key differences in update approaches for the example of a graph reachability from a given node.

Fig. 10
figure 10

Different approaches to incremental evaluation demonstrated on a reachability program using an edge relation. Using the edge relation in (a), the reachability from the first vertex is calculated, and update strategies for b DRed, c FBF, and d a counting approach are exemplified. a Edge relation visualized as arrows between objects (each element is an arrow e(ab)). b DRed algorithm: removing one edge (thick line) triggers re-evaluation of many dependent edges (dashed lines). c FBF algorithm: removing one edge (thick line) causes re-evaluation of dependent edge (thick dashed line), but confirmation that this edge is still valid stops further propagation. d Counting approach: removing one edge (thick line) causes re-evaluation of dependent edge (thick dashed line), but because this edge has multiple derivations, it is still valid, and propagation can stop. Note that a pure counting approach is not sufficient in this case because of the recursive reachability rule

Recently, the Forward/Backward/Forward (FBF) algorithm [37] used in RDFox improved the DRed algorithm in most cases by searching for alternative support (and caching the results) for each potentially deleted fact before proceeding to the next fact. Notably, this method performs better on rules involving transitivity, as deletions do not propagate further than necessary.

This method is used in the Semantic Web tool RDFox,Footnote 11 which has a high performance on multicore processors with in-memory databases. We are considering RDFox as an alternative candidate for the back end of our incremental railway infrastructure verification procedure.

Tools and performance

This section summarizes a survey of tools first presented in [32], and describes tools that feature incremental evaluation and Datalog, and which have the maturity required for industrial applications. The logic programs for our verification make use of recursive predicates, stratified negation, and arithmetic. Therefore, we pay particular attention to tools that at least satisfy these needs. In addition, we are looking for high performance on relatively small (in-memory) data sets, so light-weight library-style logic engines are preferred. High-performance distributed “big data” type of tools have less value in this context.

XSB Prolog,:

continuously developed since 1990, has constantly been pushing the state of the art in high-performance Prolog. XSB is especially known for its tabling support [52], which allows fast Datalog-like evaluation of logic programs without restricting ISO Prolog in any way. The tabling support was extended to allow incremental evaluation [47], and these features have been under continued development and seem to have reached a mature state [51]. For some applications, however, the additional memory usage for incremental tabling can lead to a significant increase in the total memory needed.


is a multicore-scalable in-memory RDF triple store with Datalog reasoning. It reads semantic web formats (RDF/OWL) and stores RDF triples, but also includes a Datalog-like input language which can describe SWRL rules. This rule language has been extended to include stratified negation and arithmetic. The RDFox system also implements the new FBF algorithm for incremental evaluation [37].

RDFox stores internally only triples as in RDF (subject, predicate, and object), which, in Datalog, corresponds to only using unary and binary predicates. A method of reifying the rules for higher-arity Datalog predicates into binary predicates allows RDFox to calculate any-arity Datalog programs. However, this requires separate rules for each component (argument) of the predicate, and when doing incremental evaluation, the FBF algorithm’s backward chaining step then examines all combinations of components (arguments) potentially involved in such a higher-arity predicate. Because of this problem, using RDFox incrementally did not improve running times in our case study, suggesting a need for native support for n-ary predicates in RDFox.


is a programming platform [2] for combining transactions with analytics in enterprise application areas including web-based retail planning and insurance. It uses a typed, Datalog-based custom language LogiQL and has a comprehensive development framework. It claims support for incremental verification, but we could not evaluate it on our railway example due to absence of freely downloadable distributions.


is a promising new Datalog-like language for modern statistical AI systems [11]. It has currently not matured sufficiently for our application, but its techniques are promising, and we hope to see it more fully developed in the future.

Many other Datalog tools are available (around 30), few of them supporting incremental evaluation. An overview and our brief evaluation of them can be found in the technical report [34], and a more general overview of Datalog tools can be found in the Wikipedia page.Footnote 12


Table 3 compares the running time and memory usage for the verification case study of Arna station presented in Sect. 6, extended to use the incremental capabilities of XSB Prolog. The extra bookkeeping required in XSB to prepare for incremental evaluation requires more time and memory than non-incremental evaluation, so we include both non-incremental and from-scratch incremental evaluation in the table for comparison. We show how updates can be calculated faster than from-scratch evaluation by moving a single object (an axle counter) in and out of a disallowed area near another object (regulations require at least 21.0 m separation between train detectors). XSB has a configurable mode for reducing the memory usage in its incremental tabling, by abstraction methods. Without using XSB’s abstraction methods, the case study verification uses over 2 GB of memory. So, for any hope of handling larger stations on a standard laptop or workstation, this must be reduced. We were not able to reduce memory usage in this case study using the abstraction methods in XSB (version 3.6.0).

Table 3 Case study size and running times on a standard laptop

While currently none of the tools seem to satisfy all conditions we hoped for in our integration, notably efficiency, but also maturity and stability, it should also be noted that the need for incremental evaluation has been identified by the community not only as theoretically interesting, but also as of practical importance. The RDFox developers aim to support incremental updates of higher-arity predicates in a later version. The XSB project has made efforts to improve its memory usage, so future versions might become feasible for our use. If reducing the memory usage would require adapting a Datalog algorithm (such as DRed), then XSB’s unrestricted Prolog might be a challenge. A different approach would be to extend another efficient Datalog tool, such as SouffléFootnote 13 to do incremental evaluation, which could require a significant effort.

In our CAD-integrated tool, the verification results would be updated after each incremental change made to the model (similar to how a programming IDE shows errors while typing), so the somewhat increased initial baseline verification time is unproblematic. However, we have not actually put incremental methods into use in our prototype tool because no incremental Datalog tools were found to be mature enough.

Conclusions, related and further work

We have demonstrated a logical formalism in which railway layout and interlocking constraints can be modelled and technical regulations can be expressed, and which can be decided by logic programming methods (Datalog in particular) with polynomial time complexity. This allows verification of railway signalling designs against infrastructure manager regulations. It also allows to build and maintain a formally expressed body of expert knowledge, which may be exchanged between engineers and automatically checked against designs. We have demonstrated this approach on an ongoing railway design project from the Anacon AS company and using the standard regulations from the Norwegian railway authorities. We have implemented a prototype and integrated it in the engineer’s CAD design tool suite. Even though preliminary tests show good performance, we saw the need for faster verification methods, and thus looked into incremental verification tools for Datalog. In this respect we presented our summary of findings and our test results on our railway use case.

This paper is an extension and combination of three previous conference papers, i.e., we extended our initial results from [33] with more explanations and background material; we combined and explained the logical work in more context, some of which was presented in [31] to the practitioners from the railway domain; we explained the need for incremental verification and provided our findings and conclusions, part of which were presented in [32]. This paper, thus, presents our results in a more uniform and integrated manner, giving a better picture of the overall tool chain and putting the problem well in context. Our future work is detailed in the following.

Related work

Railway control systems and signalling designs are a fertile ground for formal methods. See [3, 12] for an overview of various approaches and pointers to the literature, applying formal methods in various phases of railway design. For a slightly more dated state-of-the-art survey, see [22]. In particular, safety of interlockings has been intensively formalized and studied, using for instance VDM [16] and the B-method, resp. Event-B [27]. Model checking has proved particularly attractive for tackling the safety of interlocking, and various model checkers and temporal logics have been used, see e.g. [7, 10, 17, 35, 43, 56]. Critically evaluating practicality, [13] investigated applicability of model checking for interlocking tables using NuSMV or Spin, two prominent representatives of BDD-based symbolic model checking, respectively explicit state model checking. The research shows that interlocking systems of realistic size are currently out of reach for both flavors of general purpose model checkers. To mitigate the state-space explosion problem, [21] uses bounded model checking [8] for interlockings. Instead of attempting an exhaustive coverage of the state-space, symbolically or explicitly, bounded model checking analyses (the behavior of) a given system only up to a given bound (which is raised incrementally in case analyzing a problem instance is inconclusive). This restriction allows to use SAT solving techniques in the analysis. The paper uses a variant of linear temporal logic (LTL) for safety property specification and employs so-call k-induction. The work of [55] investigates how to exploit domain-specific knowledge about interlocking verification to obtain good variable orderings when encoding the systems to be verified in a BDD-based symbolic model checker. An influential technology is the tool-based support for verified code generation for railway interlockings from Prover AB Sweden [5]. Prover is an automated theorem prover, using Stålmarck’s method [50] of tautology checking.

Also logic (programming) languages, like Prolog or Datalog, have been used for representing and checking various aspects of railway designs. For the verification of signalling of an interlocking design [24] uses a Prolog database to represent the topology and the layout, where for the verification, the work uses a separate SAT solver. Similarly, the work of [38, 39] uses logic programming for verification of interlocking systems. In particular, the work uses a specific version of so-called annotated logic, namely annotated logic programs with strong negation (ALPSN). In general and beyond the railway system domain, recent times have seen renewed research interest in Datalog, see for instance the collection [36]. Datalog has in particular been used for formalizing and efficiently implementing program analyses [48, 54], whereas [49] presents Doop, a context-sensitive points-to analysis framework for Java.

The mentioned works generally include dynamic aspects of the railway in their checking, like train positions and the interlocking state. This is in contrast to our work, which focuses on checking against a formalization of the general design rules issued by the regulatory bodies, thus concentrating on static aspects such as the signalling layout. This makes the notorious state-space explosion problem less urgent and makes an integration into the standard design workflow within the existing CAD tool practical.

Lodemann et al. [29] use semantic technologies to automate railway infrastructure verification. Their scope is still wider than this paper in the computational sense, with the full expressive power of OWL ontologies, running times on the order of hours, and the use of separate interactive graphical user interfaces rather than integration with design tools.

The use of logic programming and knowledge-base systems has been explored in depth for railway control systems, e.g. by Fringuelli et al. [14], who use logic programming to assist a station operator in performing local control actions on a railway station. The knowledge-base system that we presented has a similar encoding of static railway station layout, but with a different goal, namely to aid in designing the layout (static design) rather than executing commands (dynamic control).

Haxthausen and Østergaard [20] perform static checking of interlockings using a DSL for specifying network layout and interlocking specification, and a C++ program for performing the checks. Their scope for static checking of interlockings is similar to ours, but their focus is on using this as a preparation step for model checking an interlocking implementation, while our focus is on allowing diverse extensions to the rule base and creating user-friendly integrated tools.

Future work

In the future work with RailComplete AS, we will focus on extending the rule base to contain more relevant signalling and interlocking regulations, and also on evaluating the performance of our verification on a larger scale. Design information and rules about other railway control systems, such as geographical interlockings and train protection systems could also be included. The current work is assuming Norwegian regulations, but the European Rail Traffic Management System (ETCS/ERTMS) is expected to dominate in the future. The work on further developing our prototype verification tool in the context of the commercial RailCOMPLETE CAD software would also need to extend the rule base to cover more of signalling regulations and extending also to other disciplines. In this process, ETCS/ERTMS regulations would also be relevant.

Involving railway engineers in knowledge base development is somewhat hindered by the fact that Datalog and logic programming, though declarative and concise, are still programming languages, and a good intuition about language semantics is required for efficient and correct development. We have started developing a higher-level domain-specific language which compiles to Datalog, for the purpose of including railway engineers more closely in the knowledge base development. Using the techniques of controlled natural languages (CNL) [26], the language is formally defined and parsable, yet readable as natural language. Writing text in a controlled natural language is a harder problem, as the formal grammar limits what can be expressed, and also how it is written. This problem can be mitigated by means of specialized text editors (e.g., as provided by the Grammatical Framework [44],[45, Chap. 7] or Attempto Controlled English [15, 25]) which guide the user towards writing acceptable sentences. Adding specific language constructs for static infrastructure analysis of railway designs ensures that the level of abstraction is close to the original regulation text. Our future work will include testing this language with railway engineers and integrating knowledge base development into the railway design tool chain. This preliminary work can be reached through the technical report [30] which will be updated in the future.

Finally, we plan to extend from consistency checking to optimization of designs. Optimization goals for layout plans include (i) simplified capacity/perfomance metrics, such as train spacing time between stations, or train travel time between stations, (ii) safety metrics, such as minimizing the number of short safety zones (also called overlaps), which are allowed by regulation but undesirable, or (iii) component cost and complexity metrics, such as the total number of signals, detectors, etc. Optimization requires significantly larger computational effort, and the relation between Datalog and more expressive logical programming frameworks could become relevant.





  4. Jernbaneverket: Teknisk regelverk,

  5. Prover Technology AB:

  6. OpenTrack: simulation of railway networks,

  7. LUKS: analysis of lines and junctions,

  8. treno: timetable reliability & network operations analyser, University of Trieste.


  10. The Norwegian Railway Authorities (

  11. RDFox: scalable in-memory RDF triple store with share memory parallel Datalog reasoning,


  13. Soufflé: a Datalog compiler,


  1. Abiteboul S, Hull R, Vianu V (eds) (1995) Foundations of databases, 1st edn. Addison-Wesley, Boston

    MATH  Google Scholar 

  2. Aref M, ten Cate B, Green TJ, Kimelfeld B, Olteanu D, Pasalic E, Veldhuizen TL, Washburn G (2015) Design and implementation of the LogicBlox system. In: Sellis TK, Davidson SB, Ives ZG (eds) The 2015 ACM SIGMOD international conference on management of data, pp 1371–1382, ACM. doi:10.1145/2723372.2742796

  3. Bjørner D (2003) New results and trends in formal techniques for the development of software in transportation systems. In: Tarnai G, Schnieder E (eds) Proceedings of the symposium on formal methods for railway operation and control systems (FORMS’03), pp 1–20, L’Harmattan Hongrie

  4. Bonacchi A, Fantechi A, Bacherini S, Tempestini M (2016) Validation process for railway interlocking systems. Sci Comput Progr 128:2–21. doi:10.1016/j.scico.2016.04.004

    Article  Google Scholar 

  5. Borälv A, Stålmarck G (1999) Prover technology in railways. In: Hinchey MG, Bowen JP (eds) Industrial-strength formal methods, international series in formal methods. Springer, Berlin, pp 305–329

    Google Scholar 

  6. Bosschaart M, Quaglietta E, Janssen B, Goverde RMP (2015) Efficient formalization of railway interlocking data in RailML. Inf Syst 49:126–141. doi:10.1016/

    Article  Google Scholar 

  7. Busard S, Cappart Q, Limbrée C, Pecheur C, Schaus P (2015) Verification of railway interlocking systems. In: Pang J, Liu Y, Mauw S (eds) Proceedings 4th international workshop on engineering safety and security systems, ESSS, Electronic Proceedings in Theoretical Computer Science, vol 184, pp 19–31. Open Publishing Association. doi:10.4204/EPTCS.184.2

  8. Clarke EM, Biere A, Raimi R, Zhu Y (2001) Bounded model checking using satisfiability solving. Formal Methods Sys Des 19:7–34

    Article  MATH  Google Scholar 

  9. Doyle J (1979) A truth maintenance system. Artif Intell 12(3):231–272. doi:10.1016/0004-3702(79)90008-0

    MathSciNet  Article  Google Scholar 

  10. Eisner C (1999) Using symbolic model checking to verify the railway stations of Hoorn-Kersenboogerd and Heerhuowaard. In: Pierre L, Kropf T (eds) 10th IFIP WG 10.5 advanced research working conference on correct hardware design and verification methods, CHARME ’99, Lecture Notes in Computer Science, vol 1703, pp 97–109. Springer

  11. Eisner J, Filardo NW (2011) Dyna: extending datalog for modern AI. In: de Moor O, Gottlob G, Furche T, Sellers A (eds) Datalog reloaded. First international workshop 2010, Lecture notes in computer science, vol 6702. Springer, pp 181–220

  12. Fantechi A, Fokkink W, Morzenti A (2012) Some trends in formal methods applications to railway signalling. In: Gnesi S, Margaria T (eds) Formal methods for industrial critical systems. Wiley, Hoboken, pp 61–84

    Chapter  Google Scholar 

  13. Ferrari A, Magnani G, Grasso D, Fantechi A (2011) Model checking interlocking control tables. In: Schnieder E, Tarnai G (eds) 8th Symposium on formal methods for automation and safety in railway and automotive systems (FORMS/FORMAT 2010), pp 107–115. Springer. doi:10.1007/978-3-642-14261-1

  14. Fringuelli B, Lamma E, Mello P, Santocchia G (1992) Knowledge-based technology for controlling railway stations. IEEE Expert 7(6):45–52. doi:10.1109/64.180408

    Article  Google Scholar 

  15. Fuchs NE, Kaljurand K, Kuhn T (2008) Attempto controlled english for knowledge representation. In: Baroglio C, Bonatti P, Maluszynski J, Marchiori M, Polleres A, Schaffert S (eds) Reasoning Web, Lecture Notes in Computer Science, vol 5224, pp 104–124. Springer. doi:10.1007/978-3-540-85658-0_3

  16. Fukuda M, Hirao Y, Ogino T (2000) VDM specification of an interlocking system and a simulator for its validation. In: Becker U, Schneider EL (eds) 9th IFAC symposium control in transportation systems, pp 218–223. IFAC

  17. Gnesi S, Lenzini G, Latella D, Abbaneo C, Amendola A, Marmo P (2000) Automatic spin validation of a safety critical railway control system. In: IEEE conference on dependable systems and networks. IEEE Computer Society Press. pp 119–124

  18. Gupta A, Mumick IS, Subrahmanian VS (1993) Maintaining views incrementally. In: Buneman P, Jajodia S (eds) SIGMOD international conference on management of data, SIGMOD ’93, pp 157–166. ACM. doi:10.1145/170035.170066

  19. Harrison JV, Dietrich SW (1992) Maintenance of materialized views in a deductive database: an update propagation approach. In: Ramamohanarao K, Harland J, Dong G (eds) Proceedings of the workshop on deductive databases held in conjunction with the joint international conference and symposium on logic programming, technical report, vol CITRI/TR-92-65, pp 56–65. Department of Computer Science, University of Melbourne

  20. Haxthausen AE, Østergaard PH (2016) On the use of static checking in the verification of interlocking systems. In: Margaria T, Steffen B (eds) 7th international symposium on leveraging applications of formal methods, verification and validation (ISoLA), Lecture notes in computer science, vol 9953, pp 266–278. Springer. doi:10.1007/978-3-319-47169-3_19

  21. Haxthausen AE, Peleska J, Pinger R (2014) Applied bounded model checking for interlocking system designs. In: Counsell S, Núñez M (eds) Software engineering and formal methods collocated workshops. Lecture notes in computer science, vol 8368. Springer. pp 205–220

  22. Hinchey MG, Bowen JP (eds) (1999) Industrial-strength formal methods. International series in formal methods. Springer, Berlin

    Google Scholar 

  23. James P, Lawrence A, Moller F, Roggenbach M, Seisenberger M, Setzer A, Kanso K, Chadwick S (2013) Verification of solid state interlocking programs. In: Revised selected papers of the SEFM 2013 collocated workshops on software engineering and formal methods. Lecture notes in computer science, vol 8368. Springer. pp 253–268. doi:10.1007/978-3-319-05032-4_19

  24. Kanso K, Moller F, Setzer A (2009) Automated verification of signalling principles in railway interlocking systems. In: Miller A, Calder M (eds) Proceedings of the 8th international workshop on automated verification of critical systems (AVoCS 2008), Electronic notes in theoretical computer science, vol 250. Elsevier. pp 19–31. doi:10.1016/j.entcs.2009.08.015

  25. Kuhn T (2013) A principled approach to grammars for controlled natural languages and predictive editors. J Log Lang Inf 22(1):33–70. doi:10.1007/s10849-012-9167-z

    Article  MATH  Google Scholar 

  26. Kuhn T (2014) A survey and classification of controlled natural languages. Comput Linguist 40(1):121–170. doi:10.1162/COLI_a_00168

    Article  Google Scholar 

  27. Lecomte T, Burdy L, Leuschel M (2012) Formally checking large data sets in the railways. In: Ishikawa F, Romanovsky A (eds) Advances in developing dependable systems in event-B. In conjunction with ICFEM 2012, Technical Report. Newcastle University

  28. Libkin L (2004) Elements of finite model theory. Texts in theoretical computer science. An EATCS series. Springer. doi:10.1007/978-3-662-07003-1

  29. Lodemann M, Luttenberger N, Schulz E (2013) Semantic computing for railway infrastructure verification. In: 7th International conference on semantic computing (ICSC). IEEE. pp 371–376. doi:10.1109/ICSC.2013.69

  30. Luteberget B, Camilleri JJ, Johansen C, Schneider G (2017) Participatory verification of railway infrastructure regulations using RailCNL (long version). Technical report 465, University of Oslo.

  31. Luteberget B, Feyling C (2016) Automated verification of rules and regulations compliance in CAD models of railway signalling and interlocking. In: Brebbia C, Mera J, Tomii N, Tzieropoulos P (eds) Computers in railways, WIT Press. 15: 153–165

  32. Luteberget B, Johansen C, Feyling C, Steffen M (2016) Rule-based incremental verification tools applied to railway designs and regulations. In: Fitzgerald J, Heitmeyer C, Gnesi S, Philippou A (eds) 21st International symposium on formal methods (FM). Lecture notes in computer science, vol 9995. Springer. pp 772–778. doi:10.1007/978-3-319-48989-6_49

  33. Luteberget B, Johansen C, Steffen M (2016) Rule-based consistency checking of railway infrastructure designs. In: Ábrahám E, Huisman M (eds.) 12th International conference on integrated formal methods (iFM 2016). Lecture notes in computer science, vol 9681. Springer. pp 491–507. doi:10.1007/978-3-319-33693-0_31

  34. Luteberget B, Johansen C, Steffen M (2016) Rule-based consistency checking of railway infrastructure designs (long version). Technical report 450, University of Oslo, Department of Informatics.

  35. Mirabadi A, Yazdi MB (2009) Automatic generation and verification of railway interlocking tables using FSM and NuSMV. Transp Probl: Int Sci J 4:103–110

    Google Scholar 

  36. de Moor O, Gottlob G, Furche T, Sellers A (eds) (2011) Datalog reloaded. In: 1st international workshop 2010. Lecture notes in computer science, vol 6702. Springer

  37. Motik B, Nenov Y, Piro REF, Horrocks I (2015) Incremental update of datalog materialisation: the backward/forward algorithm. In: Bonet B, Koenig S (eds) 29th AAAI conference on artificial intelligence. AAAI Press. pp 1560–1568

  38. Nakamatsu K, Kiuchi Y, Chen W, Chung S (2004) Intelligent railway interlocking safety verification based on annotated logic program and its simulator. In: IEEE international conference on networking, sensing and control, vol 1. IEEE. pp 694–699. doi:10.1109/ICNSC.2004.1297524

  39. Nakamatsu K, Kiuchi Y, Suzuki A (2004) EVALPSN based railway interlocking simulator. In: Negoita MG, Howlett RJ, Jain LC (eds) Knowledge-based intelligent information and engineering systems, Lecture notes in artificial intelligence, vol 3214. Springer. pp 961–967

  40. Nash A, Huerlimann D, Schütte J (2004) RailML—a standard data interface for railroad applications. In: Allan J, Brebbia C, Hill R, Sciutto G, Sone S (eds) Comput Railw IX. WIT Press, Ashurst, pp 233–240

    Google Scholar 

  41. Nilsson U, Maluszynski J (1995) Logic, programming, and prolog, 2nd edn. Wiley, Hoboken

    MATH  Google Scholar 

  42. Pachl J (2015) Railway operation and control. VTD Rail Publishing, Mountlake Terrace

    Google Scholar 

  43. Pavlovic O, Ehrich H (2010) Model checking PLC software written in function block diagram. In: 3rd International conference on software testing, verification and validation, ICST. IEEE. pp 439–448

  44. Ranta A (2004) Grammatical framework. J Func Progr 14(2):145–189. doi:10.1017/S0956796803004738

    MathSciNet  Article  MATH  Google Scholar 

  45. Ranta A (2011) Grammatical framework programming with multilingual grammars. CSLI Publications, Stanford

    Google Scholar 

  46. Russell SJ, Norvig P (2003) Artificial intelligence: a modern approach, 2nd edn. Pearson Education, Upper Saddle River

    MATH  Google Scholar 

  47. Saha D, Ramakrishnan CR (2003) Incremental evaluation of tabled logic programs. In: Palamidessi C (ed) 19th International conference on ICLPLogic programming. Lecture notes in computer science, vol 2916. Springer. pp 392–406. doi:10.1007/978-3-540-24599-5_27

  48. Smaragdakis Y, Bravenboer M (2011) Using Datalog for fast and easy program analysis. In: de Moor O, Gottlob G, Furche T, Sellers A (eds) Datalog reloaded. First international workshop 2010, Lecture notes in computer science, vol 6702. Springer, pp 245–251

  49. Smaragdakis Y, Bravenboer M, Lhoták O (2011) Pick your contexts well: understanding context-sensitivity (the making of a precise and scalable pointer analysis). In: Ball T, Sagiv M (eds) 38th ACM SIGPLAN-SIGACT symposium on principles of programming languages (POPL). ACM. pp 17–30

  50. Stalmårck G (1992) A system for determining logic theorems by applying values and rules to triplets that are generated from a formula. Swedish Patent No. 467 076 (approved 1992), U.S. Patent No. 5 276 897 (approved 1994), European Patent No. 0403 454 (approved 1995)

  51. Swift T (2014) Incremental tabling in support of knowledge representation and reasoning. Theory Pract Log Progr 14(4–5):553–567. doi:10.1017/S1471068414000209

    Article  MATH  Google Scholar 

  52. Swift T, Warren DS (2012) XSB: Extending Prolog with tabled logic programming. Theory Pract Log Progr 12(1–2):157–187. doi:10.1017/S1471068411000500

    MathSciNet  Article  MATH  Google Scholar 

  53. Ullman JD (1988) Principles of database and knowledge-base systems (Volume 1 and 2). Computer Society Press, Hoboken

    Google Scholar 

  54. Whaley J, Avots D, Carbin M, Lam MS (2005) Using Datalog with binary decision diagrams for program analysis. In: Yi K (ed) 3rd Asian symposium on programming languages and systems (APLAS). Lecture notes in computer science, vol 3780. Springer. pp 97–108

  55. Winter K (2012) Optimising ordering strategies for symbolic model checking interlocking control tables. In: Margaria T, Steffen B (eds) 5th International symposium on leveraging applications of formal methods, verification, and validation (ISOLA’12), Part II. Lecture notes in computer science, vol 7610. Springer, pp 246–260

  56. Winter K, Johnston W, Robinson P, Strooper P, van den Berg L (2006) Tool support for checking railway interlocking designs. In: Cant T (ed) Proceedings of the 10th Australian workshop on safety critical systems and software. ACM. pp 101–107

Download references


We are grateful to Claus Feyling from RailComplete AS and Martin Steffen from University of Oslo for valuable inputs.

Author information

Authors and Affiliations


Corresponding author

Correspondence to Bjørnar Luteberget.

Additional information

This work was partially supported by the RailComplete AS company and the project RailCons funded by the Norwegian Research Council.

Rights and permissions

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (, which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Luteberget, B., Johansen, C. Efficient verification of railway infrastructure designs against standard regulations. Form Methods Syst Des 52, 1–32 (2018).

Download citation

  • Published:

  • Issue Date:

  • DOI:


  • Railway designs
  • Automation
  • Logic programming
  • Signalling
  • Railway infrastructure
  • railML
  • CAD
  • Datalog
  • Incremental verification