A Story About Formal Methods Adoption by a Railway Signaling Manufacturer

Lecture Notes in Computer Science

Gnesi

2011

Self Cite

Abstract. In the last fifteen years, model checking has been applied successfully in the design and verification of many safety related software systems. However, it is not yet routinely adopted in the industry of safety-critical systems. In this paper we introduce the model checking technique and its relations to safety; then we survey the sensible areas of research related to the current and potential industrial application of this technique, exploring the current trends, that in our opinion will bring to a wider adoption of model checking in the next years.

Section: Model Checking Within Model Based Designmentioning

confidence: 99%

On the Adoption of Model Checking in Safety-Related Software Industry

Lecture Notes in Computer Science

Gnesi

2011

Self Cite

“…MBD practices consist in developing abstract models of the system and automatically generate code from these models. GETS employed MBD first for the development of prototypes [1], and afterward for requirements formalization and code synthesis [2]. Traditionally, unit testing is the main technique adopted to detect errors in the code before integration 1 .…”

Section: Introductionmentioning

confidence: 99%

“…GETS employed MBD first for the development of prototypes [1], and afterward for requirements formalization and code synthesis [2]. Traditionally, unit testing is the main technique adopted to detect errors in the code before integration 1 . With unit testing the code is exercized by executing it and ensuring that its behaviour is compliant to the requirements.…”

Section: Introductionmentioning

confidence: 99%

“…Unit testing activities normally require a high cost, and, on the other hand, they do not ensure that the software is completely free from errors, since exploring all the possible behaviours of the code is practically unfeasible by means of testing only. 1 Extensive testing is performed on the integrated system before the actual deployment, but we consider system testing out of the scope of this paper.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Model Based Testing and Abstract Interpretation in the Railway Signaling Context

Grasso

2010 Third International Conference on Software Testing, Verification and Validation

Ferrari³

et al. 2010

Self Cite

“…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].…”

mentioning

confidence: 99%

Formal Development for Railway Signaling Using Commercial Tools

Ferrari

Formal Methods for Industrial Critical Systems

Bacherini

et al. 2009

Self Cite

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