Information Technology Reference
In-Depth Information
During the past 40 years, software was only introduced very slowly in small
incremental steps into safety-critical signaling and train protection systems
and carefully monitored over years of operation, before rolled out in larger
quantities. Software was more or less replacing hard-wired circuits with rel-
atively low complexity based on well service-proven functional requirement
specifications over a period of four decades.
With ETCS however, a relatively large step will be taken: Virtually all
new vehicles have to be equipped with ETCS from 2015 on, enforced by
European legal requirements, despite the fact that no long-term experience
has been made.
The ongoing development of the functional ETCS specification as well as
project-specific adaptations to national or line-specific conditions has resulted
in numerous different versions of ETCS implementations not fully interopera-
ble. Up to now, there is still no single ETCS onboard equipment on the market
that could be used on all lines in Europe, which are said to be equipped with
ETCS. That means that the big goal of unrestricted interoperability would
have been missed, at least until 2010.
The next major release of the System Requirements Specification (SRS
3.0.0), also called “baseline 3”, is expected to elimination those shortcomings.
Baseline 3 has another important feature: Other than all previous SRS
versions, which have been published under the copyright of UNISIG, an asso-
ciation of major European signaling manufacturers, SRS 3.0.0 in the opposite
has been published as an ocial document by the European Railway Agency
(ERA) a governmental organization implemented by the European Commis-
sion. This gives the SRS a status of a “public domain” document. That means,
everyone in Europe is legally entitled to use that information in order to build
ETCS compliant equipment.
2.3
Quality Deficiencies in Software Products
Everyone who has ever used software products knows that almost all software
has errors and no respectable software company claims, that their software
is totally free of defects.
There are various opportunities to make mistakes during the life cycle of
software production and maintenance: Starting with System Analysis, System
Requirement Specification, Functional Requirement Specification, etc., down
to the software code generation, integration, commissioning, operation and
maintenance phases. A “NASA Study on Flight Software Complexity” [12]
shows contribution to bug counts, which can be expected in different steps
of software production (figure 2).
Figure 3 characterizes the actual situation in the European signaling in-
dustry with several equipment manufacturers working in parallel, using the
same specification document in “natural language precision” giving room for
interpretation, combined with different ways and traditions of making mis-
takes, resulting in a low degree of standardization, even for those components,
Search WWH ::




Custom Search