Demoprojekt UML für kleine Projekte

In großen Software-Projekten auf Plattformen mit Megabytes an Code und Datenspeicher greifen Entwicklungsteams immer häufiger auf Werkzeuge mit einer hohen Abstraktionsebene z.B. auf UML-Basis zurück. Die Vorteile einer strukturierten, modellbasierten Software-Entwicklung lassen sich aber auch auf kleine Targets mit wenigen kByte an Flash- und RAM-Speicher übertragen, die auf den ersten Blick für die Anforderungen der Tools nicht geeignet zu sein scheinen.

Anbieter zum Thema

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

Eurocircuits GmbH

Tieto Deutschland GmbH

Für kleine wie auch große Systeme gilt, dass Codegröße, Performance und Wartbarkeit konkurrierende Parameter in der Software-Entwicklung sind, wobei den Aspekten Wiederverwendung und Wartbarkeit immer mehr Bedeutung zukommt. Die Frage nach der für ein Projekt oder Produkt optimalen Entwicklungsmethodik erfordert eine jeweils individuelle Antwort. Dabei spielen nicht nur technische Faktoren eine Rolle. Insbesondere eine produktivere Softwaretechnik, die in mehr als nur einem Projekt Anwendung finden kann, die Wiederverwendbarkeit von Komponenten innerhalb einer Produktfamilie oder auch das frühe Software-Prototyping z.B. auch in der Interaktion mit dem Kunden können Kompromisse hinsichtlich Codegröße oder Performance durchaus mehr als aufwiegen.

Im Folgenden wird anhand eines Referenzprojekts auf Basis des Mikrocontrollers MSP430 von Texas Instruments und dem Werkzeug IBM Rational Rose Technical Developer (ehemals Rational Rose Real Time, im folgenden RoseRT genannt) gezeigt, dass es durchaus möglich und sinnvoll ist, ein ausgewachsenes RT-UML-(Real-Time-UML-)Tool auf einem sehr speicherlimitierten System zu nutzen, auch wenn diese Konfiguration auf den ersten Blick ungeeignet erscheint.

Zielsystem MSP430 und Real-Time-UML-Tool als Basis

Der MSP430 ist ein sehr populärer 16-Bit-Mikrocontroller, der besonders durch seine einfache aber vielseitig nutzbare Architektur und seine Stromsparfunktionen großen Markterfolg hat. Für die Portierung von RoseRT wurde auf ein Evaluierungssystem der Firma Olimex zurückgegriffen, das mit einem MSP430F1611 bestückt ist. Dieses Derivat bietet, neben einer reichhaltigen Peripherie, 48kByte Flash und 10kByte RAM on Chip. Als Software-Entwicklungsumgebung wurde neben RoseRT die freie GNU-Toolchain gewählt. RoseRT ist eine Real-Time-UML-Entwicklungsumgebung, mit der auf direktem Weg aus UML-Diagrammen, in denen die Struktur und das Verhalten des Systems beschrieben ist, Code für die Zielhardware erzeugt wird.

Der erzeugte Code benötigt auf dem Target eine Laufzeitumgebung, die betriebssystemähnliche Services zur Verfügung stellt. Dieses Target Run Time System (Target-RTS) muss an die jeweilige Zielhardware angepasst werden. Für gängige Zielplattformen wird die entsprechende Anpassung als Teil von RoseRT bereits mitgeliefert. Eine minimale Target-RTS-Konfiguration verlangt lediglich einen Zugang zur Systemzeit und eine einfache Speicherverwaltung um Objekte im Speicher erzeugen zu können. Mit diesen Services ausgestattet ist es möglich UML-Modelle auf dem Target auszuführen, ohne auf ein Betriebssystem aufsetzen zu müssen. Die Erstellung einer einfachen oder auch komfortablen Laufzeitumgebung ist die eigentliche Hauptaufgabe einer Portierung. Danach wird der übliche RoseRT- Workflow angewandt.

Minimale Resourcenbelegung

Auf dem MSP430 belegt die (minimale) Laufzeitumgebung lediglich 8 kByte Flash wodurch noch reichlich Platz für die Applikation übrig bleibt. Dieser Wert ist auch der sehr guten Codedichte des MSP430 zu verdanken. Der Bedarf an RAM-Speicher erfordert eine etwas differenziertere Betrachtung. Die von der Target-RTS benötigte konfigurierbare Message-Queue wurde mit 20 mal 8 Byte (160 Byte) für die geplante Applikation ausreichend groß konfiguriert. Darüber hinaus wird Speicher benötigt um die RoseRT-internen Modellstrukturen abzulegen. Dieser Wert ist sehr stark von den zu implementierenden Funktionen abhängig.

Beispielhaft wurde unter Ausnutzung der internen Peripherie ein Akku-Lader mit folgenden Funktionen implementiert:

• 4 Kanäle,
• Menüführung über LCD Display und Eingabetastern,
• vordefinierte Ladeprofile,
• Delta-U-Abschaltung,
• Lade-, Entlade-, Maintenance- Programme unabhängig für jeden Kanal,
• Temperaturüberwachung mit Lüftersteuerung,
• Überwachung und Anzeige der Slotbelegung.

Die Applikation benötigt ca. 8 KByte RAM (40 KByte Flash) und beinhaltet alle RoseRT internen und applikationsspezifischen Anteile.

Hoher Durchsatz und schnelle Reaktionszeiten

