See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/268374574

Model-based development of an Automatic Train Operation component for

Communication Based Train Controls

Conference Paper · August 2014

DOI: 10.13140/2.1.5114.8486

CITATIONS READS

2 1,106

5 authors, including:

Mariano Di Claudio Alessandro Fantechi

University of Florence University of Florence
2 PUBLICATIONS   18 CITATIONS    179 PUBLICATIONS   2,213 CITATIONS   

SEE PROFILE SEE PROFILE

Paolo Nesi
University of Florence
255 PUBLICATIONS   2,088 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Governing the smart city: a governance-centred approach to smart urbanism View project

i-Maestro View project

All content following this page was uploaded by Mariano Di Claudio on 17 November 2014.

The user has requested enhancement of the downloaded file.

 Model-based development of an Automatic Train Operation
component for Communication Based Train Control
Mariano Di Claudio, Alessandro Fantechi(*), Giacomo Martelli, Simone Menabeni, Paolo Nesi
DISIT Lab, DINFO, Dep. of Information Engineering, University of Florence, Italy; (*) DINFO,
University of Florence, http://www.disit.dinfo.unifi.it, http://www.dinfo.unifi.it
(Mariano.DiClaudio, Alessandro.Fantechi, Giacomo.Martelli, Simone.Menabeni, Paolo.Nesi)@unifi.it
Abstract— In recent years, there has been a significant
development in the world of conventional and/or urban railway
systems. The evolution of technologies is leading to deployment
of new signaling and control systems, including the
Communication-Based Train Control widespread primarily in
metro network. Strengths of this technology are continuous bi-
directional communication track to train, so as to provide
timely information on the status of the train and the line, but
especially the possibility of implementing automatic guidance
through the ATO (Automatic Train Operation). ATO manages
the running of the train by adjusting traction and braking
according to safety limits, but replaces the driver also in other
operations such as opening-closing doors or the initialization of
the train. In this article, we describe the development of an
ATO system by adopting a Model Driven Approach that aims
to increase the coherence between the analysis and the
implementation phase. The main blocks of the system were
modeled with the UML notation, starting from the functional
requirements, while to show their behavior were used
statecharts. At the end a testing activity was performed for the
verification and validation of the whole model in order to
demonstrate the properties of consistency, completeness and
correctness.
I. INTRODUCTION
The Communications-Based Train Control (CBTC) is a
novel signaling and control system for light rail in urban
context (e.g., tramway), heavy rail (e.g., metro) and APM
(Automated People Mover, e.g., Airport metros) [1], [2].
These systems give operators precise control in the
movement of trains based on positions information
provided by the high precision onboard equipment.
However, much more control and status information can be
provided to the train exploiting a continuous bi-directional
track-train data communication. Currently, most of CBTC
systems implement this communication by using radio
transmission. These systems allow more trains to run on the
same line at higher frequency and speed (with or without
drivers) thus providing high capacity, efficiency, and
operational flexibility and reducing operating costs, while at
the same time guaranteeing reliability and safety. For CBTC
systems the reference standards are IEEE 1474.1-2004 and
IEC 62290. Although these documents do not constitute an
industry standard for CBTC system architecture and function
allocation, they provide a recommended practice for the
design CBTC products to be launched into the market.
The CBTC control systems are constituted by onboard
equipment and wayside equipment (see Figure 1). The
former is installed on the train and forms the on-board
subsystem (BSS). The latter is located at a station or along
the line and forms the trackside subsystem (TSS). The major
components identified in these systems are ATC (Automatic
Train Control), ATS (Automatic Train Supervision), ATO
(Automatic Train Operation) and IXL (interlocking system).
Figure 1: CBTC system components.
The ATC represents the technological evolution of classical
ATP (Automatic Train Protection) system ensuring train
safety in manned or fully automatic operation. It is the
subsystem responsible for the control and protection of the
train running. The ATC ensures that the authorized distance
to be travelled by the train (Movement Authority, MA) is
respected. It keeps under control the distance among the
trains, checks that the speed limits are respected and ensures
a continuous protection of the train in every condition.
Despite the significant structural differences between light
rail /metro systems and conventional rail, the CBTC systems
have similar needs to those of a conventional rail and can
include an ATC similar to that used in the conventional rail
(derived from ERTMS/ETCS signaling system), simplifying
and/or refining some aspects. The supervision and
management of train traffic is provided by the wayside ATS
subsystem. The ATS integrates other functionalities such as:
train depot management, train wakeup/sleep, integrated
maintenance, incident report/replay and train routing. The
ATS operates in combination with an IXL system (that
generates the signals for route control) if the latter is
included in the overall CBTC system. Finally, the automatic
control of train movement without drivers is ensured by the
onboard Automatic Train Operation (Autonomous Train
Operator, ATO) subsystem in combination with the ATC.
The ATO manages the train running from one station (or
predetermined operational stopping point) to the next,
automatically adjusting the train speed with appropriate
traction and braking commands. This automatic control with
regard to speed, acceleration, deceleration and jerk rate is
performed by the ATO respecting the required operating
conditions and the limits imposed by the ATC. The goal is to
ensure passenger comfort, as established by operating
policy, and safe operation. ATO can replace the driver also
in other operations (opening and closing doors, initial train
setup, etc.), making unnecessary the presence of a human
operator on board.
The work we present is part of a project aimed to address the
development a novel CBTC system at a lower costs, by
adopting a strategy to lower development costs that includes
both the adoption of modern software development
technologies, such as Model-Driven design, and the
exploitation of already available components by the
industrial partner, namely components already developed for
a typical ETCS system. Model-Driven design typically
requires a model of the system to be built first. In the
literature, we can find models of CBTC systems using
formal methods to enable the verification and validation of
the model via simulation or formal proof. The models
adopted are Petri Nets, Z notation, VDM. Formal
specification in UML and corresponding verification with a
rigorous mathematical model are very complex to be used
and their application to large systems very difficult. Model
checking and simulations are the typical verification and
validation models adopted, and in order to reduce
complexity are applied only to some of the subsystems. The
complexity of adopting formal modeling techniques typical
of Model-Driven design to CBTC systems has hence been
attacked by partitioning the modeling into subsystems.
In this paper, we present a specification and validation
process for ATO component of a CBTC system. Firstly, we
created a general architecture and a set of functional
requirements for ATO based on analysis of reference
standard and solutions proposed by main vendors. Starting
from this analysis we created a model for ATO using IBM
Rational Rhapsody. Finally, the simulation results, based on
a self-developed simulator and test results are shown. The
paper is organized as follows. In Section II, a general
architecture of ATO is presented together with a set of
functional requirements. Section III describes ATO
specification through UML diagrams with a focus on
specific functional blocks of the model. Validation process is
described in Section IV and some simulation and testing
results are reported. Section V contains an overview of those
research results most related to our work. Conclusions are
drawn in Section VI.
II. GENERAL ARCHITECTURE AND ATO REQUIREMENTS
The ATO is connected with a number of subsystems and
with the train as described in Figure 2. Based on the general
integration requirements and on the evaluation of the CBTC
solutions proposed by main vendors (Bombardier, Alstom,
Thales, Invensys Rail Group, Ansaldo STS, Siemens and GE
Transportation), the integration architecture has been
studied, where the interactions with the external components
which are present on board the train and on the wayside, are
described. The ATC guarantees train protection in
accordance with level 2 of ERTMS/ETCS standard. .
This subsystem creates a continuous communication sending
to the ATO the train position information, limit speed profile
and MA received from its trackside equipment positioned
along the line, called Radio Block Centre (RBC). The MA
specifies the distance that the train is authorized to cover and
additional information about the track, such as speed
restrictions, gradients, etc. The ATS is responsible for
sending mission data used in the Start of Mission and during
the train running. The mission contains a set of information
for each stop that the train must perform during the service.
These include: start time, stop point, side of the doors to be
opened and the time duration that doors must remain open.
The Maintenance Operator is the human dealing with the
ATO maintenance. The AS Designer is the human that
provides the configuration of the ATO system, the Platform
Doors Control Unit is the Device for platform doors
opening and closing, on the TSS side. Moreover, the
TRAIN subsystems includes: Command and Control Unit to
manage train braking and traction; Train Doors Control Unit
for doors opening and closing; Passenger Emergency
Handles operated by the passengers on board the train for
emergency braking. In order to complete the analysis of the
ATO, the communication protocols between ATS-ATO,
ATO-TRAIN, and ATC-ATO have been defined and
formalized, respectively. The ATS-ATO protocol has to be
compliant with three layers (Transport - Safety -
Application) of the ISO/OSI stack model. TCP is used as a
transport protocol for its ability to provide an end-to-end
bidirectional connection, byte oriented service with
verification of the correct delivery order and with error and
flow control. Details of the protocols are omitted for lack of
space.
Figure 2. ATO Application Environment.
Based on these general functionalities and on the
analysis of reference standards a set of functional
requirements that specify the expected behavior of ATO
have been identified. The operating context highlighting the
interfaces and the messages exchanged among components
are shown in Figure 2. The information exchanged have
been identified on the basis of the functionality associated
with the ATO.
For the ATO, the following main requirements have
been identified. Train initialization: the capability to
initialize all the onboard systems. It must be able to
complete the initialization procedure of the ATC.
Automatic speed regulation: start, stop, and speed
regulation of the train as it travels along the track shall be
automatically controlled by the ATO to control speed,
acceleration, deceleration, and jerk rates according to
specified passenger comfort limits (as defined by the
authority having jurisdiction). The train speed has to be less
than the over-speed limits imposed by ATC, in all conditions
of the train. Platform berthing control: an ATO system
shall be capable of implementing any platform berthing
control modes. Door control: an ATO system shall be
capable of automatically controlling train doors during
passenger boarding and discharging. Fault recording and
reporting to ATS: failures and out-of-tolerance conditions
detected by, or input to, ATO that can impact the on-time
performance of the transit system or result in some other loss
of specific functionality may be automatically indicated on
the ATS user interface display. Any alarms shall be
categorized and prioritized into critical and noncritical
alarms and logged.
Moreover, the ATO development is conditioned by
additional key factors as compliance with: reference
standards of Communications-Based Train Control
technology: IEEE 1474.1-2004, IEC 62290, CENELEC
standards EN50128, 50126, 50129 in order to meet the
demands for safety , ERTMS/ETCS Baseline 3 (BL3) for
use of some technologies within the ATO.
III. SPECIFICATION
In order to specify and design the ATO BSS component of a
CBTC system a model-based/model driven approach (MDA)
has been adopted, usually referred as "Model-Based Systems
Engineering" - MBSE [3], [4], [5]. This approach aims to
enhance the connection between the system model and its
final realization, increasing the coherence among the
analysis and the implementation phase. The model is the
central element in this approach, thus a system can be
represented and specified at various level of granularity such
as the operational, functional, and technical aspects. MDA
always keeps the model updated and related to the final
system during all the phases of software development
process, and even when the system is complete and
maintained.
Referring to the ATO functionalities exposed, a model
divided into different packages has been designed. Each
package is a set of functional blocks that perform the sub-
features of the functionality associated to the package. The
UML Package diagram in Figure 3 shows the structure of
the designed model and the interconnections between the
various packages. In the diagram, there are two main
packages that represent two main features of the ATO: Init
(initialization of on board systems) and Running
(management of the train running). The other packages
model communication protocols with external entities
(ATCprotocol, ATSprotocol, TrainProtocol, and
JRUprotocol). There is also a package that records/logs all
system actions, LogPkg, of the ATO side. The structural
specification of the packages is given by means of UML
Class diagrams for what concerns the structural aspects, and
by UML State diagrams for what concerns behavioral
aspects.
The general principles followed in order to build the ATO
model are those necessary to have a consistent and robust
model. For example, in order to meet the reliability
requirements it has to always provide non-blocking states. In
addition, there is a method of logging all actions of the system in order to
track the behavior of the model.
ATSprotocol JRUprotocol
TRAINprotocol
ATCprotocol
«Usage»
Interfaces
Running
«Usage» «Usage»
«Usage»
Events
Init LogPkg
«Usage»
Figure 3. Package diagram of ATO.
According to the features described in section II, in the
following sections the main blocks of the ATO specification
are reported and discussed, by putting in evidence the
complexity and the most critical aspects. The same issues
have been in the main focus of the validation process
described in Section IV. For the UML modeling, the IBM
Rational Rhapsody (versions Designer for Systems
Engineers and Developer for C++) has been used. This tool
offers a visual SW development environment and improves
productivity managing the whole lifecycle, from
requirements capture to model development,
implementation, test and deployment. Its main strengths are
support for team collaboration; automated code generation,
that allows you to move from design to implementation,
simulation and model-based testing. It enables the use of
execution to validate models and offers some plug-in for
automated testing. It is also possible to integrate in
Rhapsody objects representing particular functionality
modeled in the most appropriate way with external tools
such as Simulink (used to design the control blocks), and
then achieve a co-simulation of the entire model [6].
Moreover, for the verification and validation a specific
approach has been used since the automated validation and
test provided by Rational Rhapsody presents some
limitations to cope with the complexity of the specified ATO
system.
The Running package contains the components that are
involved in various operation for the automatic management
and control of the train running between two predetermined
operational stopping points once the initialization is
complete. This package is more complex, since it has to take
into account a higher number of constraints. Inside Running
package of Figure 3, there are blocks for the management of
data coming from the outside (ATC, ATS, TRAIN
interface), blocks for calculating speed profiles and for
tracking of these curves and two logic blocks responsible for
the activation of controllers and of all the actions necessary
for moving the train from one station to another. These two
logic blocks were subject to a test phase to verify the
correctness and the compliance with requirements.
The core part is the block Running_Manager that interacts
with others blocks of the package and with the external
blocks, as shown by the class specification diagram in
Figure 4. The elements of Running package can be classified
into interface blocks, logical blocks and control blocks.
Interface blocks are ATSData_mng, ATCData_mng, The entry point is the Standby state and if the
TagData_mng and TrainData_mng. The first two manage ControllerLogic is active it switches to the pre_active state.
the input/output data exchange with ATS and ATC The latter is divided into 2 concurrent substates (AND
components. TrainData_mng simulates the positioning of states). In the upper side the reporting of some train data is
tags necessary to ensure the stopping accuracy required by executed. In the lower side ControllerLogic performs the
the functional specifications. TrainData_mng manages the operations concerning the train departure from a certain
input/output data exchange with Command and Control Unit stopping point (station) and the management of train
(for automatically control the brake/traction) and Train running. Each of these operations is executed in a predefined
Doors Control Unit (for automatically closing and opening state. To allow the train to start, the operations to be
of train doors). executed are: verifying that the current time is greater than
or equal to the departure time obtained from the Mission
«Block»
LogPkg::Log
1 Plan (state TimeControl), train position updating to the most
«Block»
ATCprotocol::ATCExecutor
1 11
«Block»
TagData_mng
recent value retrieved from Gestore_DatiATS (state
SerialComm iATPact
1
1
PositionUpdate), sending of authorization for the train doors
Init::Initialization_Manager «Block»
ATSData_mng closing (state ClosingApprovalSending) and enabling of
1
1 «Block»
Running_Manager
1
1 1 blocks OrdinarySpeedController and SpeedProfileSelection.
1
«Block»

