A hybrid model-driven approach for development and testing of an

tesi di laurea
A hybrid model-driven approach for development
and testing of an ETCS component
Anno Accademico 2014/2015
relatore
Ch.mo Prof. Dr. Stefano Russo
correlatori
Ch.mo Ing. Baseliyos Jacob DB Netz (D)
Ch.mo Ing. Fabio Scippacercola
candidato
Valerio D’Angelo
matr. M63/156
Contents
Introduction
8
1 Background on Model-Driven methodologies
11
1.1
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2
Model Driven Architecture
. . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1
MDA Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2
OMG Metamodel Infrastructure . . . . . . . . . . . . . . . . 15
1.2.3
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3
Requirements and Traceability . . . . . . . . . . . . . . . . . . . . . 18
1.4
A modeling language: SysML . . . . . . . . . . . . . . . . . . . . . . 19
1.5
Model Driven Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Background on ETCS standardization
23
2.1
Introduction to ETCS\ERTMS . . . . . . . . . . . . . . . . . . . . . 23
2.2
ETCS and ERTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3
System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4
2.3.1
Track-side equipment . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2
On-board equipment . . . . . . . . . . . . . . . . . . . . . . . 28
ETCS Modes and Levels . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.1
ETCS Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.2
ETCS Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1
3 Modeling and verification in the railway domain
3.1
36
Model-Driven Engineering of ETCS components . . . . . . . . . . . 36
3.1.1
OMG-based approach: Model-Driven Engineering of a Railway Interlocking System . . . . . . . . . . . . . . . . . . . . . 38
3.1.2
3.2
Non OMG standard approach: OpenETCS . . . . . . . . . . 41
A hybrid approach to MDE of ETCS components . . . . . . . . . . . 45
3.2.1
Model-driven design . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2
Model-driven testing . . . . . . . . . . . . . . . . . . . . . . . 47
4 Case study: ETCS Driver Machine Interface
51
4.1
DMI System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2
DMI Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3
DMI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4
4.3.1
DMI Controller Interface . . . . . . . . . . . . . . . . . . . . 59
4.3.2
System Architecture . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.3
Executable Model Design . . . . . . . . . . . . . . . . . . . . 64
Model-in-the-Loop Testing . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.1
Graphical Test Panel . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.2
CIT architecture . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4.3
Test script and model coverage . . . . . . . . . . . . . . . . . 82
4.4.4
Traceability and impact analysis . . . . . . . . . . . . . . . . 83
Conclusion and Future Works
85
A SCADE tools
87
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.1 SCADE System . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.1.2 SCADE Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.1.3 SCADE Display . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.1.4 SCADE Rapid Prototyper . . . . . . . . . . . . . . . . . . . . 89
2
B Driver Machine Interface: User Stories
90
B.1 USER STORY 1A: Start of mission Initialization . . . . . . . . . . . 90
B.2 USER STORY 1B: Inserting of Driver ID and Train running number 91
B.3 USER STORY 1D: Validation of ETCS Level . . . . . . . . . . . . . 91
B.4 USER STORY 1E: End of Procedure . . . . . . . . . . . . . . . . . . 92
B.5 USER STORY 2A: Acknowledgement of SN Mode . . . . . . . . . . 92
B.6 USER STORY 2B: Acknowledgement of SN Mode . . . . . . . . . . 92
B.7 USER STORY 3A: Transition of ETCS level and Acknowledgement
required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.8 USER STORY 3B: Transition of ETCS level and Acknowledgement
required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.9 USER STORY 5: Ceiling Speed Monitoring . . . . . . . . . . . . . . 94
B.10 USER STORY 6: Target Speed Monitoring . . . . . . . . . . . . . . 94
B.11 USER STORY 7: Release Speed Monitoring . . . . . . . . . . . . . . 95
References
96
3
List of Figures
1.1
MBE, MDE, MDD end MDA . . . . . . . . . . . . . . . . . . . . . . 13
1.2
Four layers Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3
Model, meta-model and meta-metamodel relation . . . . . . . . . . . 17
1.4
MDA Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5
Impact analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.6
SysML Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1
Legacy railway control-command systems in Europe . . . . . . . . . 24
2.2
ERTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3
ETCS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4
ETCS Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5
ETCS Level STM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6
ETCS Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7
ETCS Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8
ETCS Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1
The proposed model-driven V-Model . . . . . . . . . . . . . . . . . . 39
3.2
Main steps of OpenETCS process . . . . . . . . . . . . . . . . . . . . 42
3.3
Process for handling specification issues . . . . . . . . . . . . . . . . 47
3.4
V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5
Model-in-the-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6
Model-in-the-Loop process . . . . . . . . . . . . . . . . . . . . . . . . 49
5
4.1
Train cab fitted with ETCS . . . . . . . . . . . . . . . . . . . . . . . 52
4.2
Aweakness of the train in Level NTC . . . . . . . . . . . . . . . . . . 53
4.3
Block Definition Diagram - On Board Unit . . . . . . . . . . . . . . 54
4.4
Internal Block Diagram - On Board Unit . . . . . . . . . . . . . . . . 55
4.5
Internal Block Diagram - Driver Machine Interface . . . . . . . . . . 56
4.6
The layout of the ETCS DMI . . . . . . . . . . . . . . . . . . . . . . 57
4.7
Example of ETCS DMI . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8
Layout of a Data entry window (half grid array) . . . . . . . . . . . 60
4.9
Layout of a Data validation window (total grid array) . . . . . . . . 60
4.10 Block Definition Diagram - DMI Controller . . . . . . . . . . . . . . 63
4.11 Open/close Desk diagram . . . . . . . . . . . . . . . . . . . . . . . . 65
4.12 Icon acknowledgement mechanism . . . . . . . . . . . . . . . . . . . 66
4.13 Nested if-block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.14 Menu management model . . . . . . . . . . . . . . . . . . . . . . . . 69
4.15 Main menu controlled by the Driver . . . . . . . . . . . . . . . . . . 70
4.16 Text Messages model . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.17 Boolean activator for ETCS Level
. . . . . . . . . . . . . . . . . . . 72
4.18 Train Data storage and update State Machine . . . . . . . . . . . . . 75
4.19 Train Data adapter operator
. . . . . . . . . . . . . . . . . . . . . . 75
4.20 Train Data confirmation State Machine . . . . . . . . . . . . . . . . 76
4.21 Overview of objects in the Planning Area . . . . . . . . . . . . . . . 76
4.22 CIT Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.23 Example of running test scenario . . . . . . . . . . . . . . . . . . . . 79
4.24 If-Block for test scenarios . . . . . . . . . . . . . . . . . . . . . . . . 80
4.25 Logic of test scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.26 Example of test scenario State Machine . . . . . . . . . . . . . . . . 82
4.27 Coverage report of operators . . . . . . . . . . . . . . . . . . . . . . 83
4.28 Traceability Three . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6
List of Tables
4.1
From DMI Manager to DMI Controller . . . . . . . . . . . . . . . . . 62
4.2
From DMI Controller to DMI Manager . . . . . . . . . . . . . . . . . 62
4.3
Two ways direction packet . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4
Truth table that defines the color of the speed pointer . . . . . . . . 73
4.5
Truth table that defines the colours of the Speed gauge
4.6
Thruth table that defines the Distance to Target display conditions . 74
7
. . . . . . . 74
Introduction
In the last years, the complexity and pervasiveness of software in society is growing
exponentially, as well as the request of safety-critical software. The choice of the
right development process suitable for projects with security requirements may be
crucial for its success. Factors like strict European standards, high quality required
by customers and, last but not least, time to market constraints, may contribute to
the high complexity of systems. Nowadays, one effective technique to handle the
complexity is to raise the level of abstraction by means of models: the state of the
art of software engineering are the model driven approaches.
Abstraction, is the process of taking away or ignore characteristics of some
phenomena in order to reduce it to a set of essential characteristics. In software
engineering, it means understand the problem domain and describe it by models, considering only necessary elements. In other words, the abstraction process
requires the separation of the essential from the non-essential. Obviously, the
non-essential is not less important, but ignoring it allows to reduce the complexity.
A model is a representation of a system or a phenomenon, expressed in a formal
language, highlighting only the essential aspects. It represents the principal means
to perform abstraction.
In a model-based approach, the models are used to support the development
activities and processes mainly for documentation scope (document-centric). In
a mode-driven approach, models are the key artifacts, they can be transformed
into other models or in an executable code. The documentation can be gener8
ated through automatic report mechanisms (model-centric). The Object Management Group (OMG) has provided a standardization of a model-driven methodology
called Model Driven Architecture (MDA). MDA aims to improve several aspects of
the development process such as portability, interoperability and productivity but
in some context such as the railway domain, where processes and methodologies
are well rooted, the introduction of a new approach is not simple.
This thesis proposes to suggest a hybrid model-driven approach supporting the
development and testing phases in the railway sector. The term hybrid means an
approach that involves: a) methodologies and techniques standardized by OMG, b)
tools and formalisms not belonging to any standard. Therefore, this work has been
carried out analysing several approaches and methodologies present in literature
and its feasibility has been demonstrated through a case study.
The case study was carried out at the Deutsche Bahn Netz AG, Munich (Germany), within the OpenETCS1 project, during the six-month internship.
OpenETCS is an European project that aims at providing the formal model of
the European Train Control System (ETCS) system, the source code of the ETCS
software and the tool chain necessary to develop and verify them [13]. Many companies of railway sector are part of the this project and contribute to develop the
ETCS framework. This work provided the opportunity to cooperate with industry experts, improving the knowledge of these complex systems and flattering the
learning curve.
Thesis structure
The thesis is structured in five chapters and two appendices. The first chapter gives a background about model-driven methodologies, clarifying the different
acronyms and approaches. A focus on the OMG Model-Driven Architecture (MDA)
is given, highlighting the main aspects.
1
www.openetcs.org
9
Chapter two introduces the ETCS standard, the motivation behind its dissemination and a brief description of the system architecture, highlighting the principal
components.
An overview of different processes regarding the model driven approaches is given
in chapter three, describing in particular a OMG-based approach proposed by a
research team of Università degli Studi di Napoli Federico II and a non-standard
approach applied in the OpenETCS project. Finally, the hybrid approach proposed
by the author is shown.
Chapter four is the case study, it provides all the details about the work, the
implemented functionalities, design choices and the testing activity.
The last chapter gives some considerations about the proposed approach, evaluating the positive and negative aspects and eventually changes may be useful to
improve it.
10
Chapter 1
Background on Model-Driven
methodologies
Model-Driven Engineering (MDE) is a software engineering approach that promotes the usage of models and transformations as primary artifacts [15] and today
represents the state-of-the-art of software development techniques. MDE has been,
in the last years, object of great attention and has become popular in industry as a
way to cope with the increasing complexity of systems, reduce the time to market
and costs, last but not least, improve the quality of software, especially in safetycritical sectors. Model-driven approaches are based essentially on two key concepts:
models and transformation. Models are the principal mean to describe the system
or a specific aspect of it, whereas transformations, through well defined syntax and
rules, provides a support to refine models and obtain the final executable code.
Models assume a central role (model-centric) in the process, they are used as
a common language between customers and providers and describe the system at
different levels of detail. Documents assume a marginal role in model-centric processes, since they are derived from modules using transformations, often automatic.
The basic idea is that ”...model is the representation of something, whereas the document is a report on something”[5] and brings, as positive aspects, traceability of
11
artifacts, consistency of informations and an improvement of the maintenance.
1.1
Terminology
There are a lot of acronyms in software engineering to indicate a wide variety of
model-based/model-driven techniques. This section provides a brief clarification.
Model Driven Architecture (MDA)
It’s an approach defined from Object
Management Group (OMG) formalized in 2003. The core concept is "everything
is a model" [20]. MDA is a specification that provides a set of guidelines for
structuring specifications expressed as models[wikipedia] and can be considered a
particular version of MDD.
Model Driven Development (MDD)
Was defined at the beginning of 2003,
it is a development paradigm where models play a central role. The main difference
between MDD and MDA is that MDD doesn’t specify any standard.
Model Driven Engineering (MDE)
MDE can be considered as a superset
of MDD, it doesn’t refer only to the development phase but to the whole process
and activities. Model-driven engineering technologies offer a promising approach
to address the inability of third-generation languages to alleviate the complexity
of platforms and express domain concepts effectively [16].
Model-Driven vs Model-Based
There isn’t a big difference meaning and of-
ten are used as synonymous. Model-Based refers to a set of approaches in which
models assume a central role and do not represent the key artifacts of the development process. For instance, in a model-based project the code generation could
be performed manually, instead, in a model-driven approach the model ”drive” the
development process. In conclusion, a Model-Based approach could be considered
as a superset of a Model-Driven approach [3] (Fig. 1.1).
12
Figure 1.1: MBE, MDE, MDD end MDA
1.2
Model Driven Architecture
For eleven years, the Object Management Group (OMG) has focused on making
sure that you can integrate what you’ve built, with what you’re building, with what
you’re going to build. [Richard Soley]
As touched on in the previous section, MDA is a specific version of MDE standardized by the OMG, it was born mainly to overcome the interoperability issues
but, unlike Object Management Architecture (OMA) and CORBA, it is not a
framework for implementing distributed systems, but an approach to use models
in software development [10] exploiting the OMG specifications such as the Unified Modeling Language (UML), Meta Object Facility (MOF) and the Common
Warehouse Metamodel (CWM). MDA addresses the complete software lifecycle
like: requirements analysis, design and testing. Below are listed the main goals of
this approach:
• Portability and Integration: a better migration capabilities into new environment and platform to satisfy the business needs and easier integration
of legacy systems. New technology simply means new transformation rules.
• Quality: the consistency and reliability of the models contribute to the
enhanced quality of the whole system
13
• Documentation and Maintenance: models are the documentation, this
imply an automatic handling of consistency. The human-readable nature of
the models, gives all the members involved in the project, a direct access to
the specification of the system, then an easier overview of the project.
• Testing: models can be easily validated against the requirements and also
can be used to simulate the behaviour of the system, improving the failure
detection.
• Productivity: developers focus more resources on the core logic of the system, avoid dealing with tedious tasks. Every phases of the process directly
contributes to the product, not just to the implementation.
Four principles underlie the OMG’s view of MDA[2]: first of all models expressed
in a well-defined notation are a cornerstone to understand systems for enterprisescale solutions. The development of systems can be organized around a set of
models by imposing a series of transformations between models, organized into
an architectural framework of layers and transformations. A formal underpinning
for describing models in a set of metamodels facilitates meaningful integration
and transformation among models, and is the basis for automation through tools.
Finally, acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, and foster competition among
vendors. To apply these principles, OMG has specified a set of layers and transformations that form the framework and vocabulary for MDA.
1.2.1
MDA Models
MDA specifies three different models to describe a system, each one with a different
degree of abstraction: Computation Independent Model (CIM), Platform Independent Model (PIM) and Platform Specific Model (PSM).
14
Computation Independent Model
CIM is a representation of the system, without implementation details. The aim of
this model is to clarify what the system is expected to do. CIM is usually a UML
model and necessary to fulfil the gap between the domain experts and designers.
In the MDA specifications a traceability between CIM and PIM should exist.
Platform Independent Model
PIM has a deeper degree of details regarding the business functionality still with
a platform independent viewpoint. The systems structure is well know, with a
good level of details. PIM exploits a technology-neutral virtual machine to achieve
a complete platform independence. A virtual machine consists in a set of parts
and services (communications, scheduling, naming etc.) which are independently
of any specific platform [10].
Platform Specific Model
PSM is indispensable for the implementation of the system, it combines the specifications in the PIM and the details of a particular platform to provide a mapping
between them. Generally at this level the technology is specified, and the PSM
should have been enough informations to allow code generation.
1.2.2
OMG Metamodel Infrastructure
An important concept dealt in the MDA approach is meta-modeling, standardized by OMG. A metamodel is a special kind of model that specifies a language
for expressing a model, in other words, is a model of a modeling language. This
concept is fundamental to enable (automatic or semi-automatic) transformation of
models (M2M) or Model-To-Text (M2T). The OMG standard defines a structure
of four layers each one with a greater level of abstraction (Fig. 1.2).
15
Figure 1.2: Four layers Infrastructure
• M0: It’s the layer with the lowest level of abstraction, here are placed the
concrete objects of the problem domain.
• M1: Here are located the models that abstracts the real data, the system
through UML language (classes or associations).
• M2: Begin the real metamodel concept. Here is defined, through UML, the
syntax of UML models used in M1. With the rules here specified it’s possible
to perform the consistence check of M1 models.
• M3: It’s the layer with the highest level of abstraction, here is defined the
Meta-Object Facility (MOF) language. By MOF can specify syntax and the
semantic for metalanguage, enabling the definition of transformation rules
among different models belonging to M1 layer and compliant to metamodel
of M2 layer.
A model conforms to a language whose abstract syntax is represented by a metamodel, means the model is conformed to the metamodel, analogously for metamodel
and meta-metamodel (Fig. 1.3).
1.2.3
Mapping
In a MDA project the PIM model assumes a central role. This model can be
transformed in one or more model specific platform such as Enterprise Java Beans
16
Figure 1.3: Model, meta-model and meta-metamodel relation
Figure 1.4: MDA Pattern
(EJB), OMG CORBA etc. It’s easy to understand that the key concepts of MDA
process, are models and transformations. The aim of MDA is to automate as
much as possible the transformation process and it is possible only with a well
defined mapping mechanism (Fig. 1.4). Mapping provides specifications to transform a PIM to PSM. There are different approaches like Model type mapping and
Model instance mapping. The first one specifies how to transform types, used in
PIM mode, in types used in PSM model. The second one exploits the Marks.
Latter can be viewed as an overlay (or transparency) placed over the PIM [4],
specifies how marked element in the PIM has to be transformed, hence contains
information about target platform. The final step in a transformation process is
the code generation. This phase is considered one of the most critical aspect of the
17
whole process, also in this phase, a well-defined specifications play central role and
strongly depend on the quality of the tools. Generally, these tools support a fully
automatic transformations, so the designer doesn’t need to know any details about
the programming language. The generated code has to be generally well structured
and readable, because in the most of cases, needs to be integrated with additional
informations.
1.3
Requirements and Traceability
Traceability is the ability to establish relationship between two or more artifacts
of a development process. It’s fundamental to bind models with the related requirements and improve the readability of the project. As discussed in previous sections,
models, in a model-driven approach, play a central role, often they are generated
automatically or semi-automatically (PIM to PSM) and during this process, hence
the traceability is considered an necessary characteristic. In a document-centric
process, models are considered only as documentation artifacts, traceability isn’t
automatically included in the development process. In a project, an information
can appears in multiple places and if it changes, the designer needs to update the
information overall the project (manually). Since complex systems, usually, are
generated a huge amount of document, traceability can be very hard to manage
and often it leads inconsistency problems.
Another aspect that should be considered in a model-driven process is the
importance of requirements: without effective requirements engineering, development projects are like ships drifting rudderless in a storm! [7]
This citation well explains the importance of having a good quality of requirements.
The problem of requirements are closely related with the traceability, in fact, in a
model-driven process, a lot of models are generated, each one contributes to realize
and cover one of more requirements. Hence, traceability is fundamental for the
following reasons:
18
Figure 1.5: Impact analysis
• Binding between models and requirements.
• Requirements coverage;
• Impact analysis
The first point helps to better understand the meaning of a model, in other words,
what the model does. The second point means the traceability can be exploited as
roadmap to know the actual progress status of the project (how many requirements
are left). Finally, last point is important for the maintenance. It is not unusual
a requirement changes during the software development, due different needs of
stockholders or a modification of the system environment. In these situations, a
designer can exploit the traceability among the artifacts to evaluate which models
are involved and which impact will have in the project. The figure (Fig. 1.5) gives
an idea about this concept.
1.4
A modeling language: SysML
A modeling language is a semi-formal language that defines the kinds of elements
you’re allowed to put into your model, the allowable relationships between them,
and-in the case of a graphical modeling language-the set of notations you can use
to display the elements and relationships on diagrams [6].
19
Figure 1.6: SysML Taxonomy
The choice of a modeling language is the first important step in a model-driven
process. There are different types of graphical languages each one with its own
purpose. SysML (System Modeling Language) is one of them. SysML is a subset
(or dialect, profile) of UML and is considered a standard de facto, a lingua franca
for Model-Based System Engineering (MBSE).
SysML introduce the concept of block as the basic structure and offers nine
diagrams, figure 1.6 shows the hierarchy structure. The following list gives a brief
description of each diagram:
• Block definition diagram (BDD) used to show the system hierarchy tree,
the structure and the relationship between those elements.
• Internal block diagram (IBD) used to specify the internal structure of a
single block, showing the connection between the internal parts.
• Use case diagram has the same meaning of UML Use Case diagrams where
the services of the system are considered in a black box view.
• Activity diagram is used to express the behaviour of the system such as
20
sequence of actions.
• Sequence diagram is used to describe the behaviour through exchange of
signals or messages between modules.
• State machine diagram is used to describe the behaviour through the
states that a system can assume and it possible transitions.
• Parametric diagram is used to express one or more constrains to the proprieties of a system.
• Package diagram is used to organize the system in terms of package, show
dependencies between them and their contained model elements.
• Requirements diagram is used to specify text-based requirements and the
relationship with models or others artifacts that satisfy or test them.
1.5
Model Driven Testing
Model-driven techniques have changed not only the way to develop software but
also the testing manner. The basic idea is to develop test cases exploiting the
models defined during the software development process. Model-Driven Testing
(MDT) aims increasing productivity and quality. There are several model-based
testing techniques and tools, each one with own peculiarity. However, to achieve a
good gain in terms of productivity, test cases and test scripts should be generated
automatically or semi-automatically, than a formal language such as UML Testing
Profile (UTP) is mandatory. UTP is a standardized language based on UML
created by OMG. It is very flexible and it can be combined with other UML profiles,
so that test cases can be associated with other relevant system artifacts [11].
In the last ten years a lot of literature has been produced around the Model
Driven Testing. As mentioned previously, MDT represent a set of techniques each
one with different test target, for instance, several techniques provide a testing on
21
abstract UML design models, others only on implementation units or some other
on the complete system. The paper [12] presents an interesting discussion about
15 model-driven testing techniques demonstrating the great variety of different
approaches. In this work will show the Model-in-the-Loop testing adopted in the
case study as failure detection technique.
22
Chapter 2
Background on ETCS
standardization
2.1
Introduction to ETCS\ERTMS
Today, a train crossing from one European country to another has to be equipped
with several Automatic Train Protection (ATP) and switch the operating standard
properly as it crosses the border. The national ATP systems needs a lot of space
on-board and it also adds maintenance and operational costs. Only in Europe
exist more than 20 train control systems (Fig. 2.1) often incompatible with each
other in terms of electricity voltage, communication protocol, signalling, operating
rules etc. Sometimes, it is necessary changing locomotive or the driver at frontiers
because generally each country has its own signalling rules and local regulations for
which the drivers have to be trained. For this reason, the European Transport
minister started in the 1980s to formulate a strategy to develop a single train
control system standard to apply across Europe. Unifying of the railway control
systems aimed a) to provide a better interoperability, b) improve the quality of rail
transport services and last but not the least c) costs reduction thereby enhancing
the competitiveness. In December 1989 a group of railway sector experts started to
23
Figure 2.1: Legacy railway control-command systems in Europe
formalize the requirements specification of European Train Control System (ETCS)
to consider as base for industrial development. The project framework covered all
aspects of a railway system, including both a new on-board unit architecture and a
continuous (EURORADIO) and discontinuous (EUROLOOP and EUROBALISE)
system for data transmission. In the summer of 1998, UNISIG, comprising the
European Signaling companies was formed to finalise the specifications and the
System Requirements Specification (SRS) documents was delivered. Finally, in
July 2009 becomes transaction to ETCS standard for several listed high-speed
lines mandatory with deadlines ranging from 2015 to 2020. Not only in Europe
but also in countries such as China, Taiwan, South Korea, India, Algeria, Libya,
Saudi Arabia, Mexico, New Zealand or Australia have launched a ETCS investment
programs, probably in the future will become a worldwide railway standard.
2.2
ETCS and ERTMS
European Railway Traffic Management System (ERTMS) is the new generation
concept of train control and signalling for European railway system, include many
parts: the track-side system, train-borne system, in-cab signalling and European
24
Figure 2.2: ERTMS
ATP system (ETCS). Often ERTMS, ETCS or ETCS\ERTMS are terms used
as synonymous but the ETCS refers to the train control system instead GSM-R
(Global System for Mobile Communication - Railways) covers the radio system
for data and voice communication. Therefore, ERTMS is the joining of ETCS
and GSM-R and represents the new signalling and traffic management system that
improves the interoperability throughout the European railway network (Fig. 2.2).
2.3
System Architecture
"The European Train Control System (ETCS) is a signalling, control and train protection system designed to replace the many incompatible safety systems currently
used by European railways, especially on high-speed lines.[21]"
As mentioned previously, ETCS is a ATP system, it is divided in two parts: ETCS
on-board equipment and ETCS track-side equipment. The figure 2.3 shows
a overview of a complete ETCS system.
25
Figure 2.3: ETCS Architecture
26
2.3.1
Track-side equipment
The track-side equipment provides control signalling both in intermittent and continuous way through Balises, Euroloop and Radio Block Centre (RBC). Following a brief description of track-side components:
• Balise: is an electronic device or transponder placed between the rails. Generally needs no external power supply because it’s activated by radio frequency energy through a Balise Transmission Module (BTM) mounted generally under the locomotive by passing train. When the train passes over the
balise the BTM receives informations (Uplink) or sends informations (Downlink) in a sufficient rate to complete a telegram. The typical informations of
a telegram are: the permitted speed, location of the balise, gradients, curves
etc. Balises are organized in groups of maximal eight elements, each one is
identified by a unique ID. The balise group (BG) is useful to determine the
train direction through recognizing of ID order.
• Euroloop: is a semi-continuous data transmission system, consists of a coaxial cable with a resistor at the end placed along the rails, a Loop Module Transmission (LMT) mounted on the train and several track-side signalling systems such as Lineside Electronic Unit (LEU) an analogue-digital
converter. This system is able to transmit telegram to train (Uplink) continuously through electromagnetic waves emissions and is considered an extension
of balise, in fact the telegrams structure is the same as used by balises.
• RBC: The Radio Block Centre represent the heart of ETCS system. It’s
located with other signalling and control equipment systems and is able to
send and receive message through radio frequency to\from on-board unit
of a train. These messages are transmitted via GSM-R data radio. Each
transmitted\received messages consist of one or more data packets with the
same structure as used by balises. The RBC is able to exchange a great
27
variety of informations like Movement Authority (MA), position of the train,
track description, validation of train data etc.
2.3.2
On-board equipment
The on-board equipment also known as On-Board Unit (OBU) comprises all devices
and technology placed inside the train that computes all the informations received
by the track.
Train Interface Unit (TIU)
is the interface by which ETCS controls the main
functions of the train, include the following:
• Braking system of the train, both service (not safety-critical) and emergency
brake (safety-critical).
• Train control, to command the change of traction, raising and lowering of
pantograph on the roof and the air tightness.
• Engine control, to cut the traction power when either the service brake or
emergency brake is activate.
• Cab status, includes the determining the position and check the status of the
cab desk (open or closed).
European Vital Computer (EVC)
is the most critical element of the ETCS
on-board equipment. It receives all the inputs from trackside, odometry, stored
informations, from display by the driver etc. and provides supervision of the train
movements. Provides outputs to the driver, the train braking system and eventually
sends information back to RBC. In other words is an on-board computer which are
processed the trainborne functions in safety mode.
Driver Machine Interface (DMI) is a in-cab display, located in a prime position on the on-board desk. The DMI represents the main means of interaction
28
between the driver and the train. It shows all informations regarding the status
of the train such as instantaneous speed, permitted speed, target speed, release
speed, messages etc. according to ETCS notation (colours, font-ize, font-style and
position). A special focus will be given in chapter tot.
Odometry provides both distance and speed informations, interacts directly
with EVC. It consists by more then one mechanism, such as tachometer, speed
radar etc. EVC uses these informations to calculate train speed and position with
a high grade of accuracy.
Balise Transmission Module (BTM) is connected with the balise reader and
EVC, represents the interface to transfer telegrams to and from trackside properly.
Loop Transmission Module (LTM) is connected with the Euroloop antenna
and EVC, represents the interface to transfer the telegram to and from trackside
properly.
Euro Radio is the component used to exchange informations with RBC via
GSM-R radio.
2.4
ETCS Modes and Levels
ETCS supervises constantly the train to ensure that it doesn’t exceed the velocity
that it has permission, doesn’t travel further than permitted in other words controls
all the trip to ensure the safety. The degree of supervision depends on the ETCS
Level and the ETCS Operating Mode.
2.4.1
ETCS Levels
ETCS offers 5 different degree of supervision, following sections will give a brief
description.
29
Level 0 and STM
Level 0 is a transition level, it covers the scenario in which the train is ETCS-fitted
and the track not yet or is coming soon, then the infrastructure exist but ignored.
The driver is in charge to ensuring that the train doesn’t travel further than the
Movement Authority (MA)(Fig. 2.4). The ETCS DMI provides only a speedometer
display and the train is able to respond to any level change instruction received
from Balises. Line-side optical signals or other means of signalling are used to give
movement authorities to the driver [19].
Figure 2.4: ETCS Level 0
In Level STM (or National Train Control, NTC) the national system
is used, through the STM module the ETCS DMI is able to provide some or all
information for the driver and ETCS TIU provides the train interfaces required
by the national system. In this way, is not necessary to install separate national
train protection system, the switching is under software control(Fig. 2.5). Line-side
optical signals are not mandatory, depending on the underlying national system
[19].
Level 1
It Is based on intermittent track-to-train communication, used as an overlay on an
underlying signalling system. The Movement Authorities are transmitted to the
train via Eurobalises and the track-side equipment doesn’t know any information
30
Figure 2.5: ETCS Level STM
about the train. The driver has to observe the line-side signalling and it receives
new information only if a balise group is passed. A variant of Eurobalise can be
used at this level, using Euroloop or radio infill. In this way the on-board system
will be able to show new informations as soon as available through DMI display,
improving the safety if Level 1 (Fig. 2.6).
Figure 2.6: ETCS Level 1
Level 2
The main innovation of Level 2 is the radio based train control system (RBC).
Now the communication is continuously via GSM-R radio frequency. This system
is able to do safe operation in higher speeds, and provides an instantaneous update
of MA, than the Eurobalises are used only as passive positioning beacons no more
to report gradient and speed profile or distance to go. During the trip, the trains
report their exact position and direction directly to the RBC. Level 2 is able to work
31
with or without line-side signalling. The on-board unit has a list of balise groups
that the train will pass. It exploits this information to a) confirm that the train
is travelling in the preselected route, b) confirm that the odometry system works
with a good tolerance and c) reset the eventually stored odometry errors.(Fig. 2.7)
Figure 2.7: ETCS Level 2
Level 3
The architecture of Level 3 is very similar to the Level 2 but it works without
line-side signalling. Now the on-board equipment is responsible for train detection
by checking the integrity and reporting completeness to the track-side. The train
location is calculated by the odometry system on-board and reported to the trackside via GSM-R radio frequency. The interlocking no longer controls train spacing,
so the occupancy capacity of the track is improved. This solution provides a cost
reduction for the track-side systems, but this level is still under evaluation and not
yet applied.(Fig. 2.8)
32
Figure 2.8: ETCS Level 3
2.4.2
ETCS Modes
The ETCS on-board system has 15 different Operating Modes each one with a
distinct degree of supervision and protection but not all modes can be applied to
each ETCS Level, for more details [19].
• Full supervision: Mode for normal running with cab-signalling. Is entered
automatically, when all train track data, which is required for a complete
supervision of the train, is available on-board.
• Reversing: The driver is allowed to change the direction of movement of
the train while driving from the same cab.
• Trip: Is entered automatically, when the train passes its limit or end of
movement authority or in other critical situation.
• Post Trip: Shall be entered immediately after the driver acknowledges the
trip.
• Non Leading: Is defined to manage the ETCS on-board equipment of a
slave traction unit that is not remote controlled.
33
• Sleeping: Defined to manage the ETCS on-board equipment of a traction
unit that is remote controlled.
• Unfitted: Is used to allow train movements in areas that are not equipped
with functioning ETCS track-side equipment.
• STM National: Shall enable an STM to access (via the ETCS on-board)
the DMI, odometer, train interface and brakes.
• Isolation Mode: The ETCS on-board equipment is isolated from the other
on-board equipment/systems and physically isolated from the brakes.
• No power: The ETCS on-board equipment is not powered. It shall command the emergency brake.
• System failure: The ETCS on-board equipment shall switch to the System
Failure mode in case of a fault which affects safety. It shall permanently
activate the emergency brakes.
• On Sight: Is applied the full protection, including the MA bu t the difference
with Full Supervision mode is that the driver is now responsible for ensuring
the train can be brought to a standstill prior to meeting any obstacle. For
that scope the ETCS system supervises the train with a ceiling speed.
• Shunting: This mode is activated manually by the driver and is responsible
for the movement of the train. The ETCS equipment supervises the train
to a ceiling speed. It is possible to limit the distance travelled through a
distance limit or a balise group. Latter if the train passes over a balise it will
cause a train to trip.
• Stand By: This is the default mode of the on-board unit. The driver is able
to navigate in the DMI menus to perform the Start of Mission procedure or
check some informations.
34
• No Power: This mode is activated if no power is applied to th ETCS onboard equipment. A continuous emergency brake demand is made.
35
Chapter 3
Modeling and verification in
the railway domain
3.1
Model-Driven Engineering of ETCS components
The railway control system, such as ETCS/ERTMS standard, are complex systems
with safety-critical requirements. Model-Driven Engineering is becoming even more
popular in this domain to support a wide part of development and testing process,
and it represents an alternative way to cope the great complexity of these systems.
The standard EN50128, approved by CENELEC (Comitè Europèen de Normalisation Electrotechnique) and IEC (International Electrotechnical Commission),
provides the procedures and the requirements for any safety-related software for
railway control systems. EN 50128 specifies five levels to classify the degree of
safety performance of a function, this classification is called Safety Integrity Level
(SIL) and represent the core concept of the standard. The higher the risk resulting
from software failure, the higher the software safety integrity level will be. The levels 1 to 4 refer to safety related software, indeed level 0 refers to non safety-related
software. These levels don’t provide a guidance on which integrity level should be
applied for a given risk, because this decision will depend upon many factors such
36
as the nature of the application, the measure to which other system carry out safety
functions, social and economic factors. EN 50128 requires applying a systematic
approach to:
• identifying risk, hazards and criteria;
• selecting a suitable system architecture;
• specifying the safeguards necessary to achieve risk reduction
• planning, monitoring and controlling the activities to transform the safety
requirement into a safety-related system.
Summarizing, the principles applied for the software development of a high integrity
software include:
• top-down strategy;
• modularity;
• verification of each step of the development cycle;
• clear documentation;
• validation testing.
The standard regarding the development lifecycle is quite flexible, it doesn’t mandate the use of a particular process. Finally, the CENELEC standard provides also
a set of requirements regarding the competency of staff involved in the software
development (except for SIL0).
theory and practice, and can support with new evidence the benefits of modeldriven approches, making the companies more confident in these techniques. In this
chapter . . . model-driven procesES, one of the two OMG-based. Both approaches
have been applied in real industrial cases.
the chapter proposes a hybrid MDE approach that . . .
37
The model-driven architecture standardized by OMG groups provides a set of
theoretical guidelines that covers a large part of the software development lifecycle.
MDA seems attractive in safety-critical sectors thanks to the claimed advantages
in terms of interoperability, portability and re-usability, but the integration of this
approach in a real context is not easy to do for two major reasons: a) the presence
of well-proven activities drastic change in the development process and b) the
lack of mature tools that are able to properly support the particular needs in the
development of critical systems. Only industrial experiences can reduce the gap [9]
between theory and practice, and can support with new evidence the benefits of
model-driven approches, making the companies more confident in these techniques.
This chapter presents two different model-driven processes, one of the two OMG
based. Both approaches have been applied in real industrial cases. Finally, the
chapter proposes a hybrid MDE approach that takes into account some aspects of
a OMG-based process, includes some aspects of MDA but does not exploits all the
OMG standards.
3.1.1
OMG-based approach: Model-Driven Engineering of a Railway Interlocking System
A model-driven development process for safety critical systems that supports the
activities of the forward engineering and testing in a classical V-Model, has been
proposed in [8]. It provides a strategy to support verification and validation activities through a conventional V-Model according to CENELEC EN50128 standard.
The process is presented conducting a pilot project for the development of the
Prolan Block, in this work deals development and testing of the Prolan Block (PB)
a safety-critical railway interlocking system. Summarizing, the PB receive data
from semaphores and sensors alongside the track and manages the Block, i.e. the
railway segments. The of PBs forms the distributed railway control system that
ensures a no-collision condition overall the track. Figure 3.1 shows the adapted
38
V-Model with model-driven techniques for the development and testing.
Figure 3.1: The proposed model-driven V-Model
System Requirements Specification
In this phase a CIM model is defined to describe the environment with a subset
of requirements. SysML model language is used to realize Use Case diagram,
Sequence Diagrams, SysML Requirements diagrams that provides a non-functional
description. State Machine diagrams, Activity diagrams and Sequence diagrams
are used to model the behaviour of system et a high level of abstraction.
System Design
A high level PIM is defined identifying the main software components. Usually,
new requirements are derived to clarify ambiguities, and the interfaces of each
component are defined. The system design model is specified by UML diagrams,
in particular with Component diagram and Class diagrams. The interfaces in this
phase are platform independent, thus are defined using generic elements of UML
syntax.
39
Component Design
The Component design stage represents a further refinement step of the previous
PIM model. UML is used to keep the model platform independent, but behavioural
diagram defined here (State Machine diagrams), exploiting Rhapsody1 datatype
(transformation rules to PSM model are just defined). This phase, generates a detailed PIM model where the design of internal components are completely defined.
Implementation phase
Implementation phase creates a PSM as refinement of previous PIM, adding details (such as tool parameters, transformation rules, etc.) for the model-to-code
transformation. Latter is fully automated and generates executable C++ source
code. Only few interventions, are made to adapt the code with a specific target
(Proprietary Prolan hardware, in this case).
V&V phase
The central and right side of V-Model cover the V&V activities (Fig. 3.1). This
phase starts exploiting the CIM model that describes the system environment and
it is unaware of computation details. The CIT is useful for validation test or special
kinds of assessment, like performance testing.
Ricontrolla. Latter chi
BB-PIT includes the description of the expected behavior of the components,
having only a their description at interface level.
The Integration and Verification design defines a Black Box Platform Independent Test (BB-PIT) model that provides a static and dynamic view of system
components. BB-PIT includes the description of the expected behaviour of the
components, having only a their description at interface level. These components
1
Rational Rhapsody, a modeling environment based on UML, Rhapsody is a visual development
environment for systems engineers and software developers creating real-time or embedded systems
and software.
40
are modelled by using a UTP profile (State Machine, Sequence and Activity diagrams) but, to generate automatic test cases, a QML profile has been used in
the pilot project, since the lack of MDT compliant tools (they adopted Conformiq
Designer2 ).
the PIT is refined. T
In the Component Verification Design a further step of refinement on the previous PIT is defined. he Gray-Box PIT is exploited to generate structured test cases
generated automatically by ATG (Automatic Test Generator of Rhapsody) with
the aim to cover the elements of design model. Often the coverage criteria aren’t
satisfactory, sometimes is necessary create manual test cases.
At this stage a user interface is created to interact with the existing model.
In this way engineers can simulate test cases on a preliminary PSM and detect
eventually design faults, hence perform an early fault detection.
3.1.2
Non OMG standard approach: OpenETCS
OpenETCS is an Open Proofs - Open Source project with the aims at creating a
framework for the development, validation and testing of a ETCS system, reducing
the costs and improving the efficiency of resources. This process does not adopt
the guidelines of OMG standard but gives a proposal on how to produce from
requirement documents a product that is SIL-4 compliant. Figure 3.2 depicts the
entire OpenETCS process.
System analysis
The goal of this phase is to clarify the system requirements that have to be covered
by the solutions. In this activity requires several inputs, such as the SRS-Subset
0263 and ERA documents, which include the specification of the system. The
2
Conformiq is a leading software technology company, focused on test automation, functional
testing and software quality.[www.conformiq.com]
3
SRS-Subset is a set of documents delivered by ERA European Railway Agency. The document
026 in particular, contains the Systems Requirements.
41
Figure 3.2: Main steps of OpenETCS process
system analysis consist essentially of four tasks:
• Define the scope of the high level model.
• Provide an architecture for the model.
• Clarify any ambiguities.
• Detect errors and inconsistencies.
At the end of the analysis tasks several of artifacts are produced. The API generated from system analysis is fundamental to describe the environment of the
system, its interface and its dynamic implementation. A data dictionary is produced and contains the description of the input/output variables needed to describe
42
the interaction between functions. Requirements from SRS document can be split
and rewritten in order to avoid any ambiguities, it consists of 8 chapters and often
the specification offers more than one solution for a specific function, hence new
requirements can be derived.
Architectural Modeling
This phase has the goal of deriving the software architecture from the output of the
previously system analysis. The SysML models can be argumented here to describe
the architecture. This operation suggests the use of SCADE System, a proprietary
tool suited for system design. Finally, the results of this task are an updated and
completed API, functional architecture and data dictionary. New requirements are
provided to describe the design choice made during this phase and are traced with
system analysis.
Functional and behavioural modelling
This phase provides a formal model for each system function. It represents a further
refinement of the architectural model, this step provides a formal model traceable
with the system analysis, starting from API, functional architecture, and Data
dictionary elaborated in the previous phase. The formal model avoids ambiguities
and, due the traceability, increase the readability of the entire system.
Executable code
The aim of this phase is to generate executable code which implements models
defined during the system analysis. No platform is fixed for the executable code,
thus it can be reused in different environment, where the constrains defined in
API document shall hold. This process can be supported by automatic tools, such
as SCADE Suite tool that provide a CENELEC EN 50128 certified code. The
generated code shall have the following proprieties:
43
• Readable: It shall propagate names, comments and shall be well structured.
• Portable: The code can be executed on a different machine and platform,
hence, independent from the target.
• Modular: It shall be structured in several modules.
To prevent undeterministic behaviour it is required a static memory allocation,
static bounded allocation and no recursion.
Verification and Validation
Verification and validation (V&V) activities are performed alongside with the modelling process to ensure the correctness and consistency of the model. These tasks
are performed repeatedly during the development phases and provide feedback to
it. In order to perform the V&V a list of safety requirement for the Subset 026
is considered. OpenETCS suggests a variety of verification methods that can be
applied depending on the chosen approach:
• Proof Technique: consist on the demonstration of statements (axioms) that
are required to be true. Formal proof is used to verify that the model never
reaches a falling state. The proprieties to be proven have to be identified and
described.
• Model Checking: is an automatic technique for verifying temporal logic
reactive system. Similar to proof technique the proprieties to proven have to
be identified and described.
• Simulation: It’s important to define test scenarios to proven safety-critical
properties and to reach the CENELEC EN 50128 SIL-4 standard. May happens that some properties cannot be checked, therefore other methods have
can be adopted such as reviews, inspections, static analysis, walkthroughs.
44
3.2
A hybrid approach to MDE of ETCS components
In a safety-critical industrial sector, development and testing processes are fixed
and well-proven. The introduction of new techniques, processes and approaches in
this area is not easy, particularly when the literature that can prove the validity of
these approaches, limited at few concrete results. During the six-month internship
in Deutsche Bahn (DB), within the project OpenETCS, I have tried tried to adapt
a hybrid approach based on a variant of OpenETCS process and MDA. Similar
to the approach described in the section 3.1.1, a V-Model has been adopted, but
without exploting all the OMG languages, in order to tune the process to the ETCS
industrial needs. In particular, the models have to be compatible with the SCADE
tool chain, since this platform is spread in the railway domain and is commonly
adopted in the development. The tool SCADE of Esterel Technology, supports both
development and testing in a model-based approach. One of the reason that let to
define this hybrid approach is that SCADE is able to generate C code compliant
with CENELEC EN50128, reducing the efforts and costs of implementation and
represent a great point of strength in railway sector. The proposed approach is more
flexible and maintainable, because it can exploit the transformation and traceability
typically of a OMG model-driven approach.
3.2.1
Model-driven design
The ETCS requirements regarding to the On Board Unit (OBU) functions are
mainly collected in the SRS Subset and ERA documents. ETCS standard provides
a high level system architecture but it’s not enough for a more detailed functional
breakdown. The first effort needed in this phase is an accurate analysis of the
system requirements to understand the scope of OBU subsystem that will be developed. The specification analysis performed in the context of OpenETCS project
works around 16 user-stories carried out through UML Sequence diagrams that
describe the interaction of the EVC system with other OBU subsystems such as
45
DMI, TIU, the Eurobalise etc. The number of user-stories are continuously increasing as long as all the requirements are covered. The user-stories show a high
level interaction, this means an additional refinement effort is needed to better
describe the subsystem under development. In this phase a CIM model is defined
to describe the environment of the system. CIM is a computation independent
model defined in SysML and provides an overview of the components involved in
the system. BBD and IBD are used to describe the static structure.
After the CIM has been defined, System Design clarifies the structure of the
component to develop. This is another step of refinement, here are designed the
interface and the data flow between the components, CIM is transformed in the
PIM model. In this phase SysML as modelling language is used, with BDD and
IBD for the static view and State Machine, Sequence diagram for modelling the
dynamic behaviour.
The Component Design represents a crucial step of the hybrid process because
the SCADE tool is introduced, the defined model has been executable and ready
to be simulated. The interfaces of the components are fully defined as well as
the dynamic behaviour. The refined model is still considered a PIM, because no
executable platform is fixed: for instance, the PIM can be transformed in PSM for
C or ADA and several target platforms. In this process no PSM is specified. Latter
is derived from the tool by configuring the target platform.
Handling specification issues
The OpenETCS project is based on several standards like SRS, ERA, CENELEC
and other minors documents. During the modelling, issues regarding specification
could arise. They may be caused by several reasons such as insufficient knowledge
of domain, wrong understanding of specification or a non clear requirement. The
model built through SCADE language (with a strict formal model) helps to clarify
the interpretation of the solution adopted by the modeller, otherwise, a issue is
46
detected (or more than one) and a mini process to handle it should start. Picture
3.3 shows briefly the four steps. If the designer cannot resolve the issue, He should
Figure 3.3: Process for handling specification issues
address the problem to a domain expert who can clarify it or confirm the problem. If
possible a solution should be proposed and stored in a database (repository). At the
later point all the unresolved issues should be reported back to the standardization
institution.
3.2.2
Model-driven testing
Model-Driven Testing (MDT) is to exploits models to generate tests cases. Similarly to the approach presented in the section 3.1.1, the testing activity exploits
the CIT (Computation Independent Test) model, a novel model derived from CIM
through SCADE modelling language. The aim of this phase is to generate a testing environment able to perform test cases repeatable, traceable with the system
requirement and automatic generated. In accordance with OpenETCS philosophy:
”Make the train run with a very minimum functionality”, the testing activity aims
at proving, in the preliminary phase of the project, only the nominal cases, i.e. the
use cases with positive responses, therefore scenarios with packet losses or unavaiable data are neglected. The CIT, that model the System Under Test’s (SUT’s)
environment, is defined taking into account this concept.
47
Figure 3.4: V-Model
Figure 3.5: Model-in-the-Loop
Model-in-the-loop
Model-in-the-Loop (MiL) is a testing technique widely used in the automotive
industry [14]. It is useful to perform testing at an early stage, where the system is
not complete but the system and the environment models are available. In a MiL
test, the systems are connected in a closed feedback loop (Fig. 3.5). Therefore,
necessary conditions to perform a MiL testing are: a) the environment has to be
modelled with the same notation of the System Under Test (SUT) because they
have to be connected each other and b) both have to be executable. Because CIT
and the PIM are connected each other, the interface of CIM is complementary
48
to the one of the SUT. Testing is arranged in test scenarios, each one simulating
a real situation and stimulates the PIM properly. A graphical panel (or panels)
helps to summarize the results and to set up the test scenario. Each test scenario
is traceable with the requirements and gives the designer informations regarding
the coverage of requirements.
Figure 3.6: Model-in-the-Loop process
During the development phase may happen that the fix of a problem or a
redesign of a component in one area can introduce a new bug in another area.
These problems are caused by dependencies between software components and are
detected through the so called Regression Testing. Latter verifies that whether
changes made in the code (or in the model), did not introduce new faults. Modelin-the-Loop testing is particularly suited to perform this kind of analysis, because
SUT and CIT model are both executable, thus it is easy to repeat the tests several
times and then to compare the results.
SCADE tool allows recording the test simulation and transform it in an executable script, written in a proprietary language (SSS Script). SSS Scripts allow
executing the testing scenarios without using the graphical panels. The simulation
49
by text scripts is useful to generate model coverage reports that allows figuring out
which parts of the model have been covered by the tests.
50
Chapter 4
Case study: ETCS Driver
Machine Interface
This chapter presents a case study regarding the development of a subset of functions of a ETCS Driver Machine Interface (DMI) exploiting the hybrid model-driven
approach described in the previous chapter through the support of SCADE.
The DMI is the principal way used by the driver to interact with OBU, and it
is mounted in central position of the cockpit. Figure 4.1 shows a typical train cab,
where the ETCS DMI is highlighted in red. DMI provides several informations to
the driver, which we can summarize in three categories:
• Track Description: Information about the track condition, e.g gradient
profile (useful to compute the ratio downhill/uphill), the current permitted
travel length, the position where the train speed limit change, etc.
• Speed Monitoring: Includes all information about speed, e.g the current
speed, the maximum speed limit, changing of speed pointer colours according
to the breaking curve and ETCS requirements.
• Status informations: Includes information about the current ETCS level,
ETCS Mode, emergency brake or extra informations via text messages, ad51
Figure 4.1: Train cab fitted with ETCS
vising of Mode or Level change.
There are two possible technologies of DMI, namely soft-key or touch-screen. In
this work we consider the touch-screen version. The few differences between them
are related only to the pointing mechanism, one can exploit dedicated buttons
placed around the screen and the other the touch sensitive display.
The case study has been performed in the framework of the OpenETCS project
and aimed at assessing early verification techniques introduced by model-driven
approaches. We exploited real-word use case scenario at an early stage of the development process, hence adopting a functional approach traceable with the System Requirement Specification (SRS). The aim is to realize the essential kernel
functions of a ETCS system and set up a test environment that will be used as
demonstrator in the final phase of the project. In the last phases of the development process, model-in-the-loop tests can be run on the HMI, after the deployment
on the target hardware. The use cases scenarios are defined by the analysis of the
Utrect-Amsterdam, that is a route compliant with the ETCS Level 2 standard.
The entire software development is managed with SCRUM agile method, an
iterative framework suitable for complex software systems. This framework is also
appropriate with the top-down strategy adopted in the project, since the iterative
approach of SCRUM allows a continuous refinement of the architecture. Accord52
ing to the SCRUM management methodology, the requirements are presented in
form of user stories. Below is reported a user-stories, represented with a sequence
diagram:
User story 5 - Aweakness of the train in Level NTC
According to the
procedure in chapter 5 of SRS ERA document [19] the use case shows how demonstrate the train starts with the National Train Control (NTC) Level and Stand By
mode. Figure 4.2 depicts the sequence diagram that describe the interaction of the
involved subsystems.
Figure 4.2: Aweakness of the train in Level NTC
53
4.1
DMI System Analysis
The first step of the development process consists in defining the role and responsibility of DMI in the OBU system, and derive the functionalities to develop by
analysing the OpenETCS user-stories. The derived functional requirements have
been formalized as user-stories that describe the behaviour of DMI. As design
choice, DMI is a passive component, i.e. the Driver or the EVC sends request and
the DMI replies appropriately as in a client-server architecture. The development
process follows an adapted V-Model approach and according to the first phase
showed in figure 3.4, SysML models that depict the system environment is defined
(Fig. 4.3). The figure 4.3 (Block Definition Diagram (BDD)) shows a simplified
Figure 4.3: Block Definition Diagram - On Board Unit
version of the On Board Unit that forms the CIM, where are included only the
that are involved with DMI communication. As showed in the BDD, the DMI
consists of two components: DMI Display and DMI Controller; the first represents
54
Figure 4.4: Internal Block Diagram - On Board Unit
the graphical widgets that compose the DMI such as Speed Gauge, ETCS Symbols,
Menus, Text area, etc. and it has been developed with SCADE Display, instead
the second contains all the logic to control and check the graphical widgets and
has been developed in SCADE suite. All the components present in the BDD are
also present in the OBU architecture showed in the section 2.3.2, except for DMI
Manager.
The DMI Manager has the responsibility to convey the informations from various
EVC modules and to submit them through an API (Application Programming Interface) to the DMI Controller. In other words the DMI Manager is an adapter
that assembles the informations in such a way to be compliant with the DMI API.
The introduction of DMI Manager in the OBU system derives from a design choice
that aims at making the DMI side more flexible and less complex. Figure 4.4 shows
the data flow of the OBU’s components: the Internal Block Diagram (IBD) that
highlights how the modules are connected each other and gives an overview about
the interfaces. The figure 4.5 focuses on the DMI module is also a IBD and shows
how DMI Display and DMI Controller are connected.
55
Figure 4.5: Internal Block Diagram - Driver Machine Interface
4.2
DMI Display
The DMI Display manages the graphical widgets that compose the DMI, all the
ergonomic principles such as dimension, colours, font style and positions are conformed with [1]. This part is developed using SCADE Display: in order to increase
the modularity, each graphical widget has been made as single standalone project
with the aim to increase the modularity.
The DMI is divided in six well defined parts namely A,B,C,D,E and F each one
with a specific function (Fig. 4.6). Positions, dimensions and style are described in
detail in the [1] requirements document. In the following each region is described,
while 4.7 shows an example of a running DMI display.
• Area A: displays distance information through a Distance to target bar..
The target bar has a linear behavior in the range from 0 to 100 km and a
logarithmic behaviour for values outside the range This widget indicates the
distance and appears onli in some ETCS Modes (for more details [1]).
• Area B: In this area are placed speed informations and some additional
informations regarding ETCS Mode and track-side informations. Each operating mode and track-side informations have a specific symbol defined by the
European Railway Agency (ERA) and are collected in the [1] requirements
document. Around the speed gauge, according to the ETCS Mode, Level,
56
Figure 4.6: The layout of the ETCS DMI
Figure 4.7: Example of ETCS DMI
57
braking curves and speed profiles, appears a curved coloured line that indicates speed limitations, such as Permitted Speed, Target Speed and Release
Speed. Similarly, the speed pointer, that shows the actual speed of the train,
changes the colours to alert the driver.
• Area C: This area shows the changing of ETCS mode and level symbols.
It may happen that the driver has to acknowledge a Mode\Level transition
by pushing on the showed symbol. When an acknowledgement is required,
the symbols will be yellow and the area will be touch sensitive. Emergency
brake symbols is also displayed in this place and likewise, if it has to be
acknowledged a yellow flashing border will appear around it.
• Area D: Here is placed one of the most innovative and dynamic widget: the
Planning Area. Here are concentrated a lot of track informations. During the
trip a vertical bar with a percentage value inside informs the driver about
track gradients. Through a step chart is shown the position where the train
has to change speed and a lot of symbols can appear to inform the drive
of a forthcoming order like Raise Pantograph, Lower Pantograph, Change of
traction system announcement etc.
• Area E: This area is dedicated to displaying text messages. There are
different kinds of messages: Information message, Important message and
Acknowledgement Required message. Each one consists of a current time
(hh:mm), a text field and are managed as a list with a FIFO (First In First
Out) policy where, the Important messages are positioned on the top with a
bold font style, instead the Information message are positioned after, with
a normal font style. The Acknowledgement Required messages have to be
acknowledged by the driver and are shown one at time, furthermore, the text
area will be touch sensitive with a yellow flashing border around it.
• Area F: In this area placed the buttons to access the various menus of the
58
DMI such as Main Menu, Settings, Data view etc.
• Area G: This area provides supplementary informations such as geographical
position of the train and current time.
Finally, the windows exploited to display, enter or modify the data can span on
multiple areas, in particular there are two kinds of window, Half grid array and
Total grid array both with a similar style. The first one occupies the G,D and F
area, the figure 4.8 shows an example of layout. With this type of window only the
right half is covered, the speed gauge, text message area, modes and level symbols
are still displayed. The second one covers all the areas, the figure 4.9 gives an
example.
4.3
DMI Controller
DMI Controller contains all the logic to manage the graphical widgets. As showed
in picture 4.4, DMI Controller doesn’t communicate directly with EVC but rather
with the DMI Manager and the interface between them is not standardized in
the ETCS documents. The API used for the communication between the DMI
Controller and the DMI Manager follows the structure of an existing one, developed
by a software engineering company specialized in the production of ERTMS/ETCS
related solution, the next subsection explains the structure.
4.3.1
DMI Controller Interface
In accordance with SysML system architecture of the On Board Unit, the DMI
Controller consists of two interfaces. One between the DMI Controller and the
DMI Display and one between the DMI Controller and the DMI Manager. The
structure of the interface between DMI Controller and DMI Display is not dealt in
this work.
DMI Controller and DMI Manager communicate through packets. Each packet is
59
Figure 4.8: Layout of a Data entry window (half grid array)
Figure 4.9: Layout of a Data validation window (total grid array)
a structured type with a validity flag (i.e. boolean variable), the DMI controller
takes into account the data inside the packet only when it is valid.
The interface can be divided in three parts according to the direction of the information:
• From DMI Manager to DMI Controller
• From DMI Controller to DMI Manager
• Both ways directions
60
Below are listed the packets that form the used API with a brief description. These
packets are exchanged sporadically1 , the only exceptions are DMI_dynamic and
DMI_status_report (market with an asterisk) that are periodically transmitted.
1
On event
61
Table 4.1: From DMI Manager to DMI Controller
NAME
DESCRIPTION
DMI_entry_request
DMI_identifier_request
DMI_menu_request
*DMI_dynamic
DMI_text_message
DMI_icons
Request to enter data (e.g. Driver id, Train Data etc.)
Request of the DMI informations
Request to enable or disable buttons
Contains informations about current speed, mode etc.
Contains predefined or plain text messages
Request to display one or more icons in any area
Table 4.2: From DMI Controller to DMI Manager
NAME
DESCRIPTION
DMI_identifier
DMI_driver_request
DMI_train_data_ack
*DMI_status_report
DMI_text_message_ack
DMI_icons_ack
Information about DMI (e.g. version, cabin identifier etc.)
Driver request or acknowledgement
Train data acknowledgement
The actual status of DMI (keep alive)
Text message acknowledgement
Icon acknowledgement
Table 4.3: Two ways direction packet
NAME
DESCRIPTION
DMI_driver_identifier
DMI_train_running_number
DMI_train_data
Contains the default or entered driver identifier
Contains the default or entered train running number
Contains the default or entered train data
62
Figure 4.10: Block Definition Diagram - DMI Controller
4.3.2
System Architecture
DMI Controller consists of seven modules each one covering a set of functionalities
according to ERA Requirements [1] and the OpenETCS user-stories. Figure 4.10
shows the structure in SysML and below is given a description of each module:
Initialization Mng This module performs the initialization phase, ensures that
no informations will be exchanged with DMI Manager or the Driver before the desk
is open 2 . Once the desk is open, ensures that a handshake is performed with DMI
Manager; after that the communication can begin.
Icon Mng This module manages the symbols in C Area to advise the Driver
about track informations. It is responsible also of the acknowledgement mechanism
when required.
2
The term Desk is Open means that the DMI is on, this expression derives from the old train
cabin which were provided with a cover on desk
63
Menu Mng This module is responsible for menu management, show/hide Main
menu, navigation inside the windows, management of buttons (enable/disable) in
accordance with packets received from DMI Manager.
Message Mng This Module is responsible for the correct displaying of text messages in Area E. It deals with the management of acknowledgement mechanism
when required and the display of messages with the correct font style according to
the importance of the information.
Periodic Info Mng
As mentioned in previously section some information are
received periodically. This module manages the display of these informations, such
as speed (current speed, target speed etc.), ETCS mode, ETCS Level, radio connection information etc.
Train Data
Manages the storage of train data and eventually the update of
informations. The train data can be viewed, modified and confirmed by the driver
through DMI menu.
Planning Area
This module manages the informations that have to be displayed
in the planning area (D area) and checks according to ETCS Mode if can be
displayed or not.
4.3.3
Executable Model Design
As mentioned in 3.2.1 the component design represent a crucial step of the development process, because here the SysML models have to be adapted for being used
with SCADE. Thanks to SCADE Suite tool, the PIM model has enough detail
in order to realize an executable C-code, CENELEC EN50128 standard conform
and no PSM is needed. In the following, we describe parts of the SCADE model,
derived from the SysML model shown in 4.10.
64
Figure 4.11: Open/close Desk diagram
Initialization
The initialization phase is implemented through a State Machine. The figure 4.11
depicts the behaviour of DMI in the starting phase, it starts in DeskIsClose state
(the display shows a black screen) and if OpenDesk signal from TIU is triggered the
transition evolves in DeskIsOpen state. In this model we separate the control flow
and data flow, this pattern is frequently used inside the projects (Fig. 4.11). The
operator Sub_fuc:CheckDeskStaus is responsible for monitoring the TIU signal and
stimulate the state machine. Inside the DeskIsOpen state is modelled the handshake
mechanism. Latter ensure that no packets will exchange between DMI Control and
DMI Manager before DMI Control receives an Identifier request. After receiving
the identifier request, DMI Control responds with an Identification packet in which
are contained informations such as Cabin ID, software version etc.
Icon Management
This module manages the display of the icons according to information received
by the EVC via the DMI_icons packet. It also implements the acknowledgement
mechanism: when the acknowledgement for a display is required, it properly man-
65
ages the flashing frame. When the driver pushes on an flashing symbol, the DMI
sends DMI_icon_ack to DMI Manager (than to the EVC) to inform it about:
the name of activated area, the symbol displayed and the timestamp. This model
consists of several diagrams but only some of most significant parts are shown:
Figure 4.12 shows the state machine for the icon acknowledgement mechanism. It
Figure 4.12: Icon acknowledgement mechanism
starts in Idle state, when a yellow flashing frame is present around the icon, then
the highlighted area becomes touch sensitive and ready to be acknowledged by the
driver. The acknowledgement mechanism refers only for C1 and C9 area of DMI.
In the DMI_icons packet is specified which icon, in what position has to be shown
in the DMI layout and which action has to be applied such as clear area, show icon
with yellow flashing frame or simply show icon. All these choices are taken through
nested if-block as shown in figure 4.13:
66
Figure 4.13: Nested if-block
Menu Management
The menu management model is responsible for displaying of menus and enabling/disabling the buttons in accordance with the ETCS mode, train data, ETCS levels,
etc. The display of a specific window can be requested both by EVC and by Driver,
the first for security reasons, with a higher priority. This model is structured in a
data-flow and control-flow architecture (Fig. 4.14). The data-flow part consists of
two operators: DMI_entry_requested and DMI_menu_req_To_button, the first
one is used to specify which windows shall appear (with the highest priority) by
EVC command, the second defines which button are enabled/disabled in the main
menu. Within the MainMenu state in figure 4.14, it is located the state machine
that performs the navigation logic of the menus controlled by the Driver (by the
means of touch screen commands). This nested state machine ensures the highest
priority of the EVC commands. EVC can impose at any time to display a different window sending the DMI_entry_request packet, the condition present on the
outgoing arcs of the MainMenu state will be activate and the window will change.
67
68
Figure 4.14: Menu management model
69
Figure 4.15: Main menu controlled by the Driver
70
Text Messages Management
This model describes the behaviour of the text messages shown in area E and
its acknowledgement mechanism. As discussed previously there are three type
of messages: Information, Important and Acknowledgement Required messages.
To manages the different kinds of behaviours a dispatcher module is used that
distributes the incoming messages in three queues, one for each type of message.
The Acknowledgement Required messages have the highest priority, whereas the
Information type have the lowest. Figure 4.16 shows the model.
Figure 4.16: Text Messages model
71
Periodic Information
This model is responsible for the proper display and update of the periodically
informations received from EVC like ETCS Mode, ETCS Level, speed, and RBC
connection. All these informations are collected into DMI_dynamic packet. Its
validity flag triggers the operators responsible of managing of the periodic informations, these are characterized by he boolean activators 3 mechanism. An example
of a boolean activator is shown in figure 4.17). The Periodic Information model
provides also the management and checking of both Speed Pointer and the Circular
Speed Gauge colours in accordance with the table 4.4 and 4.5 of ERA Requirements
and the display of the Distance to Target bar according to the table 4.6.
Figure 4.17: Boolean activator for ETCS Level
3
The function represented in SCADE as a blue bubble around the operator, executes the content
of an Operator only when the boolean input condition, placed on the upper side, is satisfied.
72
Table 4.4: Truth table that defines the color of the speed pointer
73
Table 4.5: Truth table that defines the colours of the Speed gauge
Table 4.6: Thruth table that defines the Distance to Target display conditions
74
Train Data
This model consists of three parts responsible for the display, the update and
the confirmation of the train data. The first part is a simple state machine with
two states (Fig. 4.18). The initial state provides the store the default train data
values, if the valid flag of DMI_Train_data packet is true, then the transition
triggers and the state Incoming_TrainDataValues is reached to update of train data
informations. The figure 4.19 shows the operator responsible for the adaptation
Figure 4.18: Train Data storage and update State Machine
of DMI_Train_data packet in the format compatible with DMI API. Finally, the
Figure 4.19: Train Data adapter operator
state machine 4.20 performs the logic of acknowledgement of data, receiving the
data from the touch screen. It triggers a transition that makes the machine to
evolve in state YES (when) or NO (if otherwise).
75
Figure 4.20: Train Data confirmation State Machine
Planning Area
This model manages the display of informations within the D area of DMI. It consists of two operators Area_D e D_Behaviour. Area_D receives inputs from DMI
Manager such as Speed profile, Gradient profile, train position. These informations
are elaborated and adapted for the next operator D_Behaviour. Latter implements
the behaviour logic of the widgets that are displayed in the planning area. The
picture 4.21 gives an overview of the possible symbols and information that could
appear in the planning area.
Figure 4.21: Overview of objects in the Planning Area
76
4.4
Model-in-the-Loop Testing
In our process, we exploit the CIT to perform the of model-in-the-loop testing, it
is derived from the CIM model and allow to reproduce a real system environment.
The CIT is connected to the PIM in a closed feedback loop with a complementary
interface. In our project, we modelled in the CIT six use cases, that were used to
simulate six scenarios. The test scenarios are:
• START OF MISSION: Simulates the Start of Mission (SoM) described
in the SRS subset 026 chapter 5, it’s represent the initialization phase where
the Driver interacts with DMI to enter informations like Driver ID, Train
Running Number, Train Data etc.
• SWITCH TO SN MODE (a): Simulates the switching to SN mode, the
driver has to acknowledge it by pushing on the yellow flashing symbol.
• SWITCH TO SN MODE (b):Simulates the switching to SN mode, the
driver has to acknowledge it by pushing on the yellow flashing text message.
• CHANGE ETCS LEVEL (a): Simulates the changing in the ETCS Level
2, the driver has to acknowledge it by pushing on the yellow flashing symbol.
• CHANGE ETCS LEVEL (b):Simulates the changing to ETCS Level 2,
the driver has to acknowledge it by pushing on yellow flashing text message.
• SPEED MONITORING: Simulates some brief train trips to verify the
correctness of speed pointer colours.
More details about them are in appendix B.
77
4.4.1
Graphical Test Panel
The CIT model interacts with PIM model sending a sequence of packets simulating
real use case scenarios. We modelled several test scenarios selectable through a
graphical panel (Fig. 4.22), using a dropdown menu. In the central area are placed
the results of the tests, they are represented as LEDs, each one associated with a
boolean condition. If the condition is satisfied by the test, then led colour become
green, otherwise remain red. When the test scenario is running, both are shown:
CIT panel and DMI. The tester is able to observe the dynamic behaviour of DMI
(Fig. 4.23).
Figure 4.22: CIT Panel
78
Figure 4.23: Example of running test scenario
4.4.2
CIT architecture
The CIT is composed of several state machines, each one that simulates a particular
scenario. The graphical panel, allows to select one of the scenarios and execute it,
as shown in figure 4.24 where are located the test scenarios inside them.
79
Figure 4.24: If-Block for test scenarios
80
Figure 4.25: Logic of test scenario
The state machines used to build the test environment follow the structure
depicted in figure 4.25. The states on the left side send packets sequentially to the
DMI Control, simulating the real environment. The states on the right perform
checking based on the packets sent. An abstract of the CIT is shown in figure 4.26,
it is composed of a high level state machine, where state identifies a phase of the
test scenario within are placed the state machines that implement the schema of
figure 4.25.
81
Figure 4.26: Example of test scenario State Machine
4.4.3
Test script and model coverage
As widely discussed in the previous sections, the testing technique that we have
examined performing the mode-driven development approach is the Model-in-theLoop. It has been performed as a Black-Box testing where the SUT (the PIM
model) is considered as a closed box, unaware of its internal structure. The proposed hybrid development process is in an experimental stage and some aspects are
still demands for better investigation, such as how to integrate with a White-Box
testing strategy. A White Box testing is a technique that takes into account the
internal structure of the model.
SCADE Suite is able to generate coverage reports by executing the simulation
stored in a SSS Script. The SSS script is a scripting language proprietary of SCADE
suited to stimulate and check the model under test with few simple commands.
The script generation is automatic. During the simulation of the CIT model,
82
Figure 4.27: Coverage report of operators
SCADE Suite translates all the operations in textual script that can be used at any
time. Figure 4.27 shows a report generated from SCADE suite tool and highlights
the operators covered by the simulation. SCADE uses basically three colours to
highlight the model elements: red, yellow and green. Red means that the operator
isn’t covered (never executed), yellow instead is covered only partially and green
totally. It can be observe in the figure, only 137 operators of 188 are covered, that
means only 60 % of the model. As mentioned before, this result is caused from
the adopted testing strategy, in fact this report, has been carried out only with the
aim to demonstrate the feasibility with the considered tools.
4.4.4
Traceability and impact analysis
An important aspect which the proposed hybrid model-driven process has taken
into account, is the traceability. SCADE tools, through its integrated Requirements
Management Gateway plug-in, allows managing the traceability between requirements and models. This tool is able to manage graphically the links and generate
reports like coverage analysis, impact analysis etc. Figure 4.28 shows the document
83
Figure 4.28: Traceability Three
and artifacts used and traced in this work.
84
Conclusions and Future Work
In this thesis we proposed a process based on a hybrid model-driven approach to
support the development and testing components in railway domain. This work
has been carried out during an internship experience in the framework OpenETCS
project, and aims at investigating the application of MD techniques in a real industrial case. The cooperation with industrial partners was crucial for several
aspects, such as understanding of technical issues and clarify ambiguities of the
ETCS standard.
In some aspects, the hybrid approach suggested in this work, is not yet complete
and too immature for a practical use in a real industry context but in some others
it seems to be ready for it. The crucial weakness is represented by the testing
phase. As mentioned in the section 4.4.3, it lacks an automatic generation of test
cases that takes into account the internal structure of the models. In other words a
White Box testing is missing. This issue is also highlighted from the model coverage
report. The model-in-the-loop testing technique adopted in this work allows the
simulation of the component under real working condition and since the model
under test is a PIM, independent from the target hardware, it allows also an early
fault detection, traceable with the graphical test panels. From this point of view,
a gain in terms of productivity and quality was recognized.
The development phase, in particular the System Design is characterized from
SysML. This modelling language is totally supported by SCADE tool even if Eclipse
is also able to support it (Papyrus plug-in) and it is fully compliant with the OMG
85
approach. This means the process has a good level of interoperability with other
tools and this aspect represents a strength. The modelling language adopted in
the Component Design instead, is propriety of SCADE and represents, on one
hand, a great weakness. The designers are not able to exploit external tools (e.g.
Rhapsody) for extra features. It should underline, on the other hand, the role of
SCADE suite. It is fundamental in the development process, it provides a certified
C/ADA code generation and in the industrial domain is an essential aspect, such
as to spend big effort to adapt the development process to the needs of SCADE
tool.
This thesis represents a starting point for further research, addressed to complete and refine the methodology proposed in terms of improvement of test cases
automation and better interoperability of SCADE with external tools. One last
consideration, model-driven approaches enable engineers to work on a more abstract level than the document-centric approaches, focusing on the problem and
leaving other artifacts to be derived through transformations but industry, especially in the safety-critical domain, are with reasons, hard anchored to own consolidate process and methodology. To convince people to make this big step, is needed
that academia and industrial sector work in parallel to produce examples aimed
for bridging the existing gap between theory and practice.
86
Appendix A
SCADE tools
A.1
Introduction
SCADE is a formal modelling language and tool suite of Esterel Technologies,
a French company born in 1999 specialized in safety-critical systems. SCADE
includes software to support a model based approach suited for the avionics, rail,
automotive and industrial automation domain. It provides formal and deterministic
graphical and textual modelling language, simulation and debugging on model level,
formal model proof, test cases execution, automatic report generations, model test
coverage measurements and some other minor functionality. The point of strength,
especially in railway sector, is the KCG code generator, able to generate a EN
50128 compliant code up to SIL 3/4.
A.1.1
SCADE System
SCADE System is a system architecture design and modeling IDE (Integrated
Development Environment). It allows developing system architecture compliant
with system engineering methodology using SysML block diagrams. Includes a
great variety of features like checking model consistency, trace design elements
to requirements, add note and comments to generate reports, extract subsystem
87
components from model to refine them separately etc. It provides a user-friendly
editor suites to decompose requirements with SysML syntax.
A.1.2
SCADE Suite
SCADE Suite is a model-based IDE suitable for designing critical systems. Offers a series of dedicated tools allow designers to combine the activities of system
engineering, software engineering and system integration into a single design environment. The main characteristic is the model-based design to capture both data
flows and control flows aspects of model. Large project ar easy handled through a
multi-view management and offers integration with requirements traceability tool.
SCADE Suite simulator is an integrated feature also fundamental to support blockby-block debugging using breakpoints and stop conditions. SCADE Suite has an
own graphical syntax easy readable and understandable thanks common constructs
such as State Machine, If-Block case, Logical operators. SCADE Suite Model Test
Coverage is another integrated feature that supports the verification activity and
coverage measurement analysis through a graphical interface notation. At last but
not least the KCG code generator that represent the most important function of
SCADE Suite. It generates from SCADE models a C or ADA code certified for
EN 50128 CENELEC standard up to SIL 3/4, hence saves verification effort in the
coding phase, such as code reviews and low-level testing [18]. The generated code
fulfils, for safety-critical reasons, constrains like static memory allocation, static
bounded loops and no recursions, these proprieties are closely related with SCADE
Suite Checker that checks in modelling phase syntax errors.
A.1.3
SCADE Display
SCADE Display is a flexible graphics design and code generation tool the development of Human Machine Interfaces (HMI), safety-critical embedded display systems and 2D/3D simulator displays. It’s based on What You See Is What You Get
88
(WYSIWYG) paradigm that helps to reduce project costs and similarly to SCADE
Suite, consists of a KCG Code Generator that produces a EN 50128 certificated
code with native support for the OpenGL SC (Safety Critical) end ES (Embedded System) standard [17], furthermore is hardware independent too. In SCADE
Display are integrated some tools for simulation, syntax check, requirements and
traceability management, automatic documentation generation and some other minor features. It is tightly coupled with SCADE Suite for the development of the
behaviour logic.
A.1.4
SCADE Rapid Prototyper
Rapid prototyper is a IDE for building control cockpit, panels or similar using
component form a predefined widgets library. It’s useful, combined with SCADE
Suite, to refine, improve or validate the functional requirements that are defined
as input of software project. SCADE rapid prototyper helps to create a simulation
environment that could be exploited to the verification activity.
89
Appendix B
Driver Machine Interface: User
Stories
This Appendix describes the User Stories used to define the functional requirements
of the Driver Machine Interface. These user stories are derived through a refinement
process of the OpenETCS scenarios and an analysis effort of Utrecht-Amsterdam
data track. This document has been exploited for the test scenarios in the CIT
model to set up the Model-in-the-Loop testing.
B.1
USER STORY 1A: Start of mission Initialization
• The DMI starts with a black screen. It’s ready to receive the open desk
signal.
• Opendesk signal is received, the desk is open but no informations are displayed
(Mode, ETCS Level, Text Message etc). The DMI shall not exchange any
informations with the DMI Manager before a handshake is done.
After the initial handshake the DMI is ready to show all kind of informations
received from DMI Manager, in accordance with ETCS mode and Level.
90
• Start of Mission procedure can begin.
• The actual mode shall be Stand By mode. The ETCS symbols shall compare
in B7 area.
• The Actual Level shall be ABT (Neaderland National System) and shall
compare in C9 area.
B.2
USER STORY 1B: Inserting of Driver ID and Train
running number
• The DMI Manager commands to display the Driver ID panel to enter the ID
number of the driver and confirm it.
• The DMI Manager commands to display the Train Running Number window
to enter the Train Running Number and confirm it.
• The DMI Manager commands to display the Main Window with the following
activated buttons: Driver ID, Train Running Number, Train Data, ETCS
Level.
B.3
USER STORY 1D: Validation of ETCS Level
• The Driver shall validate the ETCS Level through the Level window by clicking on Level button of the Main Menu.
• The click on Level button, triggers a Level information request packet to DMI
Manager to retrieve the last informations about the available permitted Level
on the actual track.
91
B.4
USER STORY 1E: End of Procedure
• The DMI Manager commands the DMI to display the Main Window with
Start button Active
• The Driver shall push the Start button to complete the Start of Mission
procedure.
B.5
USER STORY 2A: Acknowledgement of SN Mode
The DMI Manager needs to receive an SN Mode acknowledgement. The DMI shows
a yellow SN Mode symbol in C1 area with a flashing frame.
• The Driver has to acknowledge the SN Mode by pushing on C1 Area.
• The DMI sends an acknowledgement packet to DMI Manager.
• The yellow SN Mode symbol shall disappear.
• A gray SN Mode symbol will appear in B7 Area.
B.6
USER STORY 2B: Acknowledgement of SN Mode
The DMI Manager needs to receive an SN Mode Acknowledgement. The DMI
shows a fixed text message in E area with a flashing yellow frame.
• The Driver has to acknowledge the SN Mode by pushing on E Area.
• The DMI sends an acknowledgement packet to DMI Manager.
• The text message shall disappear.
• A gray SN Mode symbol will appear in B7 Area.
92
B.7
USER STORY 3A: Transition of ETCS level and
Acknowledgement required
The DMI Manager needs to receive an acknowledgement for the level transition:
from ATB (Nation System) to ETCS Level 2.
• The DMI shows a yellow Level 2 symbol in C1 area with a flashing yellow
frame.
• The Driver has to acknowledge the Level 2 transition symbol by pushing on
C1 area.
• The DMI sends an acknowledgement packet to DMI Manager.
• The Level 2 transition symbol shall disappear.
• A gray Level 2 symbol will appear in C8 Area.
B.8
USER STORY 3B: Transition of ETCS level and
Acknowledgement required
The DMI Manager needs to receive an acknowledgement for the level transition:
from ATB (Nation System) to ETCS Level 2.
• The DMI shows a yellow plain text message in E area with a flashing yellow
frame.
• The Driver has to acknowledge the plain text by pushing on E Area.
• The DMI sends an acknowledgement packet to DMI Manager.
• The text message shall disappear.
• A gray Level 2 symbol will appear in C8 Area.
93
B.9
USER STORY 5: Ceiling Speed Monitoring
• The train start from the velocity of 0.0 km/h.
Warning status is Normal.
Permitted Speed = 50 km/h.
• The train overpass the Permitted speed.
Warning status is Overspeed.
FLOI (First Line Of Intervention) is 60 km/h.
• The train reaches the 60 km/h.
Warning status is Intervention.
FLOI is 70 km/h.
• The Simulation ends when the train reaches the velocity ov 70.0 km/h.
B.10
USER STORY 6: Target Speed Monitoring
• The train starts from the velocity of 0.0 km/h.
Warning Status is Normal.
Permitted speed is 100 km/h.
Target Speed is 50 km/h.
• The train overpass the velocity of 50 km/h.
• The train overpass the velocity of 70 km/h.
Warning status is Indication.
• The train overpass the 100 km/h.
Warning status is Intervention.
Permitted Speed is 80 km/h.
94
Release Speed is 50 km/h.
FLOI is 100 km/h.
• The train decelerates down to 80 km/h.
FLOI is 0.0 km/h.
• The Simulation ends when the train reaches the velocity of 0.0 km/h.
B.11
USER STORY 7: Release Speed Monitoring
• The train leaves from the velocity of 0.0 km/h.
Warning status is Indication.
The Permitted Speed is 80 km/h.
The Release Speed is 50 km/h.
• The train reaches the velocity of 25 km/h.
Warning status is Intervention
• The train reaches the velocity of 40 km/h.
95
References
[1] European Railway Agency. ETCS DRIVER MACHINE INTERFACE, Mar
2012.
[2] Alan Brown. An introduction to model driven architecture. Available at http:
//www.ibm.com/developerworks/rational/library/3100.html, 2004.
[3] Jordi
Cabot.
gineering.
Model-based
Available
engineering
at
vs
model-driven
en-
http://modeling-languages.com/
model-based-engineering-vs-model-driven-engineering-2/, 2009.
[4] Cephas Consulting Corp. The fast guide to model driven architecture, Jan
2006.
[5] Paul Logan Tommie Liddy David Harvey, Michael Waite. Document the
model, don’t model the document, 2012.
[6] Lenny Delligatti. SysML Distilled. Nov 2013.
[7] Jeremy Dick Elizabeth Hull, Ken Jackson. Requirements Engineering. Third
edition, Apr 2010.
[8] Stefano Russo Andràs Zentai Fabio Scippacercola, Roberto Pietrantuono.
Model-driven engineering of a railway interlocking system, 2013.
96
[9] Francesco Fucci Roberto Pietrantuomo Stefano Russo Gabriella Carrozza,
Mauro Faella. Engineering air traffic control systems with a model-driven
approach, 2013.
[10] Object Management Group. Mda guide version 1.0.1, May 2003.
[11] Object Managent Group. Uml testing profile. Available at http://www.omg.
org/spec/UTP/1.2/PDF/, Apr 2003.
[12] Waseem Al Sammane Abdelwahab Hamou-Lhadj / Springer Mohamed Mussa,
Samir Ouchani. A survey of model-driven testing techniques, 2009.
[13] Deutsche Bahn Netz. European train control system (etcs) open proofs - open
source. Available at http://openetcs.org/, 2015.
[14] Lionel Briand Thomas Bruckmann Claude Poull Reza Matinnejad, Shiva Nejati.
Automated model-in-the-loop testing of continuous controllers using
search, 2013.
[15] Volker Gruhn Sami Beydeda, Matthias Book. Model-Driven Software Development. 2005.
[16] Douglas C. Schmidt. Model driven engineering, 2006.
[17] Esterel Technologies.
Scade display.
Available at http://www.
esterel-technologies.com/products/scade-display/, 2014.
[18] Esterel Technologies. Scade suite kcg and ada code generator. Available
at
http://www.esterel-technologies.com/products/scade-suite/
automatic-code-generation/scade-suite-kcg-ada-code-generator/,
2014.
[19] ERA UNISIG. System Requirements Specification, Subset 026, 2012.
97
[20] Christian Wanger. Model-Driven Software Migration: A Methodology: Reengineering, Recovery and Modernization of Legacy Systems. 2014.
[21] Wikipedia. Etcs. Available at https://en.wikipedia.org/wiki/European_
Train_Control_System, 2015.
98