Embedded Software als integriertes Paket

Anbieter zum Thema

Eine Applikation für eingebettete Systeme verlangt oft nach Abweichungen, Optimierungen oder Erweiterungen von dem Programmierungsstandard. Diese werden in der Regel von jedem Compilerhersteller zur Verfügung gestellt, deren Einsatz sollte aber möglichst vermieden oder minimiert werden, um die damit verbundenen Abhängigkeiten zu reduzieren. Manchmal ist der Einsatz solcher Erweiterungen nicht komplett mit anderen Entwicklungsstandards wie MISRA zu vereinbaren und sollten deswegen immer dokumentiert werden, insbesondere, wenn eine Zertifizierung des Gerätes erforderlich ist.

Die Dokumentation der Software ist auch ein wichtiger Aspekt, welcher leider oft vernachlässigt wird, insbesondere in den Anfangsstadien eines Projektes. Programme wie “doxygen” generieren aus der in der Software eingebetteten Kommentare die Dokumentation automatisch. Dies kann eine große Hilfe sein, um die Dokumentation immer konsistent mit der Software zu halten und den Aufwand der Generierung der Dokumentation zu reduzieren.

Programmierungstechniken nach dem “Agile” Prinzip stehen heutzutage an der Basis der modernen Entwicklung einer Applikation.

In einem traditionelleren Verfahren würden unterschiedliche Phasen nacheinander stattfinden: anfangend mit der Definition einer Spezifikation, dann das Definieren vom Software Konzept, folgend die Implementierung der Funktionalität, das Testen der Anwendung und schließlich am Ende des Prozesses das Einführen einer Instandhaltungsphase. In einem solchen Konzept ist jede Phase mehr oder weniger abgeschlossen, bevor die nächste anfangen kann.

Im Gegenteil sehen die Prinzipien eines agilen Verfahrens vor, dass funktionsfähige Software Module binnen Tagen oder Wochen, nicht Monaten, bereitgestellt werden. Um dies zu ermöglichen, sind eine enge Kooperation zwischen der Anforderungsphase und der Implementierungsphase und eine schnelle Anpassung an stets wechselnde Vorgaben erforderlich. Dazu verwenden die Entwickler tägliche kurze Sitzungen, um den Fortschritt des Projektes zusammenzufassen und eventuelle Probleme in der Implementierung aufzubringen. (Bild 1 in der Bildergalerie)

Ein agiler Prozess sieht vor, erst einmal funktionelle Module zu identifizieren. Dann werden diese in kürzere “Handlungsstränge” aufgebrochen und nach deren Komplexität ausgewertet. Diese werden wiederum in noch kürzere Aufgaben zerlegt und jede Aufgabe dann einem Entwickler zugewiesen. Die vorgesehene Zeit um diese Aufgabe (“Sprint”) zu bewältigen ist in der Regel eher kurz, zum Beispiel zwei Wochen. Am Ende dieser Zeit ist ein Entwicklungszyklus abgeschlossen, der Entwickler liefert sein spezifischen Software Modul, und der Prozess wiederholt sich.

Dank dieser kurzen Iterationen wird es sowohl möglich, die Zeit für die Fertigstellung des Projektes abzuschätzen, als auch während der Entwicklungsphase die Geschwindigkeit des Projekt Fortschritts zu messen. Das ist sehr wichtig um Verzögerungen rechtzeitig zu erkennen und die damit verbundenen Probleme so frühzeitig wie möglich zu beheben.

In solchen Fälle kann ein Projekt-Management Tool wie „Jira“ von Atlassian Software eine solide Infrastruktur bereitstellen, um die Entwicklung nach dem “Agilen” Verfahren zu ermöglichen.

Verifikation mit simulierter Hardware

Ein oft auftretendes Problem ist auch, das dem Entwickler am Anfang eines Projektes noch keine geeignete Hardware-Plattform zur Verfügung steht, die Software-Entwicklung trotzdem frühestmöglich starten soll.

In solchen Fälle kommen andere Tools wie “CMock“ dem Entwickler zur Hilfe. Damit ist es möglich, Module auf funktionale Ebene zu simulieren und zu testen. Ein sogenannten „Mock Objekt“ kann das Verhalten einer Hardwareinteraktion mittels einer auf Software basierenden Variante darstellen und dabei diese Funktion bereitstellen.

Sobald die echte Hardware-Plattform verfügbar ist, kann der Entwickler mühelos diese Simulierte Version mit der echten austauschen. Selbstverständlich muss diese validiert werden, aber auf funktionaler Ebene konnte das Modul dank dem CMock-Objekt bereits getestet werden. Somit darf sich die Verifizierung des Verhaltens der Software auf eine reine Hardware Problematik fokussieren.

(ID:44296110)