1
«Block» 1
TrainData_mng
To manage the train running, ControllerLogic switches to
ATCprotocol::ATCMessage_Manager
1
the InControlstate where the traction and braking commands
1 1 will be determined based on the speed profile to follow.
«Block,SimulinkBlock» «Block»
SignalingSpeedProfileGenerator ATCData_mng 1 When the train reaches the next planned station the train
«Block»
1 SpeedProfileSelection doors open in the same way as done for closing operation.
«Block,SimulinkBlock»
OrdinarySpeedController 1 Standby Idle
evIdle
1 1 evStart evAttiva
«Block,SimulinkBlock» «Block» pre_active
ServiceSpeedProfileGenerator ControllerLogic dataReport
tm(2
idle
00)
tm(200)
evStateControl
Figure 4. Class diagram of Running package of Figure 3. TimeControl evErrorNotification
PositionUpdate

tm(1000)
evClosingApproval
ClosingApprovalSending
The external blocks belong to other packages of the ATO
system structure that interact with Running_Manager. These MACheck
tm(1000) evSateRepeat
ClosingCheck

evClosingDoorsApproval to itsTrainData_mng
are specifically Initialization_Manager, ATCExecutor, evClosingApproval evClosingRepeat
evErrorNotification
ATCMessage_Manager and Log. The control (or functional) evEnabling

