ESE Fachwissen
Modellbasierte Entwicklung - ein Erfahrungsbericht
Autor: Tomas Macias, Eberspächer Sütrak GmbH
Beitrag - Embedded Software Engineering Kongress 2016
Kurzfassung
In den letzten Zeiten wurde Modellbasierte Entwicklung im Software Engineering sehr populär geworden aber ist es tatsächlich praktisch für ein reales Projekt mit einer entsprechenden hohen Komplexität? In diesem Bericht wird es dargestellt, wie diese Technologie in eine Multiräume Busklimasteuerung eingesetzt wurde. In dem Vortrag wird man sehen, was die Vor- und Nachteile von diesem Vorgang sind durch die Analysierung von einem konkreten Beispiel. Von Modellierung zu Implementation durch Simulation und Testen, um die Starke von eine modellbasierte Umgebung anzuzeigen. Der Vortrag beleuchtet den Einsatz von UML-typischen Mechanismen wie Klassediagram oder Zustandsmaschinen in Embedded System und wie sie in dem Test & Qualitätssicherung hilft. Am Ende wir werden auch analysieren, wie das Code-Erzeugen ab einem Model die Verwaltung und Wiederbenutzung vereinfacht.
Einführung von Modellbasierte Entwicklung
Modellbasierte oder Modellgetriebene Entwicklung (MBE) ist der Oberbegriff für den automatisierten Prozess von Erzeugung einer lauffähigen Software aus Modellen. Ein Modell ist eine Abbildung eines Realitätsausschnitts, eine Abstraktion von einen Problem, um seine Komplexität besser abzubilden. In den heutigen Tagen gibt es zahllose verschiedene Modellierungssprache. Dennoch ist UML eine von die bekannteste, weltweit verbreitere grafische Modellierungssprache, die in der Software Industrie aufgrund seiner Ausdruckskraft und Vielseitigkeit benutzt ist.
Nachdem das System mit einer bestimmten Genauigkeit mittels eines Modellierungstools beschrieben wird, folgt eine Einsetzung diese Information mit einer Programmierungssprache weiter. Dennoch ist schon bekannt, dass meistens Mikrokontrollers (uC) nur mit C-Programmierungssprache fähig sind und da C ist keine OO-Sprache, kann ein Modell nicht 1:1 einsetzbar werden. Dieses Problem ist heute mit der Hilfe eines Code-Erzeugungstools adressiert, die manchmal auch integriert in einer Modellierungsumgebung ist. In diesem Fall können wir von Modellgetriebener Entwicklung reden, weil beginnend mit einem Modell ein lauffähiger Code generiert wird.
Busklimatisierungsgrundlagen und Aufgabenstellung
Bevor wir in MBE vertiefen, ist eine kurze Erklärung von der Problemdomäne unerlässlich. Mit Busklimatisierung werden Kühlung, Lüftung und Heizung des Raums eines Busses verstanden. Das typische Klimatisierungssystem besteht aus einer Dachklimaanlage, mit Verdampfer und Verflüssiger Einheiten, und einem Kompressor, der am Dieselmotor durch eine Kupplung gekoppelt werden kann. Zusätzliche für das Heizungssystem gibt weitere Wärmetauscher oder Konvektoren, die innerhalb der Dachklimaanlage und auf dem Boden liegen. Je nach Bustyp (Gelenkbusse, Doppeldecker,…) gibt es mehrfache Dachklimaanlage für die verschiede Räume oder Temperaturzonen.
Die analysierte Software muss das gesamte Thermomanagement, Temperaturregelung auf einem Sollwert, eines beliebigen Busses (Solobus, Gelenkbus oder Doppeldecker) betreiben. Eine Anforderung ist, die maximale Gestaltung von dem Bussystem abzudecken, damit danach die Software durch Parameter kundespezifisch eingestellt werden kann. Die Target Plattform war ein 32-bit uC innerhalb einer ECU, die in Zusammenhang mit anderer EA-Erweiterung ECUS ein verteiltes eingebautes System ausgestalten.
Modellierung des Systemstruktur: Problemen und Risiko
Wenn man in C programmiert, fangt immer mit den Funktionen und dem Ablauf an, also man denkt in Aufgaben oder Tasks. Dennoch kann man in einer objektorientiertere Annährung mit dem System Architektur, die Klassen, vorgehen. Das erleichtert den Prozess, weil die Klassen direkt aus den aktiven Komponenten der Busklimatisierung abstrahiert werden können. Unser Modellierungsvorgang bestand aus zwei Phasen:
- Definition der Klassen / Modulen unseres Systems
- Gruppierung der Objekte (Klasseninstanzen) und Herstellung einer hierarchischen Baumstruktur
Die Abbildung 1 (siehe PDF) illustriert die wichtigsten Klassen, die aus Phase 1 resultierten. Wir haben die Klasse Raum als Basiseinheit von unserer Multiraum Regelung konzipiert. Ein Kompressor ist eine separate Klasse, da zwei Räume können den gleichen Kompressor teilen.
In die Phase 2 der Modellierung, wurde berücksichtig, was die maximale Gestaltung unseres Systems ist. Nachdem eine Klasse definiert wird, können wir sie mehrfach aufwandlos benutzen. Unsere Identifizierung der Beziehungen resultierte in einer hierarchischen Struktur, die in ein sogenanntes Objektdiagramm umgefasst wurde (Abbildung 2, siehe PDF).
Eine dynamische Instanziierung war nicht berücksichtigt trotz seiner Realisierbarkeit aufgrund der nachfolgenden Erhöhung der Komplexität bei Debuggen und Fehlersuche. Deswegen entsteht das Risiko während dieser Phase, entweder zu wenige Objekte, die nicht alle Busgestaltungen abdecken können, oder zu viele Objekte, die den Speicher des uC vollfüllen und damit die Erweiterbarkeit der Software gefährden.
Data Struktur und Data Flow: Gute Praxis um die Wiederverwendbarkeit zu halten
In unserem Modell haben wir nach der Datenkapselung Prinzip (Unterschiede zwischen „public“ und „private“ Variablen) unsere Daten organisiert. Jede Klasse hat ein sogenanntes Interface, das aus den „public“ zugriffbaren Variablen (z.B. Anforderung- oder Rückmeldungssignale) besteht. Zusätzliche jede Klasse hat ihre eigenen privaten Variablen. Die Objekte greifen dann nur auf den Variablen des Interfaces zu, damit wenn eine Klasse geändert oder erweitert werden muss, die benötige Änderungen nur bei entsprechender Klasse auftreten. Gleichseitig können Klassen mit einem klaren und sauberen Interface unkompliziert in andere Orte des Modells sogar in andere Softwareprojekte wiederverwendet werden. Zu der guten Praxis gehört auch die Benutzung von Erbe: eine Klasse erbt voneinander alle ihre Variablen und Methoden, das heißt, eine Spezialisierung. Umso kleiner und generischer eine Klasse ist, desto größer ihre Wiederverwendbarkeit.
Als Nachteil können wir signalisieren, dass ein direkter Datenaustausch zwischen Instanzen, die nicht Parent-Child sind, nicht möglich ist, während in C dieses Problem mit globalen Variablen gelöst werden kann. Eine Verhandlung („glue Code“) aus einem übergeordneten Objekt ist notwendig (Abbildung 3, siehe PDF).
Modellierung von Verhalten den Komponenten: Zustandsmaschinen
Das Verhalten der verschiedenen Klassen wurde hauptsächlich mit UML 2.0 Zustandsdiagramme, auch als Zustandsmaschinen bekannten, dargestellt und mit geschriebenem Code komplettiert. Modellierung mit Zustandsmaschine war in unsere Applikation sehr geeignet aufgrund folgender Punkte:
- Einige Komponenten haben ein komplexes Verhalten und wir waren am Anfang nicht sicher, wie sie genau funktionieren sollen. Damit sind Zustandsmaschinen aufgrund seiner Flexibilität und Erweiterbarkeit sehr anwendbar.
- Einige Klassen, wie die Raum Klasse, haben sehr konkrete und schon bekannte Zustände (Abbildung 4, siehe PDF). Das Wissen des Betriebszustands ist vital für die richtige Führung anderer untergeordneten Objekten in alle Momente.
- Modellierung des Verhaltens von reaktiven Objekten – das ist dem Fall von Sensorik oder Sicherheitskomponente wie Druckschalter.
Code-Erzeugen: Simulationsumgebung und Target Integration
Wir haben mit einem speziellen Design-Compiler gearbeitet, der komplexe Generierungsprozesse unterstützt, damit fertiger C-Code aus einem OO-Modell erzeugt, der ohne Nachbearbeitung für das Zielsystem übersetzt werden kann. Der generierte Code wird mit einer PC-API zusammengestellt, um eine PC Simulation abzubilden. Das erleichtert dramatisch unseren Verifizierungsprozess und erlaubt, viele Implementierungsfehler vor uC Integration und ohne manuelle Handhabung der EA der ECU zu finden.
Die Kopplung des generierten Codes mit dem Tool-Chain des Zielsystems erfolgt auch über einen spezifische HAL/API, die den Zugriff auf EA's, Timer, Zähler, Schnittstellen, Display, Touch, etc. abstrahiert.
Am Ende, wir haben eine PC-Kommunikation, die sogenannte Visualisierung, aufgebaut, die alle Variablen, Parameter und sogar aktuelle Betriebszustände jeder Zustandsmaschine übertragen. Trotz des Aufwands lohnt es sich, um ein lauffähiges Debuggen realisieren zu können, die auch als Diagnose Tool für das Feldservice verwendet werden kann. In MDE macht solches Tool mehr Sinn als ein typisches Debuggen-Gerät (z.B. über JTAG), weil der Modellentwickler nicht unbedingt die API oder die Treiber kennt, so muss er letztendlich nur auf den Elementen des Modells konzentrieren. Zusätzlich sind die ECUs nicht immer mit JTAG zugriffbar, insbesondere wenn sie in System eingebaut sind.
Verwaltung und Dokumentation
Die Klassen und seine Elemente, Variablen und Methoden, wurden mit Metadaten, wie Beschreibungen, Einheiten des Variablen oder zusätzliche Info, innerhalb des Modells komplettiert. Diese Information ersetzt den klassischen Kommentaren innerhalb des Codes und wurde für eine automatisierte Dokumentationsherstellung verwendet.Diese Annäherung minimisiert den Aufwand und vereinfacht die zukünftige Verwaltung, da alle Diagramme und Code bleiben zusammen.
Zusammenfassung von Vorteile und Nachteile des Prozess
Ein MBE hat demonstriert, dass den Entwicklungsprozess beschleunigen kann. Wir haben eine Abstraktion dem Klimasystem realisieren können, obwohl alle Anforderungen an Regelungssystem von Anfang nicht bekannt waren. Die Flexibilität von Instanziierung hat uns erlaubt, die Objektstruktur während der Entwicklung anzupassen und extra Klassen aufwandlos hinzufügen. Mit den Zustandsmaschinen haben wir bestimmte Funktionalitäten in Betriebszustände verkapselt. Wir haben auch Testfälle direkt ab Zustandsmaschine abgeleitet. Die Verwaltung der Code wurde nach unserer Meinung vereinfacht, denn die Regelungsfunktionen werden ihren entsprechenden Klassen zugeordnet.
Leider gibt es auch ein paar Nachteile. Der Speicherbedarf für MDE ist großer als bei direkter C-Programmierung. Die Benutzung von globalen Variablen in C vermeidet die Duplizierung von Variablen in den Interfaces der Klassen. Zusätzliche Nachteile sind der Bedarf von einer API aufgrund ihres extra Speicherbedarfs und die einmaligen Kosten und Zeitaufwand, um die API zu der spezifischen Zielplattform anzupassen.
Allerdings meinen wir, dass eine MBE Annäherung sich lohn, seit sie intuitiver und realitätsnäher als klassischer C ist und Leute, die C-Programmierung nicht beherrschen, erlaubt, eine vollständige Embedded Software erfolgreich herzustellen.
Quellenverzeichnis
1. Herbert Stachowiak: Allgemeine Modelltheorie, 1973, S. 131 – 133
2. OMG: UML 2.0 Spezification
3. Andreas Foltinek: UML in der Praxis, 2011
Begriffe
MBE: Modellbasierte Entwicklung
UML: Unified Modelling Language
OOP: Obeject-Oriented Programming
OO: Obejektorientiert
uC: Mictrokontroller
ECU: Electronic Control Unit
Modellierung - MicroConsult Trainings & Coachings
Wollen Sie sich auf den aktuellen Stand der Technik bringen?
Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung.
Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.
Modellierung - Fachwissen
Wertvolles Fachwissen zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung steht hier für Sie zum kostenfreien Download bereit.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.