Die Ergänzung für Embedded Linux

Neues RTOS mit Standard-POSIX-Threads-API

30. Mai 2023, 6:00 Uhr | Von Bill Lamie und Rafael Taubinger
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Die TDD-Testumgebung

Ausschnitt aus dem TDD-Regressionstest für das PX5 RTOS in Embedded Workbench von IAR
Bild 1. Ausschnitt aus dem TDD-Regressionstest für das PX5 RTOS in Embedded Workbench von IAR
© IAR Systems

Der erste Schritt bei TDD – dem Test-First-Paradigma – ist die Erstellung einer Testumgebung. Es gibt einige Open-Source-Testumgebungen, aber für diese Zwecke hat sich PX5 entschieden, eine eigene einfache Testumgebung zu erstellen, die sequenziell einzelne Testfälle aufruft und optional den Status jedes Tests sowie eine Zusammenfassung per printf anzeigt.

Die Testumgebung des TDD-Regressionstests für das PX5 RTOS (Bild 1) enthält einfach eine Reihe von Aufrufen von px5_test_dispatch, die je- weils einen bestimmten TDD-Test auslösen.

passend zum Thema

Die Dispatch-Funktion für die Tests
Bild 2. Die Dispatch-Funktion für die Tests
© IAR Systems

Jeder Test innerhalb der Umgebung hat das gleiche Format, genauer gesagt:

int test_entry(void);
 
Der zurückgegebene Wert ist ein be- standener oder fehlgeschlagener Status, der von der Testumgebung analysiert und dem Entwickler angezeigt wird. Die Dispatch-Funktion für die Tests ist sehr einfach (Bild 2).

Der erste Test clock_getres API test untersucht die POSIX-API clock_getres, wie sie vom PX5 RTOS implementiert wird. Die Testeingabefunktion für diesen Test ist die C-Funktion:

int px5_test_clock_getres(void);

Ausschnitt aus einem clock_getres TDD-Test
Bild 3. Ausschnitt aus einem clock_getres TDD-Test
© IAR Systems

Diese Funktion enthält alle Tests für die Implementierung der POSIX-API clock_getres innerhalb des PX5 RTOS. Unter Verwendung des »Test-First«-TDD-Ansatzes wurde dieser TDD-Test vor der Implementierung der POSIX-API clock_getres geschrieben und konnte daher nicht sauber kompiliert werden (Bild 3).

Erst nachdem der TDD-Test für clock_getres abgeschlossen war, wurde mit der eigentlichen Implementierung von clock_getres begonnen. Der Implementierungsprozess besteht im Grunde aus drei Teilen:

  • Eine saubere Kompilierung/Verlinkung.
  • Sicherstellen, dass der TDD-Testfall und die Implementierung wie erwartet funktionieren und einen erfolgreichen Status ergeben.
  • Analysieren, wie viel des Implementierungscodes durch den TDD-Test ausgeführt wurde. Dieser Prozess nutzt die Codeabdeckungsfunktion im IAR-Debugger. Gibt es Pfade, die nicht ausgeübt wurden, werden neue Tests hinzugefügt, bis eine 100-prozentige Abdeckung des Implementierungscodes erreicht ist.
Codeabdeckung für die Implementierung der clock_getres-API
Bild 4. Codeabdeckung für die Implementierung der clock_getres-API.
© IAR Systems

Die Codeabdeckungsinformationen für clock_getres sind in einem erweiterten Format dargestellt (Bild 4). Die vollständig grünen Rauten zeigen an, dass alle Pfade der Funktion ausgeführt wurden. Eine nicht (vollständig) grüne Raute bedeutet, dass ein oder mehrere Codepfade nicht ausgeführt wurden. Wenn zum Beispiel eine Funktion aufgerufen wird, aber nicht zurückkehrt, ist die obere Hälfte der Raute grün und die untere Hälfte rot. Ähnlich verhält es sich bei if/when-Bedingungen:

Wurde ein Element einer Bedingung nicht ausgeführt, ist die Raute rot.
Apropos Bedingungen und Codeabdeckungsanalyse: Es ist gut, zusammengesetzte Bedingungen im Implementierungscode zu vermeiden. Auf diese Weise ist es einfacher, bestimmte Bedingungen, die getestet werden, von denen, die nicht getestet werden, zu trennen. Außerdem wird die Codeabdeckungsanalyse dadurch weniger belastet. Ohne zusammengesetzte Bedingungen ist die Anweisungsabdeckung nun funktional äquivalent zur robusteren Abdeckung von Verzweigungsentscheidungen.

In jedem Fall zeigt dieses Beispiel deutlich, dass 100 % der Implementierung von clock_getres durch den entsprechenden TDD-Test überprüft wurde. Dieser Prozess wiederholt sich für jede einzelne funktionale Implementierung der Software.

Nach Abschluss des Regressionstests zeigt die Testumgebung eine Zusammenfassung der durchgeführten Tests und der Gesamtergebnisse an. Für das in den Bildern gezeigte Beispiel lässt sich zusammenfassend sagen, dass es insgesamt 194 TDD-Tests gibt. Alle von ihnen haben die Ausführung bestanden und weisen eine 100-prozentige Codeabdeckung für Anweisungen und Verzweigungsentscheidungen auf.

Neben den TDD-Tests verwendet PX5 RTOS die statische Analyse C-STAT von IAR als weiteres Tool zur Verbesserung und Überprüfung der Qualität des Implementierungscodes. Das Tool checkt den Code auf mögliche Fehler und unterstützt auch die Überprüfung der MISRA-Konformität. Die MISRA-C-Standards wurden entwickelt, um die Sicherheit und Zuverlässigkeit von in C geschriebener Firmware zu verbessern. MISRA ist in der Avionik, im Automobilbau, in der Industrie und in anderen sicherheitsrelevanten Bereichen von Embedded-Systemen weit verbreitet. C-STAT von IAR bietet Analysen sowohl für den MISRA-C:2004- als auch für den MISRA-C:2012-Standard.

RTOS, Tools und ein bewährter Entwicklungsprozess

Bewährte Tools helfen, die Entwicklung von sicherheitskritischen Anwendungen auf Basis des neuen Echtzeitbetriebssystems PX5 RTOS zu optimieren. Dennoch benötigen Entwickler für die Erstellung von Code mit hoher Qualität einen bewährten Prozess, der sich in drei Schritten zusammenfassen lässt:

  • Document First: Das Schreiben des Anwenderhandbuchs noch vor der Implementierung trägt wesentlich zur Verbesserung des Produkts oder der Komponente bei. Ist es zu kompliziert, um es zu beschreiben, ist es generell zu kompliziert. Der Vorteil: Es ist viel einfacher, die Schnittstelle oder den Entwurf zu ändern, bevor der Code steht, als danach.
  • Test First: Das Testen hat oberste Priorität. Es sollte keine Implementierung erstellt werden, bevor die Codetests durchgeführt wurden. Mit der Codeabdeckung lässt sich sicherstellen, dass alle Pfade der Implementierung gründlich getestet werden. Tools für die statische Analyse finden zuverlässig problematische Codestellen.
  • Bewährte Tools verwenden: Der frühzeitige Einsatz einer Toolsuite mit einem bewährten und einfach zu nutzenden Debugger und Analysewerkzeug ist unerlässlich, um den Entwicklungsprozess zu beschleunigen. Insbesondere integrierte Toolsuites wie IAR Embedded Workbench und C-STAT können einen nahtlosen Entwicklungsablauf gewährleisten.

Die Einhaltung dieses Entwicklungsprozesses für Anwendungen, die auf dem fortschrittlichen Echtzeitbetriebssystem RX5 RTOS basieren – das von Natur aus nach Einfachheit strebt – ermöglicht es Entwicklern, die Qualität ihres Codes und der gesamten Anwendung zu verbessern und gleichzeitig die Entwicklungszeit zu verkürzen.

 

Die Autoren

 

Bill Lamie von IAR Systems
Bill Lamie von IAR Systems.
© IAR Systems

Bill Lamie

ist President und CEO von PX5. Er verfügt über mehr als drei Jahrzehnte Erfahrung in der Embedded-Industrie, insbesondere als Gründer und CEO von Express Logic, wo er das erfolgreiche ThreadX RTOS und mehrere Middleware-Produkte wie NetX und FileX entwickelte. Lamie hat einen B.S. in Computerwissenschaften von der San Diego State University

Rafael Taubinger von IAR Systems
Rafael Taubinger von IAR Systems
© IAR Systems

Rafael Taubinger

ist Sr. Product Marketing Manager bei IAR. Vor seiner jetzigen Tätigkeit war er als Global FAE Manager und Senior FAE bei IAR tätig. Er verfügt über mehr als 20 Jahre Erfahrung in der Embedded-Industrie und hat einen B.S.-Abschluss in Elektrotechnik mit Schwerpunkt Elektronik sowie einen Master of Business Administration (M.B.A.) in Business Management.


  1. Neues RTOS mit Standard-POSIX-Threads-API
  2. Die TDD-Testumgebung

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu IAR Systems GmbH

Weitere Artikel zu Echtzeit-/Embedded Software

Weitere Artikel zu Entwicklungswerkzeuge