Keywords

1 Introduction

The development of modern railways applications must be supported by trusted tools, able to cover the whole development process. In this paper, we describe the research challenges underlying an important effort aiming at the definition of a comprehensive design methodology for the design of computer-based interlocking systems for the Italian railways network [3]. The framework is intended to provide great usability to signaling engineers and it is based on advanced formal techniques to ensure adequate verification and validation capabilities.

The framework adopts a VV development process, clearly separating the abstract interlocking logic (corresponding to the first V, for domain-specific design aspects) and the various instantiations characterizing the single stations (corresponding to the second V, for product specific design aspects). The framework is supported by three tools, tightly integrated together, covering different aspects of the design flow. The AIDA tool [2] allows to represent the generic interlocking logic, providing various validation steps and supporting the compilation to executable code. The TOSCA tool supports the specification, generation and execution of test cases. The NORMA tool deals with the legacy interlocking solution, based on electromechanical, relay-based technology.

The challenges include leveraging the domain-product separation (Sect. 2), the definition of adequate specification languages and the traceability across levels of abstraction (Sect. 3), automated test case generation (Sect. 4), formal verification (Sect. 5), trusted compilation and tool qualification (Sect. 6), and reconciliation between computer-based and relay-based interlocking (Sect. 7).

2 General VV Flow

The approach to the design, development and verification of the interlocking system relies on the fact that it is a parameterized system that is instantiated for each railway station. It can be seen as a software product line (PL). In particular, a generic Interlocking logic (IXL) is instantiated by specifying different station configurations \(\{ cfg_1 , \dots , cfg_i ,\dots , cfg_n \}\) in different specific IXLs for each of the different stations \(\{\text {IXL}[ cfg_1 ], \dots , \text {IXL}[ cfg_i ],\dots , \text {IXL}[ cfg_n ]\}\). The development and testing methodologies typical of PL systems can be applied to these configurations. A product line (PL) is a family of products with common core features and other alternative features. The focus is on optimally managing product variability. The PL is instantiated in a specific product by putting together the features in common and the specific features for that product. One of the methodologies implemented for testing PL systems is the VV model [11] (see Fig. 1) that groups the design implementation and testing activities of PL-type systems into two parts: domain engineering and application engineering.

Fig. 1.
figure 1

The VV model in the interlocking logic development and testing.

Full size image

During the domain engineering phase, the analysis of the requirements and models in the domain is carried out in order to then be able to design the product line by identifying the points of variability. Once the features in common and the variants have been identified, the implementation of the features in common and some of the variants can be performed, thus producing reusable artifacts during the development phase of specific applications. The testing activities during domain engineering are carried out by applying component testing to each of the developed components, their integration and finally testing the functioning of the platform in general. Since a specific product does not yet exist during domain engineering, an exemplary product is used to carry out the test activities. During the application engineering phase, the specific product that is about to be built and deployed is analysed using all the artifacts already developed and tested during the domain engineering phase. In this phase, therefore, all the components that are necessary to build the specific desired product are implemented. The testing activities in this phase are similar to those of a traditional application in which typical testing methods are applied; in this case all the artifacts developed and tested during the domain engineering phase are reused. Therefore, during the application engineering phase, attention is focused on the development and testing of new components, taking into account the test cases already produced by the testing activities during the domain engineering phase.

3 Modeling Layers

The development process described above takes as its informal starting point the domain knowledge and the railway documents (national provisions, regulations and legacy relay circuits diagrams). These documents are formalized in three, tightly related levels of abstraction [2]: requirements level, models level and code level (Fig. 2):

  • At the requirements level, national provisions, regulations, and relay-circuit diagrams are manually translated by domain experts into Functional Requirements Specifications (FRS), a formalism for expressing railway-specific requirements via the use of Controlled Natural Language (CNL), a programming language designed to resemble the technical Italian language used in regulations and provisions;

  • At the models level, a representation in SysML is automatically derived from the FRS. The SysML level contains structural (e.g. dependencies between classes) and behavioral aspects (transitions of state machines, communication between state machines) of the IXL system;

  • Finally, at the code level (multiple variants of) the actual IXL C code are automatically derived from the SysML models.

The approach ensures the full traceability between the three development levels. The overall development process is supported by the tool AIDA, implemented as an Eclipse plug-in on top of CHESS platform [8].

Fig. 2.
figure 2

The modelling and implementation layers.

Full size image