blocks identified are ServiceSpeedProfileGenerator, ATSEventWaiting

SignalingSpeedProfileGenerator, OrdinarySpeedController. evErrorNotification

ClosingAttemptsCheck
evAttemptControl
These blocks have been developed by using Simulink. The evClosedDoors
first builds a reference curve VN-SER (VN is the Nominal Enabling
InControl
evEnableErrorNotification
Velocity) that meets specifications given in terms of
maximum acceleration, maximum jerk, time of arrival and evPStationErrorNotification

evSpeedErrorNotification
stopping accuracy, exploiting information related to train evErrorNotification
BlocksEnablingCheck
evConfirmation
position (received from ATCData_mng), the location of the evEnablingControl
tm(1000)
station and service speed (received from ATSData_mng). evAttemptControl
EnabledBlocksConfirmation
evInControl
The second produces a reference curve VN-SEG, upper OpeningControl evErrorNotification evDisabling
OpeningAttemptsCheck evErrorNotification
limited by the signaling speed profile (VSEG), allowing the evOpeningApproval
disablesLDSDPDV
evOpeningRepeat OpeningApprovalSending
train to stop within the limit established by the MA, and to evOpenedDoors evOpeningDoorsApproval to itsTrainData_mng
evOpeningApproval tm(1000)
resume the service due to an extension of the same MA. OpenedDoors StoppingTimeCheck
evStateControl
Finally, the latter operates a control based on the trajectory tm(1000)

