Information Technology Reference
In-Depth Information
As shown above, due to the complexity of the software, malfunctions
of the system may show up many years, even decades after commissioning.
Conventional procurement processes are therefore not suitable, since they
provide only a few years of warranty coverage for those kinds of defects.
These concepts imply that customers would be able to find all potential
defects within this limited time frame, just by applying reasonable care and
observation of the product by the user, which does not match experiences
with complex software packages with more than 100,000 lines of code.
This finding suggests that complex software will need “care” during the
whole life-cycle. Since software matures during long term quality mainte-
nance, means that during early usage, or after major changes, the software
may need more intensive care whereas in its later period of use, service inten-
sity may slow down. But as long as the software is in use, a stand-by team
is needed to counter unforeseeable malfunctions, triggered by extremely rare
operational conditions. As the ETCS onboard software can be considered
as “mission critical”, operators are well advised to maintain a service level
agreement to get the systems up and running again, even after worst case
scenarios.
Railway operators and vehicle owners are usually not be able to provide
that software support for themselves. They usually rely on services provided
by the OEM. However due to slowing service intensity after several years of
operation, this service model may not match the OEM's cost structure in
particular after the hardware has been phased out. In those cases OEMs are
likely to increase prices or even to discontinue this kind of serve. A typical
escrow agreement for proprietary software might help, but has its price too,
because alternative service providers have first to learn how to deal with the
software. Only a well established FLOSS-eco-system can fill in the gap at
reasonable cost for the end user, and that is only possible with FLOSS.
DB's experience with FLOSS is very positive in general. For more than
a decade, DB is using FLOSS in various ways: In oce applications, for the
intranet and DB's ocial internet presence and services on more than 2000
servers world-wide and even in business critical applications. The original
decision in favor of FLOSS was mainly driven by expected savings on license
cost. However looking back, quality became a more important issue over time,
since FLOSS application have had never caused a “service level breach”, which
cannot be said for proprietary software, selected by applying the same quality
criteria. This supports the impression that FLOSS does tend to have a higher
quality.
4
Conclusion
The major goal of unified European train control, signaling, and train protec-
tion system, ETCS, has led to highly complex functionality for the onboard
units, which converts into a level of complexity for the safety critical software
not seen on rail vehicles before. A lack of standardization on various levels,
