In der Praxis sind oft Vorgehensmodelle und Entwicklungsmethoden anzutreffen, die aus alten Zeiten der 8- und 16-Bit Programmierung stammen und trotz ungleich komplexeren Systemen beibehalten werden. Um den geänderten Anforderungen gerecht zu werden, sind zunehmend Methoden und Werkzeuge aus dem Bereich des Entwurfs von komplexen IT-Anwendungen anzutreffen, wie z.B. objektorientierte Ansätze und die Modellierung mit UML, teilweise mit integrierter Code-Generierung (CASE Tools). Weiterhin werden immer häufiger komplexe Bibliotheken (Treiber, ProtokollStacks wie TCP/IP oder USB und Graphical-User-Interfaces GUI) verwendet.

Zusätzlich werden in Embedded-Systemen hohe Anforderungen an die Echtzeitfähigkeit gestellt, Interrupt-Services und hardwarenahe Treiber sind unabdingbar. Diese sind meist prozedural in C geschrieben und müssen dann mit der objektorientierten Welt und den vorhandenen Programmteilen „verheiratet“ werden.

Geeignete Softwarearchitekturen und objektorientierte Methoden helfen, die Produktivität in Embedded-Softwareprojekten zu steigern. Weiterhin ist die UML für Systementwurf und Systemdesign geeignet. Sie kann für Analyse, Entwurf und Modellierung verwendet werden. Dabei stellt sie diverse Diagramme und Elemente zur Verfügung, um ein Softwaresystem aus verschiedenen Sichten zu beschreiben. Für statische Modellierung Anwendungsfalldiagramm, Klassendiagramm, Objektdiagramm, Komponentendiagramm oder Einsatzdiagramm; für dynamische Modellierung Zustandsdiagramm, Sequenzdiagramm, Kollaborationsdiagramm oder Aktivitätsdiagramm. Die UML bildet sich auf objektorientierte Konstrukte ab. Diese müssen in C darstellbar sein, damit die Anwendung in Embedded- Systemen erfolgreich ist. Da dies je nach vorhandenen Ressourcen nur teilweise möglich ist, ist die UML nicht immer vollständig nutzbar.

Zu den wichtigsten objektorientierten Konstrukten zählen Klassen, Instanzierung von Objekten, Timer, Mailboxen, Events, Messages und Ports. Einige dieser Konstrukte werden durch ein Echtzeit-Betriebssystem (RTOS) zur Verfügung gestellt (Timer, Mailboxen, Events, Messages und ein Scheduler mit Taskverwaltung), andere werden mit C nachgebildet.

Werden bestimmte objektorientierte UML-Konstrukte im Modell nicht verwendet, ist UML fast beliebig anwendbar und im Extremfall sogar ohne RTOS auch in der Sprache C umsetzbar. Prinzipiell können jedoch nicht alle objektorientierten Bestandteile sinnvoll und Ressourcen sparend in C implementiert werden. Daher wird gern auf Vererbung, Überladung und dynamische Instanzierung von Objekten zur Laufzeit verzichtet.

Stattdessen arbeiten kleine Embedded-Systeme mit statischen Objekten, die zur Entwurfszeit angelget werden. Damit braucht das System keine dynamische Speicherreservierung, die in den meisten Embedded-Targets ohne Speicherverwaltungseinheit (MMU) zur gefürchteten Fragmentierung führen kann. Weiterhin können statt Messages so genannte „Guards“ (Bedingungen, „Wächter“) zur Steuerung von UML-Zustandsmaschinen (Statecharts) genutzt werden. Messages und Mailboxen entfallen dann (synchrones Modell). Allerdings kann dardurch der Nutzen dieser Entwurfmethoden infrage gestellt sein [5].

Andere Bestandteile des Embedded-Systems sind mit der UML nicht ausreichend oder nicht beschreibbar, wie zum Beispiel hardwarenahe und echzeitfähige Reaktionen und Dienste (Interrupt-Service- Routinen, Prioritäten, Ansteuerung von Pheripherie wie DMA, usw). Damit die Vorteile der Modelierung in UML gewinnbringend genutzt werden können, ist der Einsatz eines RTOS empfehlenswert. Als Basis des UML-Modells muss auf die Anforderungen eines RTOS im kleinen Embedded-System beim Entwurf eingegangen werden. Die reine Modellierung in UML verführt oft zur intensiveren Nutzung von Ressourcen, ohne sich dessen bewusst zu sein.

Beispielhaft ist hier die harte Echtzeit untersucht: Objekte können in UML „aktiv“ sein, sie haben zur Laufzeit einen eigenen Task/Thread. Dies ist über ein RTOS effizient darstellbar. Die maximale (Echtzeit-) Auflösung hängt stark von der Task-(Kontext-) Umschaltung des verwendeten Betriebssystems ab:

Würde ein CAN- Bus mit 1 MBit/s alle 111 µs einen Empfangsinterrupt generieren und ein Taskwechsel per Message initiieren, wäre nur für die Umschaltung des RTOS-Schedulers beim schnellen ARM7 schon fast 11% der Rechenleistung verbraucht.

In vielen Beispielen wird daher auf prozeduraler Treiberebene die schnelle Datenverarbeitung mit Protokoll-Stack oder die unmittelbare Prozessreaktion ausgeführt, bevor ein Task in der Applikation über die Aktion benachrichtigt wird. Wenn zum Beispiel über einen UART eine Befehlssequenz empfangen wird, werden zunächst alle Daten der Sequenz in der Treiberebene erfasst und vorverarbeitet (Protokoll-Stack), bevor die Applikation mit der vollständigen Nachricht oder einem extrahierten Kommando beschäftig wird. Damit wird nicht bei jedem Datenempfang Rechenzeit für die Taskumschaltung benötigt.

Weiterer Vorteil: Die Applikation muss das Protokoll auf der unteren Schicht und die Datenquelle nicht kennen, Erweiterungen und Tests sind leichter möglich. Diese Betrachtung kann mit allen Mechanismen des RTOS gleichermaßen fortgesetzt werden (Message Passing, Time-outs, Event Handling).

Es ist nahe liegend, dass der Laufzeitanteil des RTOS keinen erheblichen Teil der verfügbaren Systemressourcen verwenden soll. Anhand der Task-Umschaltzeiten lässt sich ableiten, dass diese Mechanismen nur für wesentlich geringere Laufzeitanforderungen verwendet werden sollten. Die Zeiten für einen Task-Wechsel liegen bei 8-Bit-Mikrocontrollern deutlich im Millisekunden- und beim 32-Bit Mikrocontroller im 100-µs-Bereich, zusätzlich abhängig von der Anzahl der Nebenläufigkeiten. Alle härteren Anforderungen sollten weiterhin hardwarenah entworfen und implementiert werden – und auch auf andere Dienste des RTOS weit gehend verzichten.

Neben den zeitlichen Aspekten muss der Speicherverbrauch durch das Echtzeit-Betriebssystem und UML-CASE-Tools betrachtet werden. In [5] wird durch Erfahrung (Randbedingungen: Rhapsody in C, Codegenerierung, UML-Framework mit kleinem Betriebssystem) eine Grenze bei Systemen mit < 32 KByte ROM Applikation hergeleitet, unter der ein Einsatz von UML nicht sinnvoll erscheint. Hier ist der Anteil an hardwarenaher prozeduraler Software sehr hoch, der Gewinn durch objektorientierte Ansätze mit RTOS und UML aufgrund mangelnder Komplexität der Applikation zu gering.