planning, i.e., performs the tracking of the reference speed

VN generating the traction and braking percentage as a Figure 5. State diagram of ControllerLogic of Running package of Figure 4.
function of the error VN-VMETRO (where VMETRO is the
actual train speed). These blocks are been realized in IV. VALIDATION
Simulink and then integrated in the model.
In order to verify that the ATO model meets expected
The logical blocks are SpeedProfileSelection and functional requirements and it is consistent, complete, and
ControllerLogic. The SpeedProfileSelection performs a correct a verification and validation activity by testing has to
comparison between the service profile and the signaling be performed. In our context we want to verify if the ATO
profile to select the most restrictive one. This represents the system's behavior shown by the model was compliant with
VN transferred to other logic blocks as ControllerLogic. ATO System's specification, defined during the analysis
ControllerLogic handles activation/ inhibition of the phase. Once modeled the ATO component with IBM
functional blocks and consequently supervises the traction Rational Rhapsody UML tool, the testing process has been
and braking commands to be applied to the train. The scheduled for the generation and execution of test suite with
behavior of this block has been modeled by the State the aim of analyzing the results. Indeed, the best practice in
diagram shown in Figure 5. the so-called model-based testing is to test the system
running a test suite generated from the model of the system,
for test case generation a first approach was to use the ATG
(automatic test generator) tool provided by the Rhapsody
suite. In this way, we could use the system model as input to
ATG and obtain automatically test cases in output. However,
it was not possible to achieve good results for validating the
whole system. The ATG tool has proved insufficient to test
the model exhaustively; in fact, some function blocks nested
within states of the various Statechart modules have been not
considered by the ATG, thus leaving hidden large parts of
logical and functional aspects. This limited the validity and
the coverage of the produced tests from the ATG.
We have therefore adopted a different method with the aim
of achieving full test coverage of the system. To this end,
criteria regarding test cases generation and testing coverage
have been applied. For this purpose, a "test environment"
has been built. It consists of a model and tool (specified with
its own formal specification via Statechart) modeling all the
external components which interact with the ATO in Figure
2. The external system emulates the environment by loading
real traces and generating input and/or events needed to
simulate the behavior of ATO system components involved
in all the specified test cases. Each test case and trace can be
focused to verify one or more specific functional
requirements which can include several components of ATO
system. Then, each test case was executed against the
simulation of the realized ATO, system obtained by using
automatic C++ code generation from UML models, using
IBM Rational Rhapsody development tool and then
compiled by using the native code compiler.
The simulation allows keeping track of all the sequences of
states within the realized State diagram, caused by sequences
of inputs/events sent by external entities involved in this
context. During tests, the sequence of operations performed
and all the significant values are recorded in the log file, as
usually performed to keep trace of the ATO behavior. Thus,
it is possible to verify if the system’s response is compliant
with expected requirements and specifications and according
to the expected and correct ‘state’.
In the following paragraph, an example of the validation
experience for the above presented ATO blocks related to
the management of running phase is reported.
For the functionalities of the Running block, the blocks
ControllerLogic and SpeedProfileSelection are central, while
the Simulink coded blocks (mentioned in Section III) have
been used only in order to send events, to change variables
values and to trigger the transitions between the states of the
whole ATO system. Within the test environment we have
simulated first the route that a train follows in different
conditions. So the system was able to start the service
provided by the mission plan verifying that all preparatory
operations for the departure of the train have been executed
properly. For the arrival at the station we have checked that
the block ControllerLogic has verified that the train speed
reaches the value of 0m/s and the train position complies
with the stopping point defined by the Mission Plan. After
these last two checks, it has been verified that the system
autonomously disables the block SpeedProfileSelection and
that subsequently pass to send the authorization to open
doors, waiting for a response to confirm that the train doors
have been opened. In relation to the operations described, we
have defined a set of test cases considering the functional
requirements involved and the inputs needed for their
verification. Moreover, also tests to verify the robustness of
the ATO system have been performed. The inputs were
generated for both verifying the nominal behavior of the
ATO system's model and assessing the fault tolerance
capabilities against eventual, e.g., a wrong sequence of
events/transitions. A test has been considered successful
when the results have been proved to be consistent with the
expected behavior -- i.e., the sequence of transitions/events
encountered is such as that provided by the specific scenario.
In total, 15 test cases have defined. They allowed us to test
the system in a comprehensive manner. At the first
execution, some tests failed (e.g., the infinite loop into a
state was not managed) highlighting the presence of some
errors in the early ATO model. Following this first result,
the ATO model was corrected accordingly. Then, the
regressions testing demonstrated that the second version of
the ATO passed the verification and validation test.
The final results obtained have been significantly better. In
fact, all tests were successful passed. Please note that, the
test covered/involved the 100% of the modeled states, and
90.1% of transitions. The missed transitions have been a
small part of those associated with detection of unexpected
and unrealistic errors, in a so-called Defensive Programming
approach. These transitions cannot be realistically exercised
by any input to the ATO.
Notice that the state coverage corresponds, in traditional
code structural testing, to statement coverage, while
transition coverage corresponds to branch coverage. Indeed,
CENELEC safety guidelines, rule the use of coverage-based
testing in the validation of safety-related systems. Full
statement coverage is highly recommended for all safety
related systems (having a Safety Integrity Level (SIL) from
1 to 4), but has to be complemented with finer coverage
testing for SIL 3 and 4. ATO is not considered a safety-
related system, since safety is enforced by the ATP system
inside a CBTC system. However, errors in ATO may
strongly affect availability: indeed, an erroneous control of
traction which activates ATP frequently results in reduced
performance and availability of the transport system. At this
regard, having used verification criteria that are required for
SIL2 systems looks appropriate.
V. RELATED WORK
There is a large literature concerning the development
approaches of CBTC systems that currently represent the
last evolution of signaling and control systems in urban
context. A common aspect of these development methods is
the use of system modeling to be realized as a primary form
of expression. The different approaches can be classified
according to the system modeling technique used and the
formal methods or structured approaches to verify the model
realized. Typically, formal denotational models for behavior
specification such as VDM, Z and temporal logics may be
used for system specification while the verification can be
performed by using theorem provers [7]. This approach is
viable only for small systems due to the explosion of
complexity and difficulties in formal proof. The alternative
consists in passing from the specification performed via
 denotational model to an operational model such as Petri
