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

More documents

Recommendations

Info

Chapter 1. Introduction MontiCore MontiCore [50, 51] is a framework that is specialised for the development of text-based domain-specific languages [35]. A typical task during the development of these is the definition of the concrete and abstract syntax. In textual languages, the concrete syntax is also called grammar. While the definition of the grammar is mostly related to the development of the available textual constructs and elements, the abstract syntax is needed for parsing concrete text instances that conform to the grammar. Therefore, both syntax types must be held synchronised or rather must be modified together. Normally, the concrete syntax / grammar is in the main focus during the development of the textual language. Thus, modifications in the grammar render necessary adaptations of the abstract syntax. To avoid this often recurring task, MontiCore provides an own grammar format for the ANTLR [69] parser generator, from which an abstract syntax (tree) can be generated automatically. Accordingly, the manual update and development of the abstract syntax can be omitted. Although MontiCore seems to be an excellent starting point for the development of textual languages, the case study in Part III developed in this work uses a graphical modelling formalism, which is motivated in Chapter 3. Open Proofs The development of safety-critical software as re-usable open source is one of the basic ideas that supports this dissertation. A similar concept called Open Proofs [65] also addresses this idea because the term “open proofs” refers to the public proofs of correctness of a certain software. Open Proofs requires • the entire implementation, • automatically-verifiable proof(s) of at least one key property, and • required tools (for use and modification) to be free/libre open source software (FLOSS) [95]. Open Proofs demands that in such a publicly developed tool-chain faults can be found more easily and eliminated due to a big community using them. Nevertheless, currently there exist only few examples of software that implement the Open Proofs principle. In contrast to the contributions of this dissertation, Open Proofs is only a concept that can be applied to the software development for safety-critical systems. openETCS The openETCS [38, 37] initiative of German Railways (Deutsche Bahn) is based on the Open Proofs idea [40, 39]. Reviewing evidence, where security threats have been purposefully integrated into closed-source commercial software products, the initiators argued that open source software could be useful – perhaps even mandatory in the future – to ensure safety and security of railway control systems. Even though the standards applicable for safety-critical systems software development in the railway domain [11, 10] require independentthird-party verification and validation, the complexity of the source code on the one hand and the limited budget available for V&V on the other hand can only mitigate the threat of safety and security vulnerabilities. A guarantee to uncover all compromising code fragments inadvertently or purposefully injected into the code cannot be given. As a consequence, in 4
1.3. Related Work addition to the V&V efforts required by the standards the broad peer-review enabled by publicly available software could really increase software dependability 2 . As of today, the openETCS approach has stirred considerable interest, in particular among the research communities, which are now invited to act – at least in the V&V branch of the system development process – as equal partners to commercial railway manufacturers. This resulted in a European ITEA2 [43] project initiative, which is currently in progress, but, due to the short project life time, no remarkable results are available. In contrast to this work, especially to the developed case study, the openETCS project heavily focusses on the tool development to fully realise the Open Proofs concept. The case study was primarily developed to demonstrate that the main contributions of this dissertation can be seen as proof of concept for the applicability of open source software in safety-critical systems in the railway domain. A realisation of a tool chain that completely corresponds to the Open Proofs concept was not a main goal. AUTOSAR The idea of an open architecture is of course not limited to the railway domain. The Automotive Open System Architecture (AUTOSAR) [5] is an industrial approach that facilitates the interchange of software for control modules used in automotive systems. AUTO- SAR does not only include a specification for the software architecture but also for the used development tools. It defines the following goals [5]: • implementation and standardization of basic system functions as an OEM wide “Standard Core” solution • scalability to different vehicle and platform variants • transferability of functions throughout network • integration of functional modules from multiple suppliers • consideration of availability and safety requirements • redundancy activation • maintainability throughout the whole “Product Life Cycle” • increase use of “Commercial off the shelf hardware” • software updates and upgrades over vehicle lifetime In contrast to the main goal of this dissertation project, AUTOSAR only defines an open architecture, but does not require the developed software or development tools to be open source or even to use a free/libre open source development strategy [95]. TOPCASED The Toolkit in Open Source for Critical Applications & Systems Development (TOPCASED) [81] is a different approach for a standardised development. It is an extension of the Eclipse [20] Integrated Development Environment (IDE), which provides methods and tools for the development of safety-critical software or rather systems for the avionics domain. In contrast to AUTOSAR, TOPCASED does not define a certain system and/or software architecture but the development process by formalisms and tools. Although TOPCASED is, like the Eclipse, IDE published under a FLOSS software license, the developed software is typically not. 2 Following [53], dependability, in particular, safety, and security are emergent properties that can only be attributed to complete systems and not to software alone. 5
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 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 42 and 43: Chapter 3. Domain-Specific Modellin
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 128 and 129:
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 140 and 141:
Page 142 and 143:
Chapter 8. openETCS Domain Framewor
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Page 180 and 181:
Chapter 9. openETCS Generator Appli
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
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?