ASCET Implementation Mentor
Unterstützung bei der modellbasierten Entwicklung mit ASCET

ASCET ist eine Software zur modellbasierten Entwicklung von Steuerungskomponenten in der Automobilindustrie. ASCET ist ein Produkt der Firma ETAS und erlaubt es, Komponenten für Steuergeräte zu entwerfen und daraus automatisch Code zu erzeugen.

Der Ascet Implementation Mentor (AIM) ist ein Plugin für ASCET, welches die in ASCET erstellten Modelle automatisiert testet und vervollständigt.

Mit AIM ist es möglich, in ASCET erstellte Modelle mithilfe von Regeln zu überprüfen. So können Implementierungsfehler in Modellen automatisch gefunden werden und die Einhaltung von Konventionen garantiert werden (z.B. Namenskonventionen für Komponenten). Außerdem erlaubt AIM in einigen Fällen die automatische Korrektur von gefundenen Fehlern, sowie die Ergänzung von fehlenden Informationen in Modellen. Ist dies nicht möglich, unterstützt AIM den Entwickler durch Hinweise über den gefunden Fehler. Es nennt die genaue Fehlermeldung, das betroffene Element im Modell, sowie den Ort im Modell an dem sich dieses Element befindet. Diese Hinweise helfen dem Entwickler den Fehler schnell ausfindig zu machen und zu korrigieren.

Da jeder Benutzer von AIM eigene Anforderungen an seine ASCET Modelle hat, ist es unmöglich eine Menge von Regeln zu entwickeln die alle Benutzer zufrieden stellt. AIM ermöglicht daher die Integration eigener Regeln über wohldefinierte Schnittstellen, so dass die Prüfung von AIM an die eigenen Bedürfnisse angepasst werden kann. Regeln werden zur Laufzeit dynamisch von AIM geladen, damit Entwickler jederzeit neue Regeln ergänzen oder alte aktualisieren können, ohne AIM neu starten zu müssen. Darüber hinaus können Entwickler in AIM Regeln jederzeit aktivieren oder deaktivieren, um genau konfigurieren zu können auf was sie ihre Modelle prüfen möchten.

Um eine automatische Korrektur von Fehlern durchführen zu können, muss AIM Änderungen an den ASCET Modellen des Entwicklers vornehmen. Solche automatischen Änderungen können schnell zu Frust beim Entwickler und Problemen in der Produktion des Codes führen, wenn Änderungen durchgeführt werden die der Entwickler nicht erwartet hat. Dies verhindert AIM, indem jede Änderung die durchgeführt werden soll, vor der Übernahme zu ASCET, in einer Tabelle präsentiert wird. In dieser Tabelle führt AIM den genauen Ort der Änderung, sowie den alten und den neuen Wert auf. Stimmt der Entwickler den Änderungen nicht zu, werden diese verworfen.

Durch diese Funktionen hilft AIM bei der Aufspürung von Fehlern in Modellen, die dem Entwickler in ASCET selbst nicht ohne Weiteres auffallen würden. Weiterhin unterstützt AIM bei der Einhaltung von Konventionen und verhindert somit das Entstehen von Chaos in den Modellen einer Organisation. Dank der Erweiterbarkeit von AIM durch eigene Regeln muss sich aber keine Organisation von AIM in ein Korsett zwängen lassen, sondern kann AIM an seine eigenen Bedürfnisse anpassen.

Ein Blockdiagramm einer Komponente in ASCET.

Das Hauptfenster von AIM. Von hier aus erreicht man alle Funktionen von AIM und kann den Prozess laufender Aktionen im Ladebalken am unteren Fensterrand beobachten.

Die Anzeige von gefundenen Fehlern in einem Modell. Funde werden zuerst nach ihrer Regel, dann nach dem Element in dem sie auftreten sortiert. Ist AIM in der Lage einen fehler zu beheben oder Informationen zu ergänzen, zeigt es einen entsprechenden Button am Fund an.

Findet AIM fehlende Informationen in der Implementierung eines Elements und der Entwickler will diese von AIM ergänzen lassen, so präsentiert AIM ihm eine Liste der möglichen Implementierungen. Der Entwickler kann sich eine davon auswählen und AIM fügt die passenden Informationen dann in die Implementierung des Elements ein.

Hat der Entwickler seine gewünschten Änderungen abgeschlossen und möchte diese zu ASCET exportieren, präsentiert AIM ihm noch einmal alle Änderungen im Detail. Nur wenn der Entwickler hier zustimmt, findet die Übernahme der Änderungen in ASCET statt.

Der Entwickler kann für jede Überprüfung genau festlegen welche Regeln angewandt werden sollen. Werden zur Laufzeit neue Regeln zu AIM hinzugefügt, werden diese dynamisch geladen und erscheinen auch in diesem Menü. Das funktioniert ohne einen Neustart von AIM

von links nach rechts: Patrick Müller, Daniel Gonzalez, Matthäus Kiehn, Dennis Albrecht, Tobias Hamann

Die Bosch Engineering GmbH (BEG) ist eine Tochtergesellschaft der Robert Bosch GmbH, die Entwicklungen für Fahrzeug- und Motorenhersteller anbietet und auf die individuelle Anpassung von Bosch-Großserientechnik spezialisiert ist. Hauptsitz des Unternehmens ist in Abstatt. Das Unternehmen bietet Systemanpassungen in folgenden Bereichen an:

Entwicklung von Systemen, Funktionen, Software sowie Applikation für den Antriebsstrang, Sicherheit und Komfort (Fahrdynamik, Fahrerassistenz, Insassenschutz) und elektrische/elektronische Integration
Entwicklungsunterstützung durch Testdienstleistungen und Beratung, Projekt- und Qualitätsmanagement
Komplettsysteme für den Motorsport

Neben Anwendungen für die Automobilindustrie werden kundenspezifische Systemanpassungen in verwandten Bereichen wie Nutzfahrzeuge, Bau- und Landmaschinen, Powersport, Motorsport, Schiffbau, Industrieanwendungen, Eisenbahn, Blockheizkraftwerke und Luftfahrt entwickelt.

Code Reviews sind ein wirksames Werkzeug zur Sicherstellung von qualitativ hochwertigem Code, sowie zur Vermeidung von Programmierfehlern noch bevor der Code produktiv genutzt wird.
Unit Tests und Integrationstests mit Testdaten sind zwar nützliche Werkzeuge zum Sicherstellen der korrekten Funktion von Code, sie ersetzen jedoch keine Tests mit realen Daten. Es sollten daher so früh wie möglich Szenarien Tests in der Laufzeit Umgebung des Auftraggebers durchgeführt werden.
Die Organisation des Code Repositories nach dem Git Flow Prinzip, dabei insbesondere der Einsatz von Feature Branches, ermöglicht es die parallele Entwicklung von Features ohne ständige Konflikte zu meistern.