Information Technology Reference
In-Depth Information
Never the less, continuous further development and consistent use of qual-
ity assurance measures can result in a remarkable process of “maturation” of
software products, which is demonstrated by the fact that in our example in
figure 4 the bug density has been reduced by more than an order of magni-
tude (initially above 6 bugs/TLOC down to below 0.5 bugs/TLOC). On the
other hand, in a later stage of the life cycle, due to the continuous growth of
the number of code lines, which seem to go faster than the reduction of the
bug density, a slight increase of the total number of bugs, can be observed.
Given a certain methodology and set of quality assurance measures on the
one hand and a number of change requests to be implemented per release,
then this will result in a certain number of bugs that remains in the software.
Many of those bugs stay unrecognized forever. However some are also known
errors, but their elimination is either not possible for some reason or can
only be repaired at an unreasonably high level of cost. The revelation of the
unknown bugs can take several thousand unit operation years (number of
units times number of years of operation) and must be considered as a random
process. That means for the operator, that even after many years of flawless
operation, unpleasant surprises have to be expected at any time. In Europe, in
a not too distant future up to 50,000 trains will operate with ETCS, carrying
millions of passengers daily, plus unnumbered trains with hazardous material.
Then the idea is rather scary that in any of those “European Vital Computers”
(EVC), the core element of the ETCS vehicle equipment, between 100 and
1000 undetected errors are most likely left over, even after successfully passing
safety case assessments and after required authorization has been granted.
Even if we would assume, that only one out of 100 bugs might eventually
cause a hazard [12], that still means 1 to 10 mission critical defects per unit.
Further more, there will be several different manufacturer-specific variants of
fault patterns under way.
2.5
New Technologies Have to Have “At Least Same Level of
Safety”
According to German law (and equally most other EU states) defined in
the EBO (Eisenbahn Bau- und Betriebsordnung: German railway building
and operation regulations) any new technology has to maintain at least the
same safety level as provided by the preceding technology [16]. Assuming that
the more complex ETCS technology requires about ten times more software
code than legacy technology like LZB and PZB as an average and given the
fact, that PZB and LZB have already reached a very mature stage of the
software integrated after almost 3 decades of continues development, then it
seams very unlikely, that the “at least same level of safety” can be proven by
using the same technical rules and design practices for a relatively immature
ETCS technology. In addition, due to less service experience the criticality
of deviations from expected reaction patterns are dicult to assess.
This raises the question whether proprietary software combined with a
business model that sells the software together with the hardware device,
