Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

9.8. openETCS Tool Chain for Dependable Open Model Software
9.8. openETCS Tool Chain for Dependable Open Model
Software
The resulting concrete openETCS tool chain for the complete development process is sketched
in Figure 9.11. The verification of the transformation from the GOPRR to the GOPPRR
instance is done, corresponding to the description in Section 9.7, by the generated “Functional
Test Cases”, which are run on the “GOPPRR Abstract Syntax Tree”. The verification of the
transformation of the concrete GOPPRR C++ abstract syntax model to the concrete source
code for the EVC binary is implemented in the “Functional Testing”, which consumes the
generated “Source Code” and “GOPPRR Abstract Syntax Tree” artefact. The validation of
the generation process refers here to a valid model, which is checked by the constraints of the
static semantics. Also, the final build process of the EVC binary and its execution under a
Xen hypervisor were added.
Since the extensions or transformations for the PSM cannot be generally foreseen and neither
is automatically generated from other artefacts, it is omitted in Figure 9.11.
9.9. Conclusion
The openETCS generator application fulfils all initially defined requirements by combining
several C++ classes producing the different generator output.
To ensure that Req.9 is fulfilled, tests can be generated automatically for both models: First,
in a general way, independent from the meta model, for the transformation from the GOPRR
meta model instance in MetaEdit+ to the GOPPRR C++ abstract syntax model. Second, for
the concrete model-to-text transformation to openETCS domain framework objects.
The usage of cmake provides implicitly a platform independent build configuration for
compiling and linking the EVC executable binary, which facilitated the implementation of the
CBuildGenerator and fulfils Req.11.
CVMGenerator provides an implementation for generating configurations for the Xen hypervisor
for para-virtualisations, which fulfils Req.12.
The separation of independent data flows for parallelisation could be future development
work for the openETCS generator application because it is already prepared in the domain
framework.
Although the checking of the static semantics was only realised by the direct implementation
of exemplary constraints in C++, all OCL constraint statements in Section 7.5 could be used
in combination with the UML-based Specification Environment (USE) [34] application, which
is available as FLOSS, to check the static semantics outside the openETCS tool chain in
Figure 9.11. Accordingly, the openETCS tool chain and USE would have to be adapted to allow
the export and import of the concrete GOPPRR C++ abstract syntax model instantiation.
Hence, an appropriate XMI export must be realised inside the GOPPRR package / name space
and the corresponding XMI import mechanism in USE, which neither is currently available.
177