Information Technology Reference
In-Depth Information
2
Software in ETCS Vehicle Equipment
As discussed above, state of the art technology requires for almost all safety
critical as well as non-safety related functions to be implemented in software.
The end-user will normally receive this software not as a separate package,
but integrated in his embedded control device. Therefore software is usually
only provided in a format directly executable by the built-in microproces-
sor, a patter of ones and zeros, but therefore not well suited for humans to
understand the algorithm. The original source code, a comprehensible docu-
mentation format of this software, which is used to generate the executable
code by a compiler and all needed software maintenance tools are usually
not made available to the users. Manufacturers are doing this, because they
believe that they can protect their high R&D investment this way.
2.1
Impact of “Closed Source” Software
However concealment of the software source code documentation has increas-
ingly been considered as problematic, not only for economical reasons for the
users, but more and more for safety and security reasons as well.
Economically it is unsatisfactory for the operators to remain completely
dependent from the original equipment manufacturer (OEM), no matter
whether software defects have to be fixed or functions to be adapted due
to changing operational requirements. For all services linked to these em-
bedded control systems there is no competitive market, since bundling of
non-standard electronic hardware together with “closed source” or “propri-
etary” software makes it practically and legally impossible for third parties
to provide such service. This keeps prices at high levels.
While malfunctions and vulnerability of software products, allowing mal-
ware (“malicious software”: as there are viruses, trojans, worms etc.) to harm
the system, can be considered as quality deficiencies, which can practically not
be discovered in proprietary software by users or independent third parties,
whereas the question of the “vendor lock-in” due to contractual restrictions
and limiting license agreements is generally foreseeable, but due to gener-
ally accepted practices in this particular market, hardly to be influenced by
individual customers (e.g. railway operators).
Especially security vulnerability of software must be considered as a spe-
cific characteristic of “proprietary” or “closed source” software. So-called “End
User License Agreements” (EULA) do usually not allow end-users to analyze
copy or redistribute the software freely and legally. Even analysis and im-
provement of the software for the user's own purposes is almost generally
prohibited in most EULAs. While on the one hand customers who are play-
ing by the rules are barred from analyzing and finding potential security
gaps or hazardous software parts and there-fore not being able to contribute
to software improvements, even not for obvious defects, however the same
legal restrictions on the other hand do not prevent “bad guys” from disas-
sembling (a method of reverse-engineering) and analyzing the code by using
