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

8.5. Deployment Design
Hence, those classes can only have a stub implementation in the PIM because those hardware
components are always specific. The D-Bus component / daemon provides those interfaces to
the libopenETCSPIM component while it requires them from the libopenETCSPSM component.
In that way, messages from and to the specific classes in the PIM can be dispatched to the
PSM without any direct connection in an object-oriented manner.
Of course, it is possible, as proposed in Section 6.2, to place each hardware interface
implementation in an own execution environment or rather virtual machine and to connect each
to the D-Bus component in the EVC. Nevertheless, the domain framework / PIM only defines
the interfaces to the PSM but does not define how (and where) the concrete implementations
are provided because such details are not relevant for the domain framework deployment design
in general.
Finally, it must be emphasised that for an executable EVC state machine not only the source
artefacts from the openETCS domain framework are required but also the generated code from
the openETCS model, which instantiates the classes of the domain framework. However, that
generated code is mutable because it depends on the openETCS model and therefore is not a
direct part of the domain framework deployment design.
D-Bus Integration Since the preceding paragraphs in this section mainly discussed the general
integration of the D-Bus as middleware, the following paragraphs will explain the details
about the D-Bus usage. The defined interfaces IEmergencyBrake, IOdomoter, IServiceBrake,
IBaliseDeviceIn, and IBaliseDeviceOut are not directly types or rather abstract classes [79] and
therefore cannot be simply integrated into the class structure by inheritance. Therefore, the
corresponding openETCS domain framework classes must make use of the interface in a different
manner, which is shown in Figure 8.16. The function block classes that are all located in the
PlatformSpecificClientsMOC artefact have all a composition m_pProxy to the corresponding
interface 9 type. Since the general D-Bus implementation provides only a GLib [31] API,
which is not object oriented, its direct usage in the openETCS domain framework would
cause a break with the so far pure object-oriented design and implementation. Thus, as for
the concrete observer implementation CDMIQWidget, Qt 4 is employed because its D-Bus
module [59] provides an object-oriented API. Accordingly, the platform specific classes are not
only CFunctionBlock types but additionally inherit from QObject to be able to use Qt 4’s
signal and slot mechanism [59]. The function block types use a m_Mutex composition to ensure
thread-safe manipulations of their attributes.
On the one hand, D-Bus itself defines interfaces that can be used as proxies for the communication
and, on the other hand, adaptors that must be (re-)implemented with the “real”
implementation [31]. Interface and adaptor are generated from an XML file that defines the
messages and signals of an adaptor (and its interface), which is sketched in Figure 8.17. The
contents of the XML interface definition can be found in Appendix D. It must be noted that
the generated interface classes are no interfaces in the meaning of abstract classes [79], which
are types that cannot instantiated directly. Instead, they can be interpreted as proxy objects
that can be used in place of the corresponding adaptors. The artefacts are generated in the
case of the Qt 4 D-Bus API by the “qdbusxmll2cpp” application [59].
9 prefixed by an “I”
145