See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/326208320
System Integration: Challenges and Opportunities for Rail Transport
Conference Paper · June 2018
DOI: 10.1109/SYSOSE.2018.8428760
CITATIONS
READS
8
3,839
1 author:
Mohammad Rajabalinejad
University of Twente
76 PUBLICATIONS 394 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
SIRA: System Integration for Railways Advancement View project
All content following this page was uploaded by Mohammad Rajabalinejad on 07 September 2018.
The user has requested enhancement of the downloaded file.
System Integration: Challenges and Opportunities
for Rail Transport
Mohammad Rajabalinejad, Assistant Professor
Faculty of Engineering Technology, Department of Design, Production and Management, University of Twente
Enschede, Netherlands
M.Rajabalinejad@utwente.nl
The challenges on the right-side of “the V model” are often
more than its left-side for Systems Engineers. And so are the
challenges of assembly of products comparing to taking them
apart, integration of systems comparing to their decomposition,
or testing systems comparing to their analysis. For System of
Systems, this is even more confronting because a complete
definition of system is not always available or often only a part of
the system is changing. Referring to real-cases, this paper
highlights the problem and suggests basis for integration
primarily for rail transport.
Co-integration; co-creation; safety; rail; systems engineering
I. INTRODUCTION
Europe faces a huge integration challenge for its rail
transport. European Commission aims a competitive transport
system in which rail transport plays a key role. One of the goals
is that “thirty percent of road freight over 300 km should shift
to other modes such as rail or waterborne transport by 2030,
and more than 50 % by 2050, facilitated by efficient and green
freight corridors.”. To accomplish this goal, a trans-European
rail transport which is capable of high speed for medium
distances is unavoidable. Other goals are that “By 2050, all
core network airports should be connected to the rail network,
preferably high-speed; all core seaports are sufficiently
connected to the rail freight and, where possible, inland
waterway system.”. This leads to a single European rail area
operating openly across the whole Europe under agreed (non)technical demands [1].
There are multiple stakeholders for the rail systems at the
national, European, and International levels. They have
different views, skills, responsibilities, goals, behavior, and
interests. These stakeholders continuously demand a higher
level of integrity for the project and the level of tolerance
acceptance is becoming lower and lower. Extra rules and
measures do help improving safety, but they may also add to
the complexity and tight coupling; there is doubt if extra
regulations can always provide a higher safety level in risky
circumstances. Compliance with regulations of different
domains for different stakeholders can be confusing. The
complication of complying with recent regulations leads to
unclear responsibilities resulting additional resources for time,
energy, and cost. Besides, this confusion hinders the decisionmaking process and delays design or operational decisions.
Striving for perfection in complexity is a challenge. The
978-1-5386-4876-6/2018/$31.00 c 2018 IEEE
projects are becoming increasingly complex. This complexity
demands often demands high tech and smart solution to ensure
continuous performance at the desirable level. On the other
hand, system performances are increasing both in quantity and
quality. For example, not only a higher quality rail service is
requested in a shorter period of time but also the number of
passengers is increasing (see [2]).
Surprises happen including (non)intentional incidents,
failure of train systems, poor-design issues, incompetent use, or
misuse of the system. The domino effect of such safety
surprises negatively influences system values and discards its
quality. As the interconnectivity offered by internet grows (see
e.g. Smart Industry outlook), the side-effects of these surprises
may become large scale, complex and beyond the foreseeable
outlook. On the other hand, the risks must be reduced to an
acceptable level or a level that is As Low As Reasonably
Practicable (ALARP). This encourages the goal-oriented
approach which imposes more freedom and more responsibility
to rail industry.
European Rail Traffic Management System (ERTMS) has
become a standard for ATCS (Automatic Train Control
System). European Commission dropped specifications for
functional requirements for ERTMS in November 2012 and
made those specifications no longer mandatory. The remaining
specifications allow multiple interpretations and become
ambiguous. ERTMS facilitates interoperability among
countries and among projects. This influences the supply
market and increases competition within the industry. The
result of this is the absence of a single entity that handles the
railway system. Because of these circumstances, European
Railway Agency (ERA) watches a decreasing progress in
safety improvement: “Despite a positive long-term trend in the
risk of fatal train collisions and derailments over the past two
decades, the data suggests that the progress has been slowing
down since 2004” [3].
As results, the degree of fragmentation of the rail systems
and its interconnectivity, multi-stakeholder nature of making
decision, variety of views of stakeholders, numbers of (revised)
rules and regulations, and arrival of modern technology may
intensify the effects of the safety surprises and impose risks to
the rail industry, people, and society. On the other hand, the
urge for advancement and the need for changes create an
opportunity for the rail industry to upgrade its services and earn
Figure 1. The “V” model for rail industry, adapted from [3].
competitive advantages over other means of transportation e.g.
air transport.
This research studies the needs for integration in a multi
stakeholder, complex and dynamic environment such as rail
transport. It reviews the seminal references and a few best
practices for integration. Besides, several cases are presented to
highlight the scale of the integration problems in rail transport.
The research is based on several case studies conducted on the
areas of systems engineering and systems safety through
research and education in the University of Twente. It
combines the outcomes from literature study, various research
projects, expert interviews, and workshops on the topic of
system integration in the Netherlands through the Railforum
platform.
Next section explains the standard model of practice for the
rail industry and presents several example issues at the national
or European level. Section III reviews seminal references and
best practices for integration. Section IV integrates and
discusses the results. Section V summarizes conclusions.
II. FULL LIFECYCLE
Figure 1 presents the standard full life-cycle or the “V”
model for rail transport [3]. The left side of this model is about
co-creation while its right side focuses on integration,
implementation, and disposal. Further details follow.
A. Co-creation
It is a set of clear objectives and maintaining them across
the organization that fundamentally contributes to success. The
importance of objectives is becoming increasingly evident
when complexity rises. Clear objectives ensure directing the
organization towards the preidentified goals. In practice,
however, there are still many technical factors contributing to
the final goals. To highlight the interconnectivity of these
factors, one should view the influence of any design or
decision on these factors at the system or subsystem level.
It has been discussed elsewhere that there is no longer the
case that one single organization can make the rail transport
successful. Having a clear set of objectives, stakeholders need
to work together and co-create shared values and solution
where everyone benefits. Literatures conclude four different
pillars of user, operation, technology, and supplier for creating
shared values [4-6]. These have been described as follows:
•
•
•
•
User is the individual or organization that uses the
service provided by the system.
Operation includes hosting passengers, (re)scheduling
and driving trains, and offering the services that
users demand. It holds activities needed for
operating the system.
Technology is the technical installation that enables
operation of the system.
Supplier is the product producer or service provider
for the system.
Therefore, cooperation and co-creation of values for
achieving the shared goals is key for the left-side of the V
model. Next subsection explains the right side this model.
B. Integration & operation
A quick look at the V model in Figure 1 reveals that the
focus of its right wing is on integration. While the steps in the
left side are described in further details, the integration,
validation, and acceptance are the main blocks on the right
side. Some stakeholders at this stage assume that the realization
and integration will be realized according to their expectations
expressed during the design phase, but experience proves that
is not always the case and unexpected problems at the
integration phase may appear. As a matter of fact, there is often
a need for co-integration. For illustration, integration of a new
train with updated technology to the available infrastructures
may result integration issues in different cases. The experience
shows that integration is not always straight forward, and it
may impose further cost, delay or concerns into the project.
Next, several examples for the integration issues for railway
are presented (see https://integration.engineering).
1) ERTMS
Currently there are more than 20 train control systems
across the European Union. Each train used by a national rail
company must be equipped with at least one system but
sometimes more, just to be able to run safely within that one
country. Each system is stand-alone and non-interoperable, and
therefore requires extensive integration, engineering effort,
raising total delivery costs for cross-border traffic. This
restricts competition and hampers the competitiveness of the
European road transport by creating technical barriers to
international journeys. To overcome these issues, ERTMS (The
European Railway Traffic Management System) is designed to
gradually replace the existing incompatible systems throughout
Europe as a unique European train control system. Figure 2
represents ERTMS Level II where Eurobalise data is
transmitted to the train and to the control center for effective
and safe operation.
The integration of ERTMS with the currently operating
infrastructures may cause incidents. For example, in September
2017 a train continued to move with “full movement authority”
after crossing the border between two member-states while it
had supposed to stop. This incident was a result of a disorder in
transmitted signals and values across the border.
2) TGV fast trains
When new TGV fast trains were ready to be integrated
with the running infrastructure in France, the France’s national
rail operator SNCF realized that they are too wide for 1,300
stations. The cost of this problem for SNCF was estimated to
be around €50 million [8]. Public reacted negatively to this
mistake appeared in integration seeing that as waste of
resources.
3) Fyra
Fyra was an international high-speed rail service that did
not manage to successfully integrate with the operating
platforms in Netherlands and Belgium. After a month of
operation, more than 5% of all trains were cancelled and less
than 45% of them ran on schedule [9]. The continuous
problems with Fyra have caused public outcry in both nations.
The allowable speed for Fyra had been reduced several times.
Less than four years after the first operation, the contracted was
cancelled in May 2013 [10].
Figure 2. A graphical representation of how Eurobalise data is transmitted to
the train and to the control center for ERTMS level II [7].
III. SYSTEM INTEGRATION
This section reviews dealing with system integration form
different perspectives of systems engineering, project
management, standards and safety aiming to develop a
multidimensional view on the areas that a proper integration
process must cover.
A. Systems Engineering
The famous V model has two sides: the left-side is about
decomposition and definition and the right side is about
integration and verification [11]; decomposition and integration
almost summarize this model. In systems engineering (SE)
handbook, integration is listed among the technical processes
[11]. This handbook defines the purpose of integration process
“to synthesize a set of system elements into a realized system
that satisfies system requirements, ….” The SE handbook
suggests different strategies and approaches for integration e.g.
top-down integration, criteria-driven integration, or incremental
integration. Through this handbook, integration is often used
with words such as verification, validation, and test. Beyond
the physical elements, integration of software with hardware
and human system integration are discussed. Although the SE
handbook defines integration as a technical process, it only
once refers to integration requirements. On the other hand, the
systems engineering guide for writing requirements does not
provide any information about writing integration requirements
[12].
Figure 3. An example integration problem for rail industry [8].
Although integration enjoys technological supports, it is
beyond a purely technical process. From this perspective,
model driven approach or model-based systems engineering
(MBSE) is a fundamental enabler. The SE handbook also pays
attention to human system interaction further discussed through
another subsection for safety. Next subsection explains why
systems engineering should pay more attention to project
management for integration or implementation.
B. Project management
The integration process was named as an unresolved issue
for systems engineers through a panel discussion at INCOSE
International Symposium in 2006. The panel moderator, Dr.
Avigdor Zoonenshain, concluded that integration is a
challenging task because it needs synthesis, needs dealing with
interfaces, multidisciplinary team, test, evaluation, validation
and because it full of surprises. One year later, integration of
systems engineering with program and project management
was discussed in a similar event. The panel, moderated by R.
Ade, shares the observation that the best systems engineers
have been program/project managers and the best
program/project managers have been systems engineers. This
has been a subject for further research resulting in valuable
publications for the years after this event e.g. [13, 14]. The
outcome shows that this joint area covers most of integration
concerns and challenges. Some of the important integration
challenges have been discussed in [15] in details in terms or
requirements, validation and interfaces. In fact, management of
interfaces is one of the critical tasks for system integration.
Gerrit Muller explains strategies for coping with integration
problems where policy, requirements and design nonlinearly
contribute to integration [16]. Kouassi presents applications
where system integration succeeded to mitigate risks [17]. J.
Armstrong reviews approaches to address integration problem
and ways to improve the integration process [18]. The
advantages of model based approach for integration have been
discussed e.g. in [19, 20].
In conclusion, integration is a phase where the skills of both
systems engineers and project managers are needed. Not only
paying attention to interfaces and requirements but also proper
knowledge about policy, system and experience helps making
decisions that minimizes the risk of integration problem.
C. Standards
The ISO standard for systems and requirements engineering
demands requirements for human system integration [21]. This
standard demand specifying requirement for the interaction of
human and system. ISO 15745 elaborates in integration
models, processes, and information. From the industrial
perspective, this standards looks into integration of software,
applications, network, or information exchange [22, 23]. ISO
9001 and ISO 55001 primarily focus on integration of the asset
management system with the business process [24, 25]. ISO
10303-233 specifies an application module for the
representation of the variety of general model classifications
used to support model-based systems engineering. It brings
together the system modelling capabilities and the program
management capabilities and uses EXPRESS which is a
standard data modeling language for product data [26]. CMMI
makes extremely abstract models for generalization and
improvement of processes [27].
While interoperability is the aim for the rail industry across
Europe [28], the state members must check the technical
compatibility of subsystems with the railway system into which
they are being integrated and the safe integration of these
subsystems in accordance with the scope of this Regulation
[29]. EN 50126-1 pays specific attention to integration defined
as the process of assembling the system elements according to
design specification [3]. Here integration is linearly positioned
after manufacturing, see the right-side of Figure 1. This
standard demand for integration requirements for preexisting
subsystems or components. Integration is among the activities
explicitly discussed through the RAMS (reliability, availability,
maintenance, and safety) process. Integration phase aims to
achieve a complete system that works together as defined by
interfaces achieving the RAMS requirements.
This concludes that policy, organizations, management, and
technology all play roles in quality of integration, and safe
integration is desirable outcome for policy makers in Europe.
D. Safe integration
Improper integration can damage properties, environment
or human life and therefore have direct influence on safety. In
his book named Normal Accidents, Perrow explains how
integration of coupled systems can lead to accidents [31]. Need
for integration of safety assessment with systems engineering
has been discussed e.g. in [32-34]. SE handbook highlights
human system integration (HSI). HSI considers domains such
as human factors engineering (human performance, human
interface, user centered design), workload (normal and
emergency), training (skill, education, attitude), personnel
(ergonomics, accident avoidance), working condition and
health (hazard avoidance) [35]. These domains have direct
links to safety. As a matter of fact, integration is similar to
safety from several perspectives inheriting a multidisciplinary
nature where different techniques and methods can be used for
safe system integration, see e.g. [36]. The Swiss cheese model
of accidents, developed by J.T. Reason and shown in Figure 4,
presents a model for integration of different system layers in
which the risk of a threat may become a reality [30].
Seminal safety references pay attention to integration. ISO
12100, the reference standard for safety of machinery, pays
special attention to safety matters during assembly of a
machine or its integration with the surrounding environment
[37]. IEC 61508 a seminal standard for functional safety
delivered in several parts. Its first three parts focus respectively
on general requirements, requirements for E/E/PE, and
Figure 4. The Swiss cheese model of accident causation [30].
It enables to track the physical or logical chain of influence
for changes in the status of subsystems or components. This
is prerequisite of management of capital assets or big data.
Here Model Based Systems Engineering is a fundamental
technological enabler.
C. Decision support
Right decisions at right moments by right people provide
huge competitor advantages. This not only needs the
knowledge of governance and capabilities but also the
knowledge of culture and alternatives. For example, finding
the right balance among safety, cost, capacity, and speed
requires experience, managerial or leadership skills,
supporting information and technological enablers.
Figure 5. Four areas for system integration.
requirements for software for safety-related systems. Part 1 of
this standard addresses issues on system safety validation and
system integration (tests) including architecture, software, and
PE integration tests. Part 2 addresses the module and system
integration for safety-related systems, and Part 3 focuses on
software testing and integration.
Integration is comparable with safety inheriting
multidimensional problems where stakeholders with shared
goals need experience and technology to make proper decisions
and remove, minimize, or control the risks.
D. Body of knowledge
A solid foundation for knowledge dissemination is a
need for suitable growth. Knowledge about past lessons, best
practices, or design and construction concerns helps smooth
transition of new subsystems components e.g. new coaches.
It facilitates sharing the experience and recommendations for
future developments.
V. CONCLUSION
The V model for systems engineering is widely practiced
including for standard rail-related practices. Currently, the
integration process is seen as a technical process which seems
to be insufficient to address challenges for rail transport. In
other words, next to technological enablers, stakeholders need
to continue working together to realize shared values and
objectives. Alliance of technology and knowledge promises
better performances for system integration.
IV. SUMMARIZING RESULTS AND DISCUSSION
There are four areas that summarize the points reviewed
earlier through this paper. These areas are system definition
and overview, coherent frameworks for communication and for
making decision, and knowledge dissemination as shown in
Figure 5. They must be developed simultaneously for the
optimal system performance. While the upper part of this
figure is enabled by technology, its lower part needs effective
cooperation among stakeholders enabled by shared goals,
experience, and knowledge. This figure represents the area of
focus, cooperation, and simultaneous development. Further
explanation about these areas follow.
A. Overview
Two critical success factors are a clear set of objectives
across the stakeholders and cooperation for creation of values
[4]. A proper system definition, a sharp vision for the goals and
a simple interface for describing the rail transport is key to
communication, shared understanding, and collaboration.
Therefore, system definition and overview are among principal
needs for cooperation.
B. Framework
Technology offers the possibility of forming elaborated
models for the rail system and its internal or external interfaces.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
Roadmap to a single European Transport Area, E. Commission,
2011.
M. Rajabalinejad, L. van Dongen, and A. Martinetti, "Operation,
Safety and Human: Critical Factors for the Success of Railway
Transportation," presented at the System of Systems, Kongsberg,
Norway, 2016.
EN, "EN 50126 Railway Applications - The Specification and
Demonstration of Reliability, Availability, Maintainability and
Safety (RAMS) - Part 1: Generic RAMS Process," 2015.
M. Rajabalinejad and L. v. Dongen, "Framing Success: the
Netherlands Railways Experience," International Journal of
System of Systems Engineering, vol. Accepted for publication,
2018.
H. Gebauer, M. Johnson, and B. Enquist, "Value co‐creation as a
determinant of success in public transport services," Managing
Service Quality: An International Journal, vol. 20, no. 6, pp. 511530, 2010.
L. A. M. van Dongen, "Through-Life Engineering Services: The
NedTrain Case," L. Redding and R. Rajkumar, Eds.: Springer,
2015, pp. 29-51.
(2018). European Train Control System.
H. Samuel, "French rail company order 2,000 trains too wide for
platforms," in The Telegraph, ed: www.telegraph.co.uk, 2014.
"Fyra maakt rampzalige start: helft niet op tijd en 5,6 procent komt
zelfs nooit aan," in Algemeen Dagblad, ed: www.hln.be, 2013.
(2013). NMBS ontbindt contract met constructeur Fyra.
D. d. Walden, G. J. Roedler, K. J. Forsberg, R. D. Hamelin, and T.
M. Shortell, Systems Engineering Handbook A Guide For System
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
LiFe Cycle Processes And Activities. International Council on
Systems Engineering (INCOSE), 2015.
R. W. Group, Guide for Writing Requirements. International
Council on Systems Engineering (INCOSE), 2017.
E. Rebentisch, Integrating Program Management and Systems
Engineering: Methods, Tools, and Organizational Systems for
Improving Performance. John Wiley & Sons, 2017.
A. Sharon, O. L. de Weck, and D. Dori, "Project Management vs.
Systems Engineering Management: A Practitioners' View on
Integrating the Project and Product Domains," (in English),
Systems Engineering, vol. 14, no. 4, pp. 427-440, Win 2011.
B. Haskins and J. Striegel, "Integration Challenges of Complex
Systems," presented at the INCOSE International Symposium,
2006.
G. Muller, "Coping With System Integration Challenges in Large
Complex Environments " presented at the INCOSE International
Symposium, 2007.
A. J. Kouassi, "Mitigating Rail Transit Project Risks with Systems
Integration," presented at the INCOSE International Symposium,
2008.
J. R. Armstrong, "Systems Integration: He Who Hesitates Is Lost,"
presented at the INCOSE Internaitonal Symposium, 2014.
A. Salado, "Efficient and Effective Systems Integration and
Verification Planning Using a Model-Centric Environment,"
presented at the INCOSE International Simposium, 2013.
R. Oosthuizen and L. Pretorius, "Modelling Methodology for
Engineering of Complex Sociotechnical Systems," 2013.
ISO/IEC/IEE 29148 Systems and software engineering —Life cycle
processes — Requirements Engineering, 2011.
ISO 15745-1 Industrial automation systems and integration —
Open systems application integration framework — Part 1:
Generic reference description, 2003.
R. A. Martin, "International Standards for System Integration,"
presented at the INCOSE International Symposium, 2005.
ISO 55001: Asset management - Management systems
Requirements, 2014.
Quality management systems – Requirements, 2015.
SO/TS 10303-433:2011-10(E) Industrial automation systems and
integration — Product data representation and exchange Part
433: Application module: AP233 systems engineering, 2014.
CMMI, "CMMI-DEV, V1.3 Improving processes for developing
better products and services," Software Engineering Institute2010.
DIRECTIVE (EU) 2016/797 OF THE EUROPEAN PARLIAMENT
AND OF THE COUNCIL of 11 May 2016 on the interoperability
of the rail system within the European Union, T. E. P. A. T. C. O.
T. E. UNION, 2016.
COMMISSION IMPLEMENTING REGULATION (EU) No
402/2013 of 30 April 2013 on the common safety method for risk
evaluation and assessment and repealing Regulation (EC) No
352/2009, T. E. COMMISSION, 2013.
J. Reason, "Beyond the organisational accident: the need for "error
wisdom" on the frontline," Quality and Safety in Health Care, vol.
13, no. suppl_2, pp. ii28-ii33, 2004.
C. Perrow, Normal accidents: Living with high risk technologies.
Princeton University Press, 2011.
E. Duurland, G.-J. Ransijn, and M. Verhoeven, "Towards the
Integration of Safety Assessment and Systems Engineering
Methods for Rail Transport Systems Development," presented at
the INCOSE - 14th Annual International Symposium Proceeding,
2004.
M. V. Stringfellow, B. D. Owens, N. Dulac, and N. G. Leveson,
"A Safety-Driven Systems Engineering Process," 2008.
E. Villhauer and B. Jenkins, "An Integrated Model-Based
Approach to System Safety and Aircraft System Architecture
Development," presented at the INCOSE International
Symposium, 2015.
J. M. Narkevicius, "Safety assessment of system architectures
Philip Wilkinson," 2008.
F. Eubanks, "HAZOP Analysis of Product Requirements for Early
Failure Mode Identification," presented at the INCOSE
International Symposium, 2012.
View publication stats
[37]
M. Rajabalinejad, "Incorporation of Safety into Design Process: A
Systems Engineering Perspective," in ICSSE 2018 : 20th
International Conference on Safety and Systems Engineering,
Paris, France, 2018, vol. VIII, pp. 1366-1368: WASET.