The same levels of abstraction are retained for the testing framework. Depending on the level of abstraction, test cases can be specified/represented at the FRS level, at the model level, and at the code level. The execution of these test cases can take place as a simulation on the model or as a concrete execution on the code. The traceability between the different levels of abstraction allows the tool to map the execution of one level to the other levels. Similarly, coverage information can be related across abstraction levels.

The main challenge is to define a suitable trade-off between the usability of the language and its level of formality. This was achieved by designing domain-specific, controlled natural languages, both for control procedures and for test scenarios, that are very close to the style of the informal documents typically adopted in this domain. Despite their natural language flavor, the controlled natural languages have a clear execution semantics that is exploited in the compilation to SysML and to code.

Another important challenge is achieving high-quality requirements. This is supported by providing extensive checking on the controlled natural language, both at the syntactic and at the sematic level. Furthermore, the automated extraction of documentation (class diagrams, finite-state machines) provides support for manual inspection and immediate validation. Finally, the toolset provides the possibility to animate the specifications, to run them in closed loop with a station simulator, and to inspect the various phases by means of a dedicated debugger.

Further research efforts will address the problem of supporting the experts in the automated or semi-automated derivation of the specification of the procedures and test cases directly from railway regulations and technical specifications. These are usually written in uncontrolled natural language, following a domain jargon, and pose substantial challenges for current state-of-the-art natural language processing techniques.

4 Testing

The approach proposes a testing process that goes from the test cases specification, to their execution, to the collection of testing results in terms, for example, of code or SysML model entities coverage. The process also distinguishes between the abstract test cases, specified in the domain engineering phase, and those that are configuration specific defined in the application engineering phase, namely concrete test cases. The methodology is supported by the tool TOSCA, implemented as an Eclipse plug-in.

The testing methodology allows the tester, in general a railway expert, to prepare test suites containing abstract test cases for the interlocking system using a specific Controlled Natural Language that represents assumption, assertion, and verification statements in a test case using the railway jargon. Abstract test cases do not refer to the entities of a specific station configuration, so they are generic with respect to specific railway plant. The tester can write the test suites using the frontend of TOSCA that supports the expert providing editing services such as autocompletion and syntax check of the test statements, in order to continuously guide the expert in the specification of well-formed test cases.

Abstract test cases can be directly instantiated for a specific railway plant configuration \( cfg_i \), obtaining concrete test cases that explicitly refer to the entities of the specific railway interlocking system for that plant (IXL[\( cfg_i \)]). Specifically, for each abstract test case it is possible to either instantiate it on a specific route, signal, track circuit, producing a single concrete test case or to generate all possible concrete test cases to be instantiated for the station under test.

Concrete tests can then be automatically transformed into executable tests to be run on the interlocking system of the plant under test. The results of the test cases execution can be analyzed having different objectives in mind. On the one hand it is possible to perform functional system testing with the objective of identifying test cases able to detect system failures. On the other hand the objective could be that of maximizing the coverage of the system code, in terms of lines or branches that are executed, or of the SysML model entities, in terms of states and transitions that are traversed during the execution.

The approach also allows to automatically generate Test cases with the main objective of producing tests able to cover portions of code or SysML models that are difficult to be covered using manually specified test cases. The approach relies on search-based techniques, specifically genetic algorithms, that use the SysML model to drive the test case generation.

Research challenges in the testing area are twofold. On the one hand we aim at supporting the experts in translating railway regulations expressed in natural language into abstract or concrete test cases in controlled natural language. This aspect is an important step to be sure that, for example, all the regulations have been translated into a comprehensive set of test suites. On the other hand, concerning the automated generation of test cases, we aim at investigating the possibility of mixing search-based approaches with formal techniques, such as model checking, in order to exploit the power of the two techniques to overcome limitations related to the accuracy of cases in the current search approach.

5 Formal Verification

Complementary to testing, which focuses on producing execution traces witnessing existential properties (i.e. “scenarios”) and on providing coverage of the system at the various levels of abstraction discussed above, formal verification aims at proving universal properties of the IXL system, i.e. properties that must hold in all executions. More specifically, we focus mainly on railway safety requirements of the system, which ensure that no harmful situation can occur in operation, and which from the formal point of view can be characterised as invariant properties.

Similarly to the case of testing, we distinguish two main verification activities: (i) verification of the generic, uninstantiated IXL logic, independently from the specific configuration, and (ii) verification of a specific instantiation IXL[\( cfg_i \)] of the logic for a given station/application. Although ideally the ultimate goal is being able to verify the IXL logic at the generic level, it is important to highlight that the two approaches provide different trade-offs and strengths. Verification of a specific instantiation of the logic is a conceptually simpler problem, which can in principle be reduced to standard model checking and/or program analysis amenable to a high degree of automation. On the other hand, the obtained verification results might not be easily reusable across different configurations; moreover, the large size of the configurations corresponding to realistic stations might be a significant hurdle for scalability in practice. In order to tackle such challenges, we are investigating domain-specific abstraction techniques for reducing the complexity induced by the IXL instantiation on specific configurations, and for reusing verification results across similar instantiations (such as property decomposition, symmetry detection, and domain-specific slicing/cone of influence reduction methods).

One obvious advantage of performing verification at the generic level is the fact that the results do not depend on any specific configuration. However, generic verification is significantly more challenging than verification of specific configurations already from the conceptual point of view. Formally, the problem can be formulated as verification of parameterized systems. Differently from most settings considered in the literature though, in which typically the focus is on communication protocols and/or distributed systems consisting of processes arranged in a fixed and known topology, in this case the topology is not known a priori, but part of the configuration space. Moreover, the size of the (parametric) system to analyse is significantly larger than what normally considered by automatic approaches. Therefore, in practice rather than a fully automatic solution, we aim to investigate hybrid approaches, combining the use of interactive theorem provers, code annotations and contract-based decompositions for defining the overall verification strategy, coupled with automatic model checkers for parameterized systems (such as e.g. [9, 10]) for discharging individual verification conditions.

6 Tool Qualification and Certification

Ensuring the correctness of the sequence of transformations that produce the IXL code from the FRS requirements is critical for the trustworthiness of the whole toolchain. In fact, the regulations for safety-critical systems such as railway interlockings mandate the use of qualified toolchains, whose correctness has been certified/validated according to some procedures established by law. In our context, this can be achieved via several different approaches: (i) formal verification of the translator itself, (ii) formal verification of the correctness of the translations, or (iii) validation of the translations by comparing independent implementations of the toolchains. While in principle more appealing, approaches (i) and (ii) would require a significant effort of several man-years, making their cost prohibitive. Moreover, they would require a full formal specification of the translation procedures and the CNL semantics, which do not currently exist, and which would be far from trivial to produce. Therefore, we are currently working towards option (iii), by developing a methodology to allow to perform formal proofs of equivalence of two independent translations using automated program analysis techniques, leveraging domain knowledge on the specific syntactic structure of the inputs and outputs of the translation steps in order to aid the semantic analysis of the equivalence of the two independent translation results.

7 Dealing with Legacy

The need to relate the current, relay-based interlocking technology and the new, computer based interlocking solution, poses several challenges.

The first one is the digitalization of legacy relay circuit diagrams, that is supported by the tool NORMA [1]. NORMA provides the user with the ability to create a digital model, covering the whole space of electrical components adopted in relay-based interlocking systems. The schematics are then converted into a format that is amenable for the simulation and formal verification using the underlying nuXmv [7] model checker. The resulting models are extremely large and need an expressive representation, and compositional methods will be investigated to increase the capacity of the formal verification even further.

Another important challenge is to provide automated support for the extraction of models from design documents and schematics. This informal-to-formal conversion is currently being investigated with the integration of image recognition based on deep learning and background knowledge at the symbolic level.

Once a formal representation is available, and its properties have been validated, the analyst needs to be supported in the comparison of the behavior of the legacy relay-based system with that of the new digitalized IXL system. On the one side, it is possible to generate test suites that are covering for the relay-based system and that can be expected to properly stimulate the computer-based design. More interestingly, the relay-circuit model is expected to provide the reference behavior for the computer-based solution. However, the two semantics are hard to harmonize: while the computer-based solution has a cycle-based semantic, the relay-circuit model implements a run-to-completion semantics. For this reason, we are actively investigating the problem of extracting from the relay circuits an abstract view that “absorbs” the unstable states and provides for properties to be satisfied by the computer-based solution [1, 4,5,6].

8 Conclusions

In this paper we described the challenges deriving from the development of a formal framework for the design of interlocking systems. These include: the ability to support the signaling engineers with a structured natural language, that combines high usability and a well-defined execution semantic; the traceability between levels of abstraction, and the reconciliation of the exectutions for the legacy and new technology; the definition of suitable testing techniques, and the effective integration of formal verification methods and tools; the qualification of the tools, with particular reference to the correctness of the compiled code.