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

More documents

Recommendations

Info

Chapter 8. openETCS Domain Framework Similar to the CDataFlow execution by CEVCState, the ::std::thread is used to start the method in a separated thread. Its implementation is quite simple and can be found in Listing D.5 in Appendix D. It only executes a while-loop as long the internal Boolean attribute m_bStarted is true. This can only turn into false if the CEVCStateMachine instance is explicitly stopped by the Stop() method or if an exception is thrown in the executed current EVC Mode m_pCurrentState or rather in its data flows. If the execution of the current EVC Mode in Line 6 is stopped due to a Mode transition or Application Level switch, the while-loop simple starts in its next run the new active CEVCState object or with the new m_CurrentApplicationLevel or even with a new combination of both. To stop the execution, only the attribute m_bStarted has to be set to false, which informs the current thread about the stop request and waits for the state thread to terminate by the ::std::thread:join() method in Listing D.6. 8.6.5. DMI Implementation The CDMIQWidget implementation is quite simple and mainly treats the update of the displayed widgets for inputs and outputs. Any attached observer is notified by its CEVCStateMachine object via the Update() method that the contents or visibility state of one or more CDMIInput or CDMIOutput object of the current subject CDMISubject has changed or that even the complete subject was changed. The latter is the case if the ETCS mode and/or application level was changed. A changed subject always means that the input and output widgets (m_InputWidgets and m_OutputWidgets) have to be rearranged. Since this includes the deletion of all existing input and output widgets and the creation of the new ones, this process should be avoided in cases, where only the value of CDMIOutput objects of the current CDMISubject were modified by the data flow calculation. Otherwise, this would delete any input of the driver that was already entered but not yet activated via the corresponding QPushButton. Accordingly, the CDMIQWidget observer always stores the pointer to the last used CDMISubject in the m_pLastSubject aggregation (see Figure 8.5). Only, if in the execution of Update() the last subject is not identical to the current subject, the input and output widgets are rearranged. Otherwise, only the (displayed) values of the m_OutputWidgets are updated from m_Outputs in the DMI subject. Another but more minor aspect of the DMI implementation, is the fact that Qt 4 does not accept changes of GUI elements from other threads than the one running the Qt event loop [59]. The event loop is started from the main() function because the corresponding openETCS C++ generator (see Chapter 9) only generates the instantiation of domain framework types and the starting of the CEVCStateMachine object. The CDMIQWidget Update() method is called from the current data flow thread (see Subsection 8.6.2), which is not the main thread. Therefore, the Update() method cannot change GUI elements of CDMIQWidget directly. The solution is again to make use of Qt 4’s signal and slot mechanism: The real update implementation is moved to the Qt slot UpdatedSlot(), which is connected [59] with the signal Updated(). The method Update() then only emits the signal Updated() to call the slot with the update implementation but then in the thread of the Qt event loop. 154
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
Page 1:
Open Source Software for Train Cont
Page 4 and 5:
Datum des Promotionskolloquiums: 21
Page 7 and 8:
Acknowledgments I would like to tha
Page 9:
Abstract This document describes th
Page 12 and 13:
Contents 3.3.3. Rascal . . . . . .
Page 14 and 15:
Contents 8.4. Behavioural Design .
Page 16 and 17:
Contents D.3. Domain Framework Mode
Page 18 and 19:
List of Figures 6.4. Simple CORBA u
Page 20 and 21:
List of Figures 10.27. General read
Page 22 and 23:
Chapter 1. Introduction Railway Con
Page 24 and 25:
Chapter 1. Introduction MontiCore M
Page 26 and 27:
Chapter 1. Introduction ERTMS Forma
Page 29:
Part I. Background 9
Page 32 and 33:
Chapter 2. Concepts for Safe Railwa
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Chapter 3. Domain-Specific Modellin
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 59 and 60:
4The GOPPRR Meta Meta Model - An Ex
Page 61 and 62:
4.1. Concrete Syntax Description Fo
Page 63 and 64:
4.2. GOPPRR C++ Abstract Syntax Mod
Page 65 and 66:
4.2. GOPPRR C++ Abstract Syntax Mod
Page 67 and 68:
4.5. The Object Constraint Language
Page 69 and 70:
4.5. The Object Constraint Language
Page 71 and 72:
4.6. Tool Chain where artefacts are
Page 73 and 74:
4.7. Conclusion External Artefacts
Page 75:
Part II. Dependability 55
Page 78 and 79:
Chapter 5. Verification and Validat
Page 80 and 81:
Page 82 and 83:
Page 85 and 86:
6Security in Open Source Software A
Page 87 and 88:
6.1. Memory Management Open Meta Me
Page 89 and 90:
6.2. Hardware Virtualisation a fixe
Page 91 and 92:
6.2. Hardware Virtualisation in a v
Page 93 and 94:
6.2. Hardware Virtualisation Again,
Page 95 and 96:
6.2. Hardware Virtualisation the fa
Page 97:
Part III. openETCS Case Study 77
Page 100 and 101:
Chapter 7. openETCS Meta Model far
Page 102 and 103:
Chapter 7. openETCS Meta Model gEVC
Page 104 and 105:
Chapter 7. openETCS Meta Model gEVC
Page 106 and 107:
Chapter 7. openETCS Meta Model gMai
Page 108 and 109:
Chapter 7. openETCS Meta Model Outp
Page 110 and 111:
Chapter 7. openETCS Meta Model thei
Page 112 and 113:
Chapter 7. openETCS Meta Model gSub
Page 114 and 115:
Chapter 7. openETCS Meta Model The
Page 116 and 117:
Chapter 7. openETCS Meta Model can
Page 118 and 119:
Chapter 7. openETCS Meta Model The
Page 120 and 121:
Chapter 7. openETCS Meta Model List
Page 122 and 123:
Chapter 7. openETCS Meta Model 5 s
Page 124 and 125: Chapter 7. openETCS Meta Model 7.5.
Page 126 and 127: Chapter 7. openETCS Meta Model 12 )
Page 130 and 131: Chapter 7. openETCS Meta Model Thus
Page 132 and 133: Chapter 7. openETCS Meta Model In t
Page 134 and 135: Chapter 7. openETCS Meta Model Valu
Page 136 and 137: Chapter 7. openETCS Meta Model This
Page 138 and 139: Chapter 7. openETCS Meta Model and
Page 142 and 143: Chapter 8. openETCS Domain Framewor
Page 180 and 181: Chapter 9. openETCS Generator Appli
Page 200 and 201: Chapter 10. openETCS Model No Power
Page 202 and 203: Chapter 10. openETCS Model c4 bool
Page 204 and 205: Chapter 10. openETCS Model c1 c8 c1
Page 206 and 207: Chapter 10. openETCS Model Applicat
Page 208 and 209: Chapter 10. openETCS Model c1 c25 c
Page 210 and 211: Chapter 10. openETCS Model Initiali
Page 212 and 213: Chapter 10. openETCS Model Reverse
Page 214 and 215: Chapter 10. openETCS Model 0 (CONST
Page 216 and 217: Chapter 10. openETCS Model Current
Page 218 and 219: Chapter 10. openETCS Model c7 bool
Page 220 and 221: Chapter 10. openETCS Model Current
Page 222 and 223: Chapter 10. openETCS Model The purp
Page 224 and 225:
Chapter 10. openETCS Model 10.3.3.
Page 226 and 227:
Chapter 10. openETCS Model be expla
Page 228 and 229:
Chapter 10. openETCS Model 10.4.4.
Page 231 and 232:
11 openETCS Simulation Generally, a
Page 233 and 234:
11.2. Platform Specific Model for t
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
11.3. Simulation Model Figure 11.6.
Page 241 and 242:
11.3. Simulation Model 11.3.2. CDMI
Page 243 and 244:
11.3. Simulation Model sets the Boo
Page 245 and 246:
11.3. Simulation Model Entering_Dri
Page 247 and 248:
11.3. Simulation Model The states o
Page 249 and 250:
11.3. Simulation Model Figure 11.13
Page 251 and 252:
Page 253 and 254:
Page 255:
11.6. Conclusion about warnings, fa
Page 258 and 259:
Chapter 12. Conclusion and Outlook
Page 261:
Part IV. Appendix 241
Page 264 and 265:
Appendix A. GOPPRR to MOF Transform
Page 266 and 267:
Appendix B. openETCS Meta Model Con
Page 268 and 269:
Page 270 and 271:
Page 273 and 274:
DopenETCS Domain Framework D.1. Dom
Page 275 and 276:
D.2. Domain Framework Source Code 8
Page 277:
D.3. Domain Framework Model 32 m_pT
Page 280 and 281:
Appendix E. openETCS Generator 39 <
Page 282 and 283:
Appendix E. openETCS Generator 200
Page 284 and 285:
Appendix E. openETCS Generator 46 4
Page 287 and 288:
FMetaEdit+ Generators F.1. GOPPRR X
Page 289:
GopenETCS Unit Testing G.1. Unit Te
Page 292 and 293:
Appendix H. openETCS Simulation 14
Page 294 and 295:
Page 296 and 297:
Page 299 and 300:
Glossary ANTLR ANother Tool for Lan
Page 301 and 302:
Glossary EVC An European Vital Comp
Page 303 and 304:
Glossary OEM An original equipment
Page 305:
Glossary XML The Extensible Markup
Page 308 and 309:
Bibliography [12] “EN 50128 - Rai
Page 310 and 311:
Bibliography [39] ——, ““Ope
Page 312 and 313:
Bibliography [69] T. J. Parr and R.
Page 315 and 316:
Index Artefact, 51 Automatic train
Page 317 and 318:
Index Linux, 149 Memory management,
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?