Contract Based Design
The Problem + = How can we avoid this in complex software and systems?
How do we describe what we want? Requirement or Specification: REQ-1: The two traffic lights must not be green at the same time
How do we proof it?? + Unit- / Integration- / Acceptance- / HIL- / MIL- / SIL- / Testing?
Testing helps, but Source: http://www.agitar.com/images/defect_chart.gif
What if? Specification Structure Model Behavior Model Source Code Some Mechanism
Contract Based Design Contracts are formal promises and assumptions between a component and its environment Interface/Port Contracts
Contract Based Design Contract Hierarchies and Groups
What can we do with the Contract? E=mc 2 Formal Verification Generate Testcases Generate Robust Interfaces or Monitoring Generate Documentation
What can we do with the Contract? Systems can be composed of robust building blocks with well contained structure and behavior
Contract Based Design Advantages reduction of possible component and system states accidental complexity overall complexity hidden links and emerging behavior formal verification simpler and more scalable contracts can be checked indepentent on every level of granularity
Example: Eclipse etrice Toolchain Structure Model Behavior Model generate debug Runtime Library+ Source Code compile deploy
ROOM Editors: Actors & Ports hierarchical components called Actors define the structure of a system Graphical Editors (Graphiti) Textual Editors (XText) Ports are the only Interfaces of an actor and define a specific role in its environment. Semantic of Ports can be specified with contracts
Statemachines can be formally checked vs. contracts ROOM Editors: Statemachines hierarchical Statemachines define the dynamical behaviour of Actors
Tool Demo
Contract Based Design Entwicklung einer Plattform für formale Verifikation von Systemen und Software Bau einer Tool- und Methodenunabhängigen Plattform zur Beschreibung von Struktur, Verhalten und Contracts mit dem Ziel der formalen Verifikation Untertstützung einer Vielzahl von Modellierungsmethoden (UML, ROOM, AUTOSAR, ) Kern Partner: Tool Firmen und Forschungspartner Assoziierte Partner aus Avionik, Automotive & Industrie Platform wird Open Source
Contract Based Design Über die Projektpartner Forschungspartner: Fortiss Tools/Technologien: Autofocus Fokus: Formale Verifikation Vincent Aravantinos Universität Augsburg Tools/Technologien: Datenflussanalyse Fokus: Formale Verifikation Prof. Bernhard Bauer
Contract Based Design Über die Projektpartner Industriepartner: ASES Tools/Technologien: Contract Based Design Methodik Fokus: Methodik und Anwendung des Contract Based Design in der Avionik Henning Butz Itemis Tools/Technologien: Franca, mbeddr Fokus: domänenspezifische Tools und Methoden Klaus Birken, Markus Völter Protos Tools/Technologien: Eclipse etrice Fokus: domänenspezifische Tools und Methoden Thomas Schütz
Contract Based Design Über die Projektpartner Assoziierte Partner (Anwender): 1-2 Avionik Firmen Use Cases im Avionik Bereich 1-2 Automotivve Firmen Use Cases im Automotive Bereich Bereits jetzt viel Interesse bei Firmen mit sehr komplexen Problemen
Contract Based Design Aktueller Stand und Nächste Schritte Technischer Fokus definiert: Einheitliche Modelle: Komponentenmodell, Contractmodell, Verhaltensmodell, Ergebnismodell Formale Verifkation, Test-, Dokumentations-, und Monitoringgenerierung für die Contracts Toolanbindungen an Autofocus, Franca, mbeddr, etrice Umsetzung von Pilotprojekten im Bereich Avionik, Automotive und Industrie Derzeit Antragsstellung ZIM KOOP bis Ende März 2016 Gewünschter Projektstart: Juni 2016
Kontakt für das Projekt: Projektansprechpartner Technische Projektkoordination Thomas Schütz thomas.schuetz@protos.de