Komplexität beim embedded Software Design

Komplexität beim embedded Software Design

‚Best Practises‘ für statische Analysetools

Embedded-Entwickler stehen unter größerem täglichen Druck als Programmierer in anderen Industrien. Während die meisten Entwicklungsteams von weniger Komplexität durch Cloud-basierter, homogener Hardware und Virtualisierung profitieren, sieht es bei embedded Entwicklern ganz anders aus: Sie müssen Anwendungen programmieren, die durchgängige und vorhersagbare Leistung über eine steigende Anzahl an heterogenen Hardware-/Prozessor-Konfigurationen bringen, die immer neue Features beinhalten, und stehen dabei vor vielen Herausforderungen.

Beispiel einer Befehls-Injektions-Schwachstelle im Code (Bild: GrammaTech Inc.)

Beispiel einer Befehls-Injektions-Schwachstelle im Code (Bild: GrammaTech Inc.)


Außer Haus produzierter Code birgt besondere Risiken aufgrund verschachtelter Supply Chains, wiederholter Unzugänglichkeit zum Source Code der Library, und der Angst vor Insidern, die heimlich Schwachstellen einschleusen. Embedded Software Entwickler müssen potenzielle Parallelitätsprobleme (Concurrency) kennen, die zu unvorhersehbarem Verhalten führen oder unbeabsichtigte Angriffsflächen bieten können. Die zunehmende Netzwerkfähigkeit von embedded Systemen bedeutet eine große Herausforderung. Sei es Code für Netzwerkrouter, medizinische Geräte oder Home-Security Systeme – jedes Gerät mit Netzwerkanschluss bietet eine Angriffsfläche für raffinierte Cyber Attacken. Leistungskritische Software in Avionik, Automobilen und Konsumgeräten unterliegt einer steigenden Anzahl an Standards für Codequalität und Sicherheit, wie DO-178B/C, MISRA und ISO. Nach Einschätzungen der Industrie wachsen die Code-Basen von embedded Anwendungen um beinahe 30% pro Jahr. Embedded Entwicklungsteams nutzen eine Mischung aus Wasserfall- und agilen Methodiken. Unabhängig von der Coding Philosophie steigt für jedes Teammitglied der Zeitdruck nach schnelleren Zyklen für neue Features, zur Reaktion auf Kundenwünsche, und um bekannte Fehler zu korrigieren. Dennoch kann der Wunsch nach Schnelligkeit nicht auf Kosten der Code-Entwicklung gehen.
 Vereinfachte Version des Codes mit dem Infinite Loop Bug (Bild: GrammaTech Inc.)

Vereinfachte Version des Codes mit dem Infinite Loop Bug (Bild: GrammaTech Inc.)

Risiken durch embedded Sprachen

C und C++, die gängigsten Sprachen für embedded Software, beinhalten besondere Risiken für die Entwickler, denn Mängel und Unklarheiten in der Sprach-Spezifizierung können unerwünschtes und unerwartetes Verhalten in der Ausführung erzielen. Aber eine embedded Anwendung muss in unterschiedlichen Hardware/Firmware-Umgebungen laufen, so dass ein Test auf unerwartetes Verhalten schwierig sein kann. Wegen all dieser Faktoren haben embedded Entwicklungsteams formalisierte Codier- und Testpraktiken übernommen. Zusätzlich zum standardmäßigen QA-Test können automatisierte Tools den Quellcode und die Ausführung einer Anwendung schon früh in der Entwicklung prüfen, wenn Fehler einfacher zu korrigieren sind, und anspruchsvolle Berichte erstellen, um die Einhaltung von Standards so effizient wie möglich zu gestalten.

 Beispiel eines Type Mismatch (Bild: GrammaTech Inc.)

Beispiel eines Type Mismatch (Bild: GrammaTech Inc.)

Der Wert einer frühen, automatisierten Fehlererkennung

Unabhängig davon, welchen Code embedded Entwicklungsteams schreiben, ist die Fehleridentifizierung zu einem frühen Zeitpunkt wertvoll für die Ausführung und Leistung des Codes. Von allen Tools und Strategien zur Verbesserung des Entwicklungsprozesses von embedded Software bietet die automatisierte Quell-/Binary-Analyse mit die höchsten ROI-Werte. Sie ist unbestritten effizienter als ein manueller Ablauf. Ihr größter Wert ist allerdings, was sie zu welchem Zeitpunkt findet. Das belegt eine Studie des NIST (National Institute of Standard Technology) von 2002: Demnach braucht die Beseitigung eines einzelnen Fehlers in der Entwicklung rund 5 Stunden, während die Entfernung eines Fehlers in einer Produktionsumgebung durchschnittlich 15 Stunden verschlingt. Der nachgewiesene Wert einer frühen Fehlererkennung im Software-Entwickungszyklus und die Belastungen für die embedded Programmierteams untermauern die automatisierte Codeanalyse als eine der kosteneffizientesten Investitionen für Unternehmen, um Zyklen schneller freizugeben und die Produktivität der Entwickler zu steigern. Denn: Wird die automatisierte Codeanalyse mit dem ALM Prozess integriert, formalisiert sie die Identifizierung von schwer auffindbaren Fehlern und/oder Schwachstellen und fügt diese dem Bug-Tracking-System hinzu, wo sie priorisiert und eliminiert werden können. Die Erfahrung von GrammaTech bei der Entwicklung von embedded Software stammt zum Großteil von CodeSonar, dem Flaggschiff-Produkt zur statischen Codeanalyse. Es hat mehr als 500 Mio. Codezeilen verarbeitet, um die Leistung von Fehler-intoleranten Geräten wie den NASA Mars Curiosity Rover zu schützen, oder des U.S. Justizministeriums, um nennenswerte Ausfälle von Automotive Systemen zu überprüfen. Durch die Zusammenarbeit mit weltweit führenden Geräte-Herstellern und U.S. Regierungsagenturen, die hochsicherheitsfähigen Code mit Null-Fehler-Toleranz entwickeln und testen, konnte sich das Entwicklungsteam von GrammaTech ein tiefes Verständnis der für moderne embedded Software maßgeblichen Qualitätsanforderungen aneignen. GrammaTech empfiehlt gewisse ‚Schlüssel-Anforderungen‘ für automatisierte Code-Analysetools, einschließlich der nachfolgendgenannten. Jede davon enthält ein Beispiel mit echtem Code, der in CodeSonar analysiert wurde:

 Unstimmige Methoden der Ansprache einer Klasse an ein Feld (Bild: GrammaTech Inc.)

Unstimmige Methoden der Ansprache einer Klasse an ein Feld (Bild: GrammaTech Inc.)

Seiten: 1 2 3Auf einer Seite lesen

GrammaTech Inc.

Das könnte Sie auch Interessieren