Formal Development for Railway Signaling Using Commercial Tools

Abstract

This report presents the approach experimented by a railway signaling manufacturer for the development of applications through Simulink/Stateflow in a standard-regulated industrial framework. The General Electric Transportation Systems (GETS) railway signaling division of Florence, inside a long-term effort of introducing formal methods to enforce product safety, decided to adopt the Simulink/Stateflow tool-suite to exploit model based development and code generation within its own development process [1]. Products traditionally provided by GETS, like any railway signaling application developed for Europe, shall comply with the CENELEC norms [2]. Introducing the Simulink/Stateflow tool-suite within a CENELEC based process is not a straightforward step, and GETS faced two crucial obstacles: the lack of a formal semantics for the Simulink/Stateflow languages, and the absence of a CENELEC compliant code generator. The languages used by Simulink and Stateflow are not formally specified and their semantics is essentially given by the simulation engine itself. This increases the difficulty of defining an effective formal verification strategy, a highly recommended practice according to the CENELEC norms. Code generators provided for the tool-suite (in particular Stateflow Coder) are not certified for railway software development, this complicating their adoption in this domain. In order to defeat these problems, GETS first introduced a set of modeling guidelines to restrain the semantics of the tools [3]. The idea is based on the intuition that reducing the Simulink/Stateflow languages to a semantically unambiguous subset enables proper code synthesis and formal verification. Once developed this set of modeling rules, a proper strategy including formal development , model based unit testing and formal verification of modules has been defined. Given a set of system-level functional requirements, these can be partitioned into separate sets of unit requirements and then formalized into Stateflow models according to the GETS guidelines. Each model represents an independently verifiable system component. Unit testing based on requirement coverage is then performed on the models through the Simulink environment, and during test execution a test observer is used to register the test-suite input data and the test results. The registered test-suite is executed on the auto-coded unit and results are automatically compared. Finally, the module is analyzed through the

Adoption of Model-Based Testing and Abstract Interpretation by a Railway Signalling Manufacturer

“…The code generated from these models was about 150 KLOC in total. The highest cyclomatic complexity reached was about 60, and some functions showed more than 700 paths 7 : A set of modelling guidelines was introduced to disambiguate Stateflow semantics and to achieve the compliance of the code to the CENELEC standards and to the internal company code guidelines (Ferrari, Fantechi, Tempestini, & Zingoni, 2009). Automatic code generation led to the necessity of new verification techniques: the increased complexity of the control flow made impossible the use of former methods based on structural testing aimed at obtaining full path coverage.…”