Peter Braun, Jan Philipps, Bernhard Schätz et al.
Safety cases become increasingly important for software certification. Models play a crucial role in building and combining information for the safety case. This position paper sketches an ideal model-based safety case with defect hypotheses and failure characterisations. From this, open research issues are derived.
Tihamer Levendovszky, Bernhard Rumpe, Bernhard Schätz et al.
As complex software and systems development projects need models as an important planning, structuring and development technique, models now face issues resolved for software earlier: models need to be versioned, differences captured, syntactic and semantic correctness checked as early as possible, documented, presented in easily accessible forms, etc. Quality management needs to be established for models as well as their relationship to other models, to code and to requirement documents precisely clarified and tracked. Business and product requirements, product technologies as well as development tools evolve. This also means we need evolutionary technologies both for models within a language and if the language evolves also for an upgrade of the models. This chapter discusses the state of the art in model management and evolution and sketches what is still necessary for models to become as usable and used as software.
Klaus Becker, Bernhard Schatz, Christian Buckl et al.
In domains like automotive, safety-critical features are increasingly realized by software. Some features might even require fail-operational behavior, so that they must be provided even in the presence of random hardware failures. A new fault-tolerant SW/HW architecture for electric vehicles provides inherent safety capabilities that enable fail-operational features. In this paper we introduce a formal model of this architecture and an approach to calculate valid deployments of mixed-critical software-components to the execution nodes, while ensuring fail-operational behavior of certain components. Calculated redeployments cover the cases in which faulty execution nodes have to be isolated. This allows to formally analyze which set of features can be provided under decreasing available execution resources.
Jan Olaf Blech, Harald Rueß, Bernhard Schätz
This report presents our work on behavioral types for OSGi component systems. It extends previously published work and presents features and details that have not yet been published. In particular, we cover a discussion on behavioral types in general, and Eclipse based implementation work on behavioral types . The implementation work covers: editors, means for comparing types at development and runtime, a tool connection to resolve incompatibilities, and an AspectJ based infrastructure to ensure behavioral type correctness at runtime of a system. Furthermore, the implementation comprises various auxiliary operations. We present some evaluation work based on examples.