Nets or state machines. Operational model can be validated
for simulation, and also using model checking, history
checking techniques. In [8], the system modeling technique
is based on the use of the SCADE too, that allows for the
management of requirements, system modeling and
automatic code generation; code generated by the tool is
certified according to the standard EN 50128 SIL 4. In [9],
the Z notation is used for the specification of the system and
the SMV model checker for the verification through
simulation of the model. In [10], some BSS ATP
components of a CBTC system is modeled with Colored
Petri Nets (CPN), while the validation is performed by using
simulations. In [11] the CBTC model is based on Stochastic
Automata Networks (SANs): these are based on Markov
chains. In [12] the authors illustrate an approach for formal
verification applied to the train-to-ground communication
link verification component of CBCT system. This is
implemented with the TANGRAM (Tool for Analysis of
Diagrams) tool that performs automatic translation from
UML diagrams into equivalent timed automata. In [13] an
approach based on the Harmony model-driven hybrid
iterative process that uses UML/SysML as modeling
language is presented. The model is tested with the
assistance of a CASE tool to verify and validate the
functional requirements. The latter are converted into use
cases and assigned them to development cycles. For each
development cycle, they conduct analysis, design,
implementation, and testing. The ATO specified, as
described in this paper, allows to be used on systems that
have been designed so that a human driver is present on-
board.
VI. CONCLUSIONS
The need to create railway signaling systems with
characteristics of efficiency, security and interoperability,
has seen in recent years the definition of new procedures
and standards that will align this industry, and the rise of
new technologies such as CBTC that extend these issues in a
urban rail context. An element of innovation in a CBTC
system is the ATO subsystem responsible for automatic train
operation in combination with ATC. The main functional
requirements that the ATO must fulfill are: Train
initialization - Automatic speed regulation - Platform
berthing control - Doors control - Faults handling. In our
work we have developed this component with a model-
driven approach using UML notation, so the model is the
central element and the system can be represented at
different levels of detail. The two main features of the ATO
are modeled within the packages Init and Running, and we
have described in details on the latter. For UML modeling
the IBM Rational Rhapsody tool has been adopted, but for
the validation phase the ATG tool, included in Rhapsody,
has not been proved able to test the whole model
exhaustively. For this reason we have adopted a different
method to verify the full test coverage of the system. A test
environment has been built, in order to emulate the external
components with which the system must interact. This
environment has been triggered with real traces to simulate
View publication stats
the behavior of the ATO system components related to one
or more specific functional requirements.
ACKNOWLEDGMENTS
This work was partially supported by the PAR FAS
2007-2013 (TRACE-IT) project, in collaboration with ECM
S.p.A., a company producing solutions and technologies for
the safety and control of railway infrastructures.
REFERENCES
[1] R. D. Pascoe and T. N. Eichorn, "What is Communication-
Based Train Control?," IEEE Veicular Technology Magazine,
vol. 4, pp. 16-21, 2009.
Siemens AG, Trainguard MT The scalable automatic train
[2]
control system for maximum flexibility in modern mass
transit, 2010.
[3] A. Ferrari, G. O. Spagnolo, G. Martelli and S. Menabeni,
"From Commercial Documents to System Requirements: an
Approach for the Engineering of Novel CBTC Solutions,"
International Journal on Software Tools for Technology
Transfer (STTT), 2013.
[4] E. Kindler, "Model-based software engineering: the
challenges of modelling behavior," in Second International
Workshop on Behaviour Modelling: Foundations and
Applications, Proceedings of, New York, 2010.
[5] P. F. Franzini and P. M. L. Sala, A Model Driven Approach to
the Development of the controller for an unmanned all-terrain
veichle, Milan, 2007-2008.
[6] T. Sakairi, E. Palachi, C. Cohen, Y. Hatsutori, J. Shimizu and
H. Miyashita, "Model Based Control System Design Using
SysML, Simulink, and Computer Algebra System," Journal
of Control Science and Engineering, p. 14, 2013.
[7] P. Bellini, P. Nesi and D. Rogai, "Expressing and organizing
real-time specification patterns via temporal logics," Journal
of Systems and Software, v.82, no.2, pp.183-196, Feb. 2009.
[8] Z.-H. Quan, S.-A. Choi, D.-H. Choi, C.-H. Cho, G.-S. Park
and M.-S. Ryou, "Modeling for CBTC car-borne ATP/ATO
functions and its applications," in SICE Annual Conference
(SICE), 2011 Proceedings of, 2011.
[9] F. Yan, "Studying Formal Methods Applications in CBTC,"
in Management and Service Science (MASS), 2011
International Conference on, 2011.
[10] L. Chen, B. Ning and T.-H. Xu, "Research an Modeling and
Simulation of Vehicle-on-board Automatic Train Protection
Subsystem of Communication Based Train Control System,"
in Vehicular Electronics and Safety, ICVES. IEEE Int. Conf.
on, 2007.
[11] H. Zhao, T. Xu and T. Tang, "Towards modeling and
evaluation of availability of communication based train
control (CBTC) system," in Communications Technology and
Applications, ICCTA'09. IEEE Int. Conference on , 2009.
[12] A. L. N. Muniz, A. M. S. Andrade and G. Lima, "Integrating
UML and UPPAAL for designing. specifying and verifying
component-based real-time systems," Innovation in Sys. and
Soft. Eng., vol. 6, no. 1-2, pp. 29-37, 2009.
[13] C. Yang, J. Lim, J. Um, J. Han, Y. Bang, H. Kim, Y. Yun, C.
Kim and Y. Cho, "Developing CBTC Software Using Model-
Driven Development Approach," in Proc. of WCRR, 2008.