Gehen Sie einen schnelleren, intelligenteren Weg zur KI-gestützten C/C++-Testautomatisierung. Erfahren Sie mehr >>
Whitepaper
Neugierig, was im Whitepaper steht? Beginnen Sie mit der folgenden Übersicht.
Sicherheitsfunktionen in der industriellen Automatisierung werden zunehmend von komplexen elektrischen, elektronischen und programmierbaren elektronischen Systemen ausgeführt. Die Prüfung dieser Systeme ist unerlässlich, aber aufgrund ihrer Komplexität eine Herausforderung. Die Norm IEC 61508 bietet Leitlinien zur Reduzierung systematischer und zufälliger Hardwareausfälle auf ein tolerierbares Maß.
Dieses Whitepaper beschreibt detailliert, wie Parasoft Softwareentwicklungsteams bei der Erfüllung der SIL-Anforderungen unterstützt. Es stellt das Konzept von SIL gemäß IEC 61508 vor, beschreibt die integrierte Lösung von Parasoft zur Automatisierung bewährter Verfahren und zeigt, wie die Anforderungen an den Softwareentwicklungsprozess für bestimmte SIL-Stufen erfüllt werden können.
Sicherheitsintegritätsniveau (SIL) – definiert durch die Norm IEC 61508— ist eine von vier Stufen (SIL1–SIL4), die dem Bereich der Zielwahrscheinlichkeit gefährlicher Ausfälle einer gegebenen Sicherheitsfunktion entsprechen. Jeder Sicherheitsfunktion in einem sicherheitsrelevanten System muss ein geeignetes Sicherheitsintegritätsniveau zugewiesen werden. Ein sicherheitsrelevantes System der Elektrotechnik/Elektronik/Physik (E/E/PE) implementiert üblicherweise mehrere Sicherheitsfunktionen. Wenn sich die Sicherheitsintegritätsanforderungen für diese Sicherheitsfunktionen unterscheiden, gelten – sofern keine ausreichende Unabhängigkeit ihrer Implementierung besteht – die Anforderungen des höchsten relevanten Sicherheitsintegritätsniveaus für das gesamte sicherheitsrelevante System der Elektrotechnik/Elektronik/Physik.
Gemäß IEC 61508 wird das Sicherheitsintegritätsniveau für eine gegebene Funktion entweder anhand der durchschnittlichen Wahrscheinlichkeit eines Ausfalls ihrer Auslegungsfunktion bei Bedarf (bei einem Betrieb mit geringer Auslastung) oder anhand der Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde (bei einem Betrieb mit hoher Auslastung oder einem kontinuierlichen Betrieb) bewertet.
Die Norm IEC 61508 legt die Anforderungen für das Erreichen jedes Sicherheitsintegritätsniveaus fest. Diese Anforderungen sind bei höheren Sicherheitsintegritätsniveaus strenger, um die erforderliche geringere Wahrscheinlichkeit gefährlicher Ausfälle zu gewährleisten.
Parasoft C/C++test ist eine integrierte Lösung zur Automatisierung einer breiten Palette bewährter Verfahren, die nachweislich die Produktivität von Softwareentwicklungsteams und die Softwarequalität verbessern. C/C++test ermöglicht:
Dies bietet Teams eine praktische Möglichkeit, Fehler zu vermeiden, aufzudecken und zu beheben, um sicherzustellen, dass ihr C- und C++-Code wie erwartet funktioniert. Um eine schnelle Behebung zu fördern, wird jedes erkannte Problem anhand konfigurierbarer Schweregrade priorisiert, automatisch dem Entwickler zugewiesen, der den zugehörigen Code geschrieben hat, und in dessen IDE mit direkten Links zum problematischen Code und einer Beschreibung der Fehlerbehebung bereitgestellt.
Für die Entwicklung eingebetteter Systeme und plattformübergreifender Anwendungen kann C/C++test sowohl in hostbasierten als auch zielsystembasierten Codeanalyse- und Testabläufen eingesetzt werden.
Die Automatisierung von Parasoft C/C++test steigert die Effizienz beim Testen der Korrektheit und Zuverlässigkeit von neu entwickeltem oder bestehendem Code erheblich. C/C++test generiert automatisch vollständige Tests, einschließlich Testtreiber und Testfälle für einzelne Funktionen, ausschließlich in C oder C++. Diese Tests dienen, gegebenenfalls mit Anpassungen, der ersten Validierung des funktionalen Verhaltens des Codes. Durch die Verwendung von Grenzfällen prüfen diese automatisch generierten Testfälle auch das Verhalten von Funktionen bei unerwarteten Eingaben und decken so potenzielle Zuverlässigkeitsprobleme auf.
Die Berichte von Parasoft C/C++test in HTML, PDF und benutzerdefinierten Formaten lassen sich über die grafische Benutzeroberfläche oder eine Optionsdatei konfigurieren. Die Standardberichte enthalten eine Zusammenfassung der Codeanalyse und der Testergebnisse (bestanden/nicht bestanden), eine Liste der analysierten Dateien sowie eine Übersicht der Codeabdeckung. Die Berichte können individuell angepasst werden und enthalten dann eine Liste der aktiven statischen Analysen, erweiterte Testausgaben mit dem Status (bestanden/nicht bestanden) einzelner Tests, Parameter von Trenddiagrammen für wichtige Kennzahlen sowie vollständige Codelisten mit farblicher Kennzeichnung aller Codeabdeckungsergebnisse.
Codeanalyse und Testergebnisse, Abdeckungsanalyse und andere C/C++-Testdaten können gesendet werden an Parasoft DTP Die Daten werden mit Daten korreliert, die von Drittanbieter-Analysetools, Quellcodeverwaltung, Fehlerverfolgung und anderen Infrastrukturkomponenten generiert und von DTP verarbeitet werden. Das Ergebnis sind handlungsrelevante, intelligente Analysen, die nicht nur Einblick in die mit der zu testenden Anwendung verbundenen Risiken bieten, sondern auch die für die Erfüllung der SIL-Anforderungen erforderliche Rückverfolgbarkeit gewährleisten.
Die folgenden Tabellen beschreiben, wie Parasoft C/C++test die für Sicherheitsfunktionen erforderlichen Methoden des Softwareentwicklungszyklus unterstützt, um ein bestimmtes SIL zu erreichen. Bitte beachten Sie, dass die hier präsentierten Informationen lediglich eine kurze Einführung in die Verwendung von C/C++test im SIL-bezogenen Verifizierungs- und Testprozess darstellen. Für eine Klärung der in der Norm IEC 61508 definierten Anforderungen konsultieren Sie bitte die Norm und wenden Sie sich an Experten für funktionale Sicherheit. Bei weiteren Fragen zur Verwendung von C/C++test im IEC 61508-Zertifizierungsprozess kontaktieren Sie bitte Ihren Parasoft-Ansprechpartner.
Die folgenden Symbole werden in den nachstehenden Tabellen verwendet, um Folgendes anzuzeigen:
Die in Anhang A und B der IEC 61508-3 Ausgabe 2.0 2010 definierten Techniken und Maßnahmen, die von der C/C++test-Funktionalität erfüllt werden, sind in den folgenden Tabellen aufgeführt.
| C/C++-Testfunktionalität | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Design- und Codierungsstandards | ||||
| Verwendung von Codierungsstandards zur Verringerung der Fehlerwahrscheinlichkeit (Tabelle B.1: 1) | - | R | HR | HR |
| Keine dynamischen Objekte (Tabelle B.1: 2) | R | HR | HR | HR |
| Keine dynamischen Variablen (Tabelle B.1: 3a) | - | R | HR | HR |
| Online-Prüfung der Installation dynamischer Variablen (Tabelle B.1: 3b) | - | R | HR | HR |
| Begrenzte Nutzung von Interrupts (Tabelle B.1: 4) | R | R | HR | HR |
| Begrenzte Verwendung von Zeigern (Tabelle B.1: 5) | - | R | HR | HR |
| Begrenzte Verwendung von Rekursion (Tabelle B.1: 6) | - | R | HR | HR |
| Kein unstrukturierter Kontrollfluss in Programmen in höheren Programmiersprachen (Tabelle B.1: 7). | R | HR | HR | HR |
| Keine automatische Typumwandlung (Tabelle B.1: 8) | R | HR | HR | HR |
| Dynamische Analyse und Tests | ||||
| Testfallausführung aus der Grenzwertanalyse (Tabelle B.2: 1) | R | HR | HR | HR |
| Testfallausführung durch Fehlerraten (Tabelle B.2: 2) | R | R | R | R |
| Testfallausführung ab Fehlerinitiierung (Tabelle B.2: 3) | - | R | R | R |
| Äquivalenzklassen und Eingangspartitionstests (Tabelle B.2: 6) | R | R | R | HR |
| Strukturelle Prüfabdeckung (Eintrittspunkte) 100% (Tabelle B.2: 7a) | HR | HR | HR | HR |
| Strukturelle Testabdeckung (Aussagen) 100% (Tabelle B.2: 7b) | R | HR | HR | HR |
| Strukturelle Prüfabdeckung (Zweige) 100% (Tabelle B.2: 7c) | R | R | HR | HR |
| Strukturelle Testabdeckung (Bedingungen, MC/DC) 100% (Tabelle B.2: 7d) | R | R | R | HR |
| Funktions- und Black-Box-Tests | ||||
| Äquivalenzklassen und Eingangspartitionstests, einschließlich Grenzwertanalyse (Tabelle B.3: 4) | R | HR | HR | HR |
| Performance Testing | ||||
| Lawinen-/Belastungsprüfung (Tabelle B.6: 1) | R | R | HR | HR |
| Statische Analyse | ||||
| Grenzwertanalyse (Tabelle B.8: 1) | R | R | HR | HR |
| Checklisten (Tabelle B.8: 2) | R | R | R | R |
| Kontrollflussanalyse (Tabelle B.8: 3) | R | HR | HR | HR |
| Datenflussanalyse (Tabelle B.8: 4) | R | HR | HR | HR |
| Fehlerraten (Tabelle B.8: 5) | R | R | R | R |
| Formale Inspektionen, einschließlich spezifischer Kriterien (Tabelle B.8: 6a) | R | R | HR | HR |
| Schritt für Schritt (Software) (Tabelle B.8: 6b) | R | R | R | R |
| Symbolische Ausführung (Tabelle B.8: 7) | - | - | R | R |
| Designprüfung (Tabelle B.8: 8) | HR | HR | HR | HR |
| Statische Analyse des Laufzeitfehlerverhaltens (Tabelle B.8: 9) | R | R | R | HR |
| Modularer Ansatz | ||||
| Größenbeschränkung für Softwaremodule (Tabelle B.9: 1) | HR | HR | HR | HR |
| Kontrolle der Softwarekomplexität (Tabelle B.9: 2) | R | R | HR | HR |
| C/C++-Testfunktionalität | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Design von Softwarearchitekturen | ||||
| Fehlererkennung (Tabelle A.2: 1) | - | R | HR | HR |
| Verschiedene Überwachungstechniken (mit Trennung zwischen dem Überwachungsrechner und dem überwachten Rechner) (Tabelle A.2: 3c) | - | R | R | HR |
| Diverse Redundanz, die dieselbe Spezifikation für Software-Sicherheitsanforderungen implementiert (Tabelle A.2: 3e) | - | - | - | R |
| Verwendung vertrauenswürdiger/geprüfter Softwareelemente (sofern verfügbar) (Tabelle A.2: 8) | R | HR | HR | HR |
| Unterstützungswerkzeuge und Programmiersprache | ||||
| Geeignete Programmiersprache (Tabelle A.3: 1) | HR | HR | HR | HR |
| Stark typisierte Programmiersprache (Tabelle A.3: 2) | HR | HR | HR | HR |
| Sprachteilmenge (Tabelle A.3: 3) | - | - | HR | HR |
| Zertifizierte Tools und zertifizierte Übersetzer (Tabelle A.3: 4a) | R | HR | HR | HR |
| Werkzeuge und Übersetzer: gesteigertes Vertrauen durch die Nutzung (Tabelle A.3: 4b) | HR | HR | HR | HR |
| Detailliertes Design | ||||
| Strukturierte Methoden (Tabelle A.4: 1a) | HR | HR | HR | HR |
| Formale Entwurfs- und Verfeinerungsmethoden (Tabelle A.4: 1c) | - | R | R | HR |
| Defensive Programmierung (Tabelle A.4: 3) | - | R | HR | HR |
| Modularer Ansatz (Tabelle A.4: 4) | HR | HR | HR | HR |
| Design- und Codierungsstandards (Tabelle A.4: 5) | R | HR | HR | HR |
| Strukturierte Programmierung (Tabelle A.4: 6) | HR | HR | HR | HR |
| Verwendung vertrauenswürdiger/geprüfter Softwareelemente (Tabelle A.4: 7) | R | HR | HR | HR |
| Vorwärtsrückverfolgbarkeit zwischen der Spezifikation der Software-Sicherheitsanforderungen und dem Software-Design (Tabelle A.4: 8) | R | R | HR | HR |
| Softwaremodul-Test und -Integration | ||||
| Dynamische Analyse und Prüfung (Tabelle A.5: 2), (Tabelle A.9: 4) | R | HR | HR | HR |
| Datenerfassung und -analyse (Tabelle A.5: 3) | HR | HR | HR | HR |
| Funktions- und Black-Box-Tests (Tabelle A.5: 4)(Tabelle A.7: 4) | HR | HR | HR | HR |
| Schnittstellenprüfung (Tabelle A.5: 7) | R | R | HR | HR |
| Testmanagement- und Automatisierungswerkzeuge (Tabelle A.5: 8) | R | HR | HR | HR |
| Vorwärtsrückverfolgbarkeit zwischen der Software-Designspezifikation und den Modul- und Integrationstestspezifikationen (Tabelle A.5: 9) | R | R | HR | HR |
| Formale Überprüfung (Tabelle A.5: 10) | - | - | R | R |
| Änderung | ||||
| Überprüfen Sie das geänderte Softwaremodul erneut (Tabelle A.8: 2). | HR | HR | HR | HR |
| Überprüfen Sie das betroffene Softwaremodul erneut (Tabelle A.8: 3) | R | HR | HR | HR |
| Vollständiges System erneut validieren (Tabelle A.8: 3) | - | R | HR | HR |
| Regressionsvalidierung | R | HR | HR | HR |
| Software-Verifizierung | ||||
| Formaler Beweis | - | R | R | HR |
| Statische Analyse | R | HR | HR | HR |
| Dynamische Analyse und Prüfung (Tabelle A.5: 2), (Tabelle A.9: 4) | R | HR | HR | HR |
| Vorwärtsrückverfolgbarkeit zwischen der Software-Designspezifikation und dem Softwareverifizierungsplan (einschließlich Datenverifizierung) | R | R | HR | HR |
| Rückverfolgbarkeit zwischen dem Softwareverifizierungsplan (einschließlich Datenverifizierung) und der Software-Designspezifikation | R | R | HR | HR |
| C/C++-Testfunktionalität | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Hard-und Software | ||||
| Funktions- und Black-Box-Tests (Tabelle A.6: 1) | HR | HR | HR | HR |
| Vorwärtsrückverfolgbarkeit zwischen den System- und Software-Designanforderungen für die Hardware/Software-Integration und der Spezifikation für Hardware/Software-Integrationstests (Tabelle A.6: 3) | R | R | HR | HR |
| C/C++-Testfunktionalität | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Parasoft DTP-Berichts- und Analyse-Dashboard | ||||
| Vorwärtsrückverfolgbarkeit zwischen den Systemsicherheitsanforderungen und den Softwaresicherheitsanforderungen (Tabelle A.1:2). | R | R | HR | HR |
| Rückverfolgbarkeit zwischen den Sicherheitsanforderungen und den wahrgenommenen Sicherheitsbedürfnissen (Tabelle A.1:3) | R | R | HR | HR |
| Computergestützte Spezifikationswerkzeuge zur Unterstützung geeigneter Techniken/Maßnahmen (Tabelle A.1:4) | R | R | HR | HR |
Parasoft C/C++test unterstützt Softwareentwicklungsteams bei der Erfüllung der funktionalen Sicherheitsanforderungen der IEC 61508. Es bietet eine breite Palette an Analysetypen, darunter: Analyse der Einhaltung von CodierungsstandardsDaten- und Kontrollflussanalyse, Unit-Tests, Anwendungsüberwachung, Workflow-Komponenten und Peer-Code-Review-Prozesse – zusammen mit den konfigurierbaren Testberichten, die einen hohen Detaillierungsgrad aufweisen, erleichtern die für den Softwareverifizierungsprozess erforderlichen Arbeiten erheblich.
Bereit, tiefer einzutauchen?
