Information Technology Reference
In-Depth Information
database will keep growing and continuously being completed to make sure
that all “lessons learned” are on record for future tests.
State of the art formal specification tools do not only provide formatting
support for unambiguous graphical and textual representation of a specifica-
tion document, but provide also a modeling platform to “execute” the model
in a more or less dynamical way. This modeling can be used to verify the cor-
rectness and integrity of the ETCS specification itself not only statically, but
also dynamically. In addition transitions to and from class B systems need to
be specified formally as well and that might depend on national rules, even in
those cases where the same class B system is used (e.g. for PZB-STMs “hot
stand-by” functions are handled differently in Germany and Austria).
Based on a particular reference architecture the resulting formal func-
tional specification can be transformed in a formal software specification and
then converted into executable software code. Even without existing real tar-
get hardware, those elements can be used to simulate the ETCS behavior
and modeling critical operational test cases in a so called “Software-in-the-
Loop” modeling set-up. Once the specification of the functionality has been
approved and validated, the code generation can be done for the EVC em-
bedded control system. Standardization can be accomplished by providing
an Application Programmer Interface (API) similar to the approach success-
fully applied in the automotive industry within the AUTOSAR project [39]
or for industrial process control systems based on open “Programmable Logic
Control” (PLC) within the PLCopen project [40] including safety critical
systems.
In addition to the software specification, generation, verification and vali-
dation tools chain also tools for maintenance (parameter setting, system con-
figuration, software upload services) have to be included in the OSS concept,
as shown in figure 7.
3.6
How FLOSS can meet Safety and Security Requirements
For many railway experts, not familiar with open source development metho-
dology, open source is often associated with some kind of chaotic and arbitrary
access to the software source code by amateur programmers (“hackers”), com-
pletely out of control and therefore not suited for any kind of quality software
production.
This may have been an issue of the past and still being in existence with
some low level projects, adequate for their purpose. However since OSS license
and R&D methodologies concepts have successfully been applied to unnum-
bered serious business projects, even for the highest safety and security levels
for governmental administration, e.g. within the iDABC, European eGovern-
ment Services Project [26] as well as commercial, avionics [29] and military
use [24], a concept based on a group of qualified and so called “Trusted Devel-
opers” (figure 8) having exclusively access to a so called “Trusted Repository”,
which on the other hand can be watched and closely monitored by a large
community of developers, being able to post bug reports and other findings
