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

8.6. Implementation
8.6.6. Error Handling
Since faults [78, pp. 12-14] not only can occur in concrete hardware components, which means
in the PSM, but neither can be avoided completely in the implementation of the PIM, error
handling is also an issue for the openETCS domain framework. An error is the incarnation
of a fault as a deviation from the normal operation of the framework [78, pp. 12-14]. For
fault detection or rather error propagation, exceptions [79] are used. This means if in a
method of the domain framework a fault is detected that cannot be handled by the method
itself, a corresponding exception is thrown. Mostly, exceptions may occur in data and control
flows, which must be handled by the parent CEVCStateMachine object. The ETCS SRS
already defines EVC Modes and procedures [88] in the case of an error that lead to a system
failure [78, pp. 12-14]. Thus, the error handling is part of the concrete openETCS model
while only the propagation is part of the openETCS domain framework. Furthermore, from
the view of the domain framework, a system failure 11 may never occur because all errors
respectively all thrown exceptions in the execution of CEVCState objects are handled by the
parent CEVCStateMachine instance. Of course, from the view of the EVC, those errors lead to
system failures because in the resulting failure Modes the EVC cannot perform its required
function.
The most relevant origin of possible faults is the PSM or rather the HWSpecificImplementations
sources because obviously not any possible specific implementation can be foreseen. On
the one hand, faults may occur in the hardware itself. Those faults can be propagated to any
connected proxy by a D-Bus signal while the resulting error can be then thrown by the related
function block object. This kind of error propagation presumes a correct implementation of
the HWSpecificImplementations source code. As already discussed in detail in Chapter 6, this
presumption is not valid for the PSM and any supplier implementations in general, which was
the reason for the separation of PIM and PSM in different execution environments. A grave
issue for the execution of the openETCS domain framework data flow is the execution time
of calls to platform specific adaptors since a constant sample time may not be exceeded (see
Subsection 8.6.2). To avoid a dead-lock situation in the data flow thread caused by infinite
response times of platform-specific implementations, all D-Bus calls are done with a certain
time-out value. If this value is overrun, the waiting for the call is aborted and an exception is
thrown.
There is a minor set of errors that cannot be handled by CEVCStateMachine class. Those
may occur in methods that are called by an external actor, which mainly means the EVC.
Nevertheless, those are limited to methods of CEVCStateMachine for starting and stopping
the execution, and methods used during the instantiation of the domain framework classes by
the generated code from the openETCS model. The latter ones must be avoided by a correct
generator implementation and the checking of the static semantics.
In the domain framework, each method is declared with the exception types it can raise [79]
to provide a transparent chain for error propagation. This is also done for methods that cannot
throw any exception type at all. Additionally, for certain fault and error categories, different
C++ types as classes are defined. Those are shown in Figure 8.23 as UML class diagram.
CException is the parent class for all concrete exceptions types in the domain framework.
11 in the meaning of a unexpected and unwanted process termination
155