Expertise Software

Die Betriebssicherung von Softwareprogrammen, die in ein komplexes System eingebettet sind, hängt so gut wie ausschließlich davon ab, wie vollständig die Anforderungen definiert wurden, sowie von der Konzeption, den Einzeltests, der Integration und der Validierung im System.
Wir empfehlen folgende Vorgehensweise:

> Spezifikation der Anforderungen zur Betriebssicherung der Software,
> Umsetzung der Softwaretests,
> Auditieren des Entwicklungsprozesses der Software,
> Erfassen der Auswirkung der Funktionsstörungen der Software auf das System

Ein geringfügiger Fehler in einem Modul, tief in der Software, eine falsche Auslegung der Funktionserfordernisse des Systems, eine falsche Schnittstellenbildung der Software mit einer Umgebung, all das kann zu Gefahren führen, die der Funktionssicherheit des Systems gefährlich schaden können.
Daher besteht unser Beruf in der Umsetzung der Techniken zur Verifikations- und Validierungsbewertung, um die Betriebssicherung der Software zu gewährleisten:

> Kontrollieren der Vollständigkeit eines Softwarcodes (LCC),
> Prüfen der Testabdeckung der Software,
> Analyse der Auswirkung der Softwareänderungen,
> Analyse der Fehlerarten der Software und
ihrer Auswirkungen auf das System (AMDE, AEEL),
> formaler Nachweis der Korrektheit von Software.

SPECIFIKATION

Unterstützung des Projektträgers eines Softwaresystems, der Betriebssicherungskriterien erfüllen muss (Zuverlässigkeit, Wartbarkeit, Verfügbarkeit, Sicherheit) bei:
der Auswahl der relevantesten Anforderungen abhängig vom Systemtyp, der Kritizität der Funktionen dieses Systems, des geltenden Normenverzeichnisses,
der Formulierung der Sicherungsanforderungen der Software (Produkt, Prozess), die im Lastenheft oder in der technischen Spezifikation stehen müssen,
Vorbereitung der Analyse der Herstellerantworten auf diese Anforderungen.

ANALYSE

„Analyse der Fehlerarten und ihrer Auswirkungen“

Bei der Umsetzung von Systemen, bei welchen bestimmte kritische Funktionen (RAMS -bezogen) von der Software getragen werden, erlaubt es diese Methode dem Projektträger und dem Hauptauftragnehmer, die Fehler der Software zu identifizieren, die zu kritischen Ereignissen im Systems führen können, aber auch die Architektur der Software im Hinblick auf die Betriebssicherung und Fehlertoleranz zu bewerten.
Sie erlaubt es dem Prüfer / der Zertifizierungsstelle außerdem und zwar völlig unabhängig – die Restgefährdungen der Softwarefunktionen zu identifizieren, die zum Auftreten von kritischen Ereignissen im System führen können.


Die FMEA der Software baut auf einer formalisierten Funktionsanalyse auf. Sie besteht aus folgenden Elementen:

• der technischen Spezifikation der Softwareanforderungen (STBL),
• dem Software-Architekturdokument (SAD) oder der Grobfassung des Design-Dokuments (Preliminary Design Document – PDD),
• dem Feinkonzept (Detailed Design Document – DCD),
• dem Software-Code

Die funktionale Verhaltensweise wird ausgehend von dem Quellcode mit Hilfe unserer Werkzeuge APRLS® und AGFL® bestimmt, welche die Softwarearchitektur bis hin zu den Logikketten der Software-Bauteile liefern.

AUDITIERUNG

Die Zielsetzung der Auditierung des Softwareentwicklungsprozesses besteht darin, dem Projektträger eine objektive Bestätigung für die Konformität der Entwicklungsprozesse der geprüften Einheit (Hauptauftragnehmer, Lieferanten, Unterlieferanten usw.) im Vergleich zum Stand der Technik und zu den Normvorschriften (IEC61508-3, CENELEC 50128, IEC 880, DO 178B,…) zu liefern.

Die Übereinstimmung der Prozesse mit den Zuverlässigkeitsnormen wird anhand folgender Aspekte bewertet:

• Lebenszyklus der Software,
• Spezifikation der Softwarevorschriften,
• Konzeption und Entwicklung der Software,
• V&V („Verifizierung und Validierung“) der Software,
• Planung und Dokumentation der Software,
• Organisation der Teams (Verantwortung, Unabhängigkeit der Teams, Informationsfluss…),
• Projektmanagement (Planung, Reviews, Konfigurationsmanagement, Änderungsmanagement, Qualitätsmessungen usw.).

Wir verwenden das Tool Audit_SdF® mit den Anforderungschecklisten der zu bewertenden Norm. Eine Metrik wird für jedes dieser Themen in Abhängigkeit von den wichtigen Kriterien, die an den Kontext der geprüften Prozesse angepasst sind, bewertet.

TEST

Dem Projektträger alle Mittel, Methoden und Tools bereitstellen, um von einem unabhängigen Expertenteam die Einzeltests und Integrationstests (Software/Software, Software/Hardware) zur Bestätigung der in das System, das ihm obliegt , integrierten Softwareprogramme durchführen zu lassen.
Erstellen der Planungen und Dossiers der Einzel-, Integrations- und Bestätigungstests.
Erstellen eines Prüfnachweisdossiers der ausgeführten Tests im Hinblick auf die Anforderungen der für das Projekt geltenden Vorschriften.

VERIFIKATION

Unterstützen des Projektträgers, Betreibers oder Bewerters eines Systems, das Software enthält, beim Prüfen der funktionalen Deckungsgleichheit und der Vollständigkeit der Einzel-, Integrations- und Bestätigungstests im Hinblick auf die Sicherheitsauflagen.

Durch Einsatz des Tools AGFL® (Analyse mit funktionaler Graphik der Software ) Identifikation der Funktions-, Robustheits- und Fehlertoleranztest-Szenarien sowie der Tests durch Fehlerinjektion, die die Testdossiers abrunden müssen, damit das System zu einer Deckungsgleichheit des Typs „Äquivalenzklasse“ gelangt.

„Äquivalenzklasse“: D.h., die Partition des Speicherbereichs eines Programms derart, dass ein Test, der einen repräsentativen Wert einer Klasse verwendet, mit einem Test gleichwertig ist, der einen anderen Wert dieser Klasse verwendet. (Quelle: Norm DO 178 B).

KRITIK

Das kritische Lesen des Codes erlaubt es dem Projektträger eines Softwaresystems, das Qualitäts- und Betriebssicherungsforderungen erfüllen muss, die Anwendung der Regeln des Stands der Technik für Qualität und Sicherheit des Codes der Softwareprogramme zu kontrollieren (C, ADA, Modula2, Assemblers), wie zum Beispiel:

• geringfügig sichere Konstruktionen (switch Schaltschrank case ohne clause faultdefault clause, dead nicht benötigter code usw.),
• Anomalien des Kontrollstroms (Rekursion, multiple Bauteilausgänge…),
• Anomalien der Datenströme (Speicher / nicht aufgefrischte Ausgänge auf einem Ausführungspfad),
• Ordnungsrelation auf den fehlerhaften Eingängen auf einem Ausführungspfad, globale Variable zwischen
• parallelen Verarbeitungen, nicht initialisierten Eingänge, nicht verwendeten Eingänge usw.),
• Anomalien des Abhängigkeitsstroms der Daten (Randeffekte der abgerufenen Bauteile usw.),
• Konformität der Funktionspfade des Codes mit den Softwarespezifikationen (STBL , SAD),
• Rückverfolgbarkeit des Codes hinsichtlich seiner Konzeptionsanforderungen (PDD, DCD).

Alle diese Kontrollen erfolgen mit Hilfe unserer Tools AGFL® und APRLS®, die an dem Code angewandt werden.

VALIDIERUNG

Die Methode der formellen Validierung der Spezifikation erlaubt es dem Projektträger oder dem Hauptauftragnehmer, die Gewissheit der Vollständigkeit und der Kohärenz der Funktionalitäten, die die Software enthält und die in den Spezifikationen der Software enthalten sind, früher zu erhalten. Diese Gewissheit ergibt sich durch das Erstellen eines formalen Modells dieser Funktionalitäten und eines Nachweises in Form von mathematischen Beweisen, in denen die Einhaltung der Sicherungseigenschaften der Softwarfunktionen im System demonstriert wird.
(Diese Vorgehensweise wird für die Softwareprogramme des Niveaus SIL 4 in der Norm IEC 61508 „sehr empfohlen“ (HR – highly recommended )).