Die RoseRT-Laufzeitumgebung besteht im Wesentlichen aus einem Message Dispatcher, der Meldungen an die UML-Komponenten verteilt. Dieser Dispatcher wurde um eine Schleife erweitert, die ständig überprüft, ob ein Interrupt eingetroffen ist und einen registrierten, dem Interrupt zugeordneten, Handler aufruft.

Neben den je nach Mikrokontroller-Architektur von der Hardware bereitgestellten Interruptebenen, existiert nur eine Verarbeitungsebene (Single Threaded). Innerhalb dieser Verarbeitungsebene werden Events mit unterschiedlicher Priorität zugestellt und so der Ablauf der Software gesteuert. Dadurch ist das System nur für echte Hardware-Interrupts preemptive und damit sehr leichtgewichtig. Durch den Wegfall von Taskwechseln sind sehr gute Laufzeiteigenschaften bezüglich Durchsatz und Reaktionszeit realisierbar.

Alle Vorteile der modellbasierten Entwicklung

Durch die beschriebene Entwicklungsmethode stehen alle Vorteile einer modellbasierten Entwicklung mit RoseRT zur Verfügung:

• Steigerung der Wiederverwendbarkeit,
• Reduzierung der Wartungsaufwände,
• Verkürzung der Entwicklungszyklen,
• Verbesserung der Qualität durch sehr frühe Testbarkeit.

Ein Applikationsentwickler merkt praktisch nichts von der minimalistischen Hardware. Es sind fast alle Modellierungselemente verwendbar, die auch für eine „ausgewachsene“ Plattform zur Verfügung stehen. Das Verhalten der Software kann auf übersichtliche Art in Statemachines abgebildet und schon auf der Entwicklungsplattform ohne Nutzung des Targets getestet werden. Durch die frühe Testbarkeit wird eine deutlich verbesserte Stabilität und Qualität der entwickelten Software erreicht, was die Inbetriebnahme auf dem Target erheblich beschleunigt. Durch Erhöhung der Abstraktion, wird die Effektivität, Wartbarkeit und Wiederverwendbarkeit gesteigert.

Restriktionen und Grenzen

Wegen der eingeschränkten Speicherresourcen auf der Zielplattform wurde für die Codegenerierung der C-Code-Generator ausgewählt. Dieser unterstützt auch objektorientierte Aspekte wie z.B. Vererbung oder Namespaces. Dafür wird ein Klassenpräfix vor Operations- und Attributnamen verwendet. Klassen werden als Strukturen angelegt, wobei für jede Instanzoperation ein Zeiger, auch als „this“-Zeiger bekannt, explizit an die Operation übergeben werden muss. Der damit verbundene etwas erhöhte Schreibaufwand wird durch die Vorteile mehr als kompensiert. Polymorphismus und Zugriffsrechte (protected, private) werden verständlicherweise in einer C-Umgebung nicht unterstützt.

Insgesamt überwiegen die Vorteile deutlich gegenüber den Restriktionen. Die Anschaffung und Einführung des Tools lohnt sich, insbesondere wenn die Software gepflegt, weiterentwickelt und eventuell auf anderen Targets wiederverwendet werden soll, was bei Produktlinien oder Produktvarianten als Regelfall anzusehen ist. Die beschriebene Single-Threaded-Konfiguration eignet sich gut für einfache Steuerungsaufgaben wie z.B. den beschriebenen Akku-Lader oder andere industrielle Steuerungsaufgaben.

Bei komplexeren Herausforderungen ist eine leistungsfähigere Hardware und eine RoseRT-Konfiguration mit Betriebssystem erforderlich, um alle Anforderungen erfüllen zu können. Für diesen Fall können die Software-Entwickler jedoch die bereits erlernte Methodik ebenfalls anwenden und werden keine Zeit durch aufwendige Einarbeitung verlieren.

Ein wesentlicher Vorteil der beschriebenen Vorgehensweise ist die Portierbarkeit der Lösung. Die Single-Threaded-Konfiguration wurde neben dem MSP430 zusätzlich auf folgende Targets übertragen und getestet:

• Olimex Eval Board mit ARM7 LPC2294 (GNU-Toolchain)
• Infineon Evalboard mit XC164 (Keil-Toolchain)
• Lattice Soft Core Mico32
• (GNU–Toolchain)

Die FPGA-Soft-Core-Lösung bietet einen besonderen Charme als sehr kompakte und kostengünstige Lösung, wenn ausschließlich FPGA interne Resourcen verwendet werden können.

Fazit: Die Vorteile einer strukturierten modellbasierten Software Entwicklung lassen sich sehr gut auch auf kleinen Embedded-Systemen realisieren. Der weitaus größte Nutzen hinsichtlich Wiederverwendbarkeit, Wartbarkeit und Produktivität entsteht jedoch durch die Kontinuität beim Einsatz der geschilderten Methodik. Die daraus resultierende Palette an verfügbaren Lösungen und die Erfahrung der Entwickler mit den Werkzeugen und dem Entwicklungsprozess geht einher mit einer signifikanten Steigerung der Entwicklungseffektivität und der Qualität der Ergebnisse.

*Thomas Jung studierte an der Fachhochschule Koblenz und ist Diplom-Ingenieur für der Elektro- und Nachrichtentechnik. Ab 1991 war er bei Siemens für große und kleine Embedded-Software-Projekte im Bereich Telekommunikation verantwortlich. Seit Mitte 2006 ist er bei TietoEnator als Senior Embedded Software Entwickler in verschiedenen Bereichen tätig.

(ID:247357)