Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>
Lesezeit: 6 MinutenDa Cybersicherheit zu einem starken FDA-Schwerpunkt mit spezifischen Anforderungen an die statische und dynamische Code-Analyse wird, müssen Ingenieure diese Praktiken automatisieren und in vorhandene Entwicklungsworkflows integrieren. In diesem Gastblog teilt Andrey Shastin von Auriga einige Tricks aus dem Handel.
Bei Auriga liefern wir seit fast zwei Jahrzehnten viele Softwareentwicklungsprojekte für medizinische Geräte – von relativ einfachen Blutzuckermessgeräten bis hin zu komplexeren Systemen wie Infusionspumpen, Patientenmonitoren und Lungenbeatmungsgeräten. Die Implementierung statischer und dynamischer Codeanalysepraktiken und deren Einsatz in diesen Projekten ist ein wesentlicher Bestandteil unseres Prozesses, und hier werde ich darauf eingehen Statische vs. dynamische Codeanalyse und teilen Sie einige Tipps aus unseren praktischen Erfahrungen und Herausforderungen.
Bei der statischen Analyse wird automatisch die Einhaltung bekannter Codierungsrichtlinien (z. B. MISRA, CERT, AUTOSAR, JSF) überprüft und potenzielle Fehler wie Nullzeiger-Dereferenzierung, Division durch Null und Pufferüberläufe erkannt. Moderne statische Analysewerkzeuge ergänzen auch die traditionelle Praxis der Codeüberprüfung, indem sie den manuellen Aufwand um mindestens 30% reduzieren.
In den meisten Fällen zeigt der erste Durchlauf eines statischen Analysetools für Ihren aktuellen Code Tausende von Fehlern (beim ersten Durchlauf sind sogar mehr als 20,000 aufgetreten), was natürlich unglaublich überwältigend sein kann, wie es scheint Jahre, um sie alle zu reparieren. Hier sind einige Tipps unserer Experten, um das Problem zu lösen.
Disziplinierte Entwicklungsteams kompilieren normalerweise mit –Wall und –Werror (in GCC) oder / Wall / WX (in Visual Studio) oder verwenden ähnliche Optionen in anderen Compilern. Das Beheben von Compiler-Warnungen ist eine einfache und kostengünstige Möglichkeit, sich auf die Ausführung statischer Analysen vorzubereiten. Wir haben festgestellt, dass das Überprüfen der Ausgabe Ihres Compilers in einem "paranoiden" Modus das Gesamtvolumen der Verstöße gegen die statische Analyse verringern kann.
Obwohl es eine gute Sache ist, alle Compiler-Warnungen zu korrigieren, gibt es viele Projekte, bei denen die Verwendung eines Compilers aus Compliance-Gründen nicht ausreicht und sogar eine akzeptable Option darstellt.
Verwenden Sie nach dem Trocknen Ihres Compilers statische Analysewerkzeuge, die viel tiefer in den Code eintauchen und Ihnen viel mehr Hinweise geben sollen.
Wenn Sie derzeit Software für medizinische Geräte entwickeln, sollten Sie darauf vorbereitet sein, die Frage einer automatisierten statischen Code-Analyse zu beantworten. Die statische Analyse ist fast garantiert Gegenstand einer Diskussion während eines internen / externen Audits oder sogar einer Einreichung vor dem Inverkehrbringen.
Der Schlüssel besteht darin, das Tool so einzusetzen, dass die Entwicklung nicht an Geschwindigkeit verliert, während sie sich auf die Verbesserung der Qualität konzentriert und sich nicht mit Tool-Eigenheiten und Rauschen befasst. Dies ist ein Balanceakt, der Übung und Fachwissen erfordert, die die Auriga-Ingenieure im Laufe der Jahre erworben haben. Wir haben jedoch festgestellt, dass Sie bei der Ermittlung der Grundursache der gemeldeten Fehler wahrscheinlich feststellen werden, dass viele von ihnen leicht zu beheben sind .
Hier sind nur einige Beispiele aus statischen Analyseberichten, die einfach mit einem einfachen Skript oder gut ausgebildeten Praktikanten behoben werden können:
1) Aufruf klarer Funktionen in Destruktoren:
ein. Der Destruktor '~ CTitle' sollte nicht die Funktion 'clear_' aufrufen, die sich nicht im try-Kontext befindet
b. Der Destruktor '~ THelper' sollte die Funktion 'removeModule' nicht aufrufen, die sich nicht im try-Kontext befindet
2) Auf NULL prüfen:
ein. "PMP" kann möglicherweise null sein
b. "((NPage *) this) -> pSysCfg_" kann möglicherweise null sein
3) Möglicherweise Erklärung im falschen Abschnitt:
ein. Die Datenelemente 'D_FILE_1' werden als 'öffentlich' deklariert.
4) Nicht konstante Argumente:
ein. Das String-Literal "MCollection" wird an die Funktion 'FixedBlockHeap' als Zeiger auf ein nicht konstantes Objekt übergeben
Viele Verstöße gegen vorhandenen Code können Sie beiseite legen und beheben, wenn Sie Ausfallzeiten haben. Es ist jedoch wichtig, beim Entwickeln von Code KEINE neuen Verstöße (technische Abteilung) einzuführen. Beispielsweise, Parasoft C / C ++ test verfügt über Funktionen, mit denen Ingenieure das Rauschen filtern und sich auf die Behebung der kritischsten Verstöße gegen die statische Analyse konzentrieren können.
Während die statische Analyse den Quellcode als Text interpretiert und alle Schlussfolgerungen basierend auf der Parser-Ausgabe zieht, ohne eine einzige Anweisung auszuführen, Dynamic Application Security Testing oder DAST bietet eine andere Perspektive auf den Code. Es untersucht die Laufen Code, der die Codeabdeckung, die Ausreichend- keit und die Qualität von Komponententests, Speicherlecks und anderen potenziellen Schwachstellenproblemen anzeigt.
Der Begriff „eingebettet“ umfasst viele Geräte: von 8-Bit-MCU mit Kilobyte RAM und Flash bis hin zu 64-Bit-Multicore-CPU mit Gigabyte RAM und Hochgeschwindigkeits-SSD. Für den Fall, dass der tägliche Betrieb des Geräts nur minimalen Speicher- und Verarbeitungsaufwand erfordert, entscheiden sich die Hersteller wahrscheinlich für Hardware, die nur auf die Anforderungen der Größe, des Gewichts oder der Kosten ausgerichtet ist. Obwohl sie normalerweise eine gewisse Kapazität für Software-Updates und -Wartung lassen, kann dies für das dynamische Analysetool, das die Software instrumentiert, immer noch unzureichend sein, da der Prozess eine große Menge an RAM (im Vergleich zum normalen Betriebsmodus) und Speicherplatz erfordert Sammeln Sie Test- und Codeabdeckungsergebnisse.
Wenn die Speichermenge auf dem Gerät zu gering ist, um Tests durchzuführen und die Codeabdeckung zu erfassen, ist die Zielplattform möglicherweise nicht zum Sammeln der Codeabdeckung für Einheiten- und Integrationstests geeignet.
Wenn Ihre Hauptzielplattform nicht sofort unterstützt wird, suchen Sie nach gültigen Alternativen. Möglicherweise gibt es eine Schwesterplattform mit mehr Schnittstellen und Speicher, die von einem dynamischen Analysetool unterstützt werden, sodass Sie sie für Unit- und einige Integrationstests verwenden können. Eine andere Alternative ist die Verwendung von Hardware-Simulatoren, auf denen ARM Fast Models und QEMU ausgeführt werden.
Während das Ausführen von Tests auf der Zielplattform am wünschenswertesten ist, entscheiden sich Teams häufig dafür, Unit- und einige Anwendungsintegrationstests auf der Workstation des Entwicklers (wie Linux, Mac, Windows) durchzuführen, um von einem schnelleren Entwicklungszyklus und einer größeren Anzahl verfügbarer Tools zu profitieren für allgemeine Entwicklungsplattformen. In diesem Fall müssen Sie Ihren eingebetteten Code portieren, um mit einem Host-Compiler zu kompilieren, was einige Herausforderungen mit sich bringen kann.
Es gibt viele Compiler, Build-Tools, Frameworks und Methoden, um sie auszuführen. Dynamische Analysetools unterstützen einige gängige Build-Techniken mit internen Annahmen darüber, wie Entwickler sie anwenden könnten. Selbst wenn der Code portabel ist, benötigt das Projektteam daher höchstwahrscheinlich zusätzliche Zeit, um die Einstellungen eines dynamischen Analysetools abhängig von der Funktionsweise des Build-Systems des Projekts anzupassen.
Es wird dringend empfohlen, alle Anstrengungen im Voraus zu schätzen, um den besten Ansatz für die zukünftige Entwicklung und Unterstützung auf lange Sicht zu finden.
Moderne dynamische Analysewerkzeuge generieren automatisch Sätze von Komponententests, um die Codeabdeckung zu erhöhen. Tools sind jedoch nur Tools - sie sind unabhängig von verschiedenen Szenarien, wie der Produktionscode verwendet werden soll, insbesondere wenn Sie versuchen, die Codeabdeckung zu erhöhen und eine Grenze zwischen reinen Komponententests und Integrationstests zu überschreiten. Sie müssen die generierten Komponententests weiterhin manuell aktualisieren und sogar neue schreiben, da nur Sie wissen, was der Code für positive und negative Testergebnisse tun soll.
Nach unserer Erfahrung können für eine Reihe ausgewählter Dateien in einem kritischen Bereich automatisch generierte Komponententests in einem Bereich von 40% bis 100% für jede Datei erstellt werden. Im Durchschnitt können die Zahlen für das gesamte Projekt zwischen 25% und 60% variieren.
Darüber hinaus können automatisch generierte Komponententests, bei denen nur Quellcode als Eingabe verwendet wird, auf einem fehlerhaften Code häufig perfekt ausgeführt werden. Die automatische Generierung sollte als ein guter Weg verwendet werden, um den Prozess des Komponententests zu starten. Das manuelle Erstellen von Testfällen verbessert die Qualität des Codes, da zusätzliche Codeüberprüfungen erzwungen werden und ein anderer Blickwinkel auf das Design geboten wird.
Die FDA verlangt, dass jedes Tool, das während der formalen Entwicklung verwendet wird, für den beabsichtigten Gebrauch gültig ist, um sicherzustellen, dass es die erwarteten Maßnahmen ausführt und die richtigen Ergebnisse liefert. Normalerweise ist dies ein spezielles Testprotokoll namens IUV (Intended Use Validation).
Branchenführende Anbieter von statischen und dynamischen Analysetools helfen bei der Erstellung der erforderlichen Verfahren und Dokumentationen. Dies ist äußerst hilfreich, um Ihren Aufwand zu minimieren. Parasofts sind besonders wertvoll, da sie einen großen Teil des Prozesses automatisieren. Wie bei jedem anderen generischen Paket möchten Sie möglicherweise einen Teil Ihrer Bemühungen zur Überprüfung und Anpassung von Dokumenten vorbehalten, um sie mit Ihren eigenen QMS-Verfahren zu synchronisieren. Beispielsweise bietet die Tool Qualification-Software von Parasoft eine Reihe von Testfällen, die in Ihrer Umgebung ausgeführt werden können, um die statischen und dynamischen Analysefunktionen zu validieren.
Wenn Sie Hilfe bei der Einführung statischer und dynamischer Analysen benötigen, kontaktieren Sie uns bitte unter Wagenlenker.
„MISRA“, „MISRA C“ und das Dreieckslogo sind eingetragene Marken von The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Alle Rechte vorbehalten.
Als Executive für Technologie- und Geschäftspartner bei Auriga strategisiert Andrey sein Software-F & E-Angebot, um die Herausforderungen der Hersteller elektronischer Geräte im Bereich Embedded SDLC zu lösen, einschließlich Qualitäts- und Cybersicherheitssicherung.