DO-178C-Softwarekonformität für die Luft- und Raumfahrt sowie Verteidigung

Das Radio Technical Committee for Aeronautics (RTCA) DO-178C ist ein funktionaler Sicherheitsstandard, der Leitlinien und Überlegungen zur Erstellung von Software für Bordsysteme und -geräte enthält. Ziel ist es, sicherzustellen, dass das System seine beabsichtigte Funktion mit einem Maß an Sicherheit erfüllt, das den Anforderungen an die Lufttüchtigkeit entspricht. Wenn ein Flugzeug über den kommerziellen US-Luftraum fliegen soll, ist die Einhaltung des Standards erforderlich.

DO-178C bietet die folgenden Hinweise:

• Ziele für Software-Lebenszyklusprozesse
• Aktivitäten, die zur Erreichung dieser Ziele beitragen
• Beschreibungen der Nachweise in Form von Software-Lebenszyklusdaten, die belegen, dass die Ziele erreicht wurden
• Variationen in den Kategorien Ziele, Unabhängigkeit, Software-Lebenszyklusdaten und Kontrolle nach Softwareebene
• Zusätzliche Überlegungen (z. B. zuvor entwickelte Software), die für bestimmte Anwendungen gelten
• Definition der im Glossar angegebenen Begriffe

DO-178C deckt den gesamten Engineering-Lebenszyklus ab. Von der Planung, Entwicklung, Verifizierung, Qualitätssicherung, Zusammenarbeit und Zertifizierung. Es ist in 12 Abschnitte unterteilt. Abschnitt 1 (nicht abgebildet) beschreibt den Zweck, den Umfang und die Verwendung des Dokuments.

Die RTCA wurde bereits 1935 gegründet. Sie ist eine unabhängige Organisation zur Entwicklung von Standards und dient als Grundlage für die staatliche Zertifizierung der Ausrüstung, die von den Zehntausenden Flugzeugen verwendet wird, die täglich durch den weltweiten Luftraum fliegen.

RTCA ist ein privates, gemeinnütziges Unternehmen, das eng mit der Federal Aviation Administration (FAA) und Branchenexperten aus den USA und der ganzen Welt zusammenarbeitet, wie etwa der Arbeitsgruppe der European Organization for Civil Aviation Equipment (EUROCAE), um diesen umfassenden, zeitgemäßen Luftfahrtstandard zu entwickeln. Die EUROCAE ist eine gemeinnützige Organisation mit dem Ziel, Standards für die europäische Zivilluftfahrt zu entwickeln.

Der ursprüngliche DO-178-Standard wurde bereits 1982 veröffentlicht. Er wurde jedoch nicht als nützlich erachtet. Daher folgte die 178 veröffentlichte DO-1985A-Revision. Diese Revision konzentrierte sich mehr auf moderne Softwareentwicklungsprinzipien und Verifizierungspraktiken. Sie führte eine Korrelation zwischen kritischen Fehlerzuständen mit den Levelnummern 1, 2 und 3 ein. Level 1, das Sie vielleicht besser als Development Assurance Level (DAL) kennen, war das strengste.

Im Dezember 1992 erfolgte die Revision DO-178B wurde veröffentlicht, das von einem „How-to“-Dokument zu einem „Was tun“-Dokument wechselte. Ein großer Schwerpunkt wurde auf die Ziele gelegt, die Ihr Softwareprozess erfüllen muss, um Konformität und letztendlich Zertifizierung zu erreichen.

Eine weitere auffällige Änderung betraf die Anzahl der in DAL definierten möglichen kritischen Fehlerbedingungen. Sie stieg auf fünf Softwareebenen und änderte sich von Zahlen zu Buchstaben von A bis E. Ebene A war die strengste und Ebene E bedeutete keine Sicherheitsanforderungen. Außerdem wurde das Testen Ihrer Anforderungen stark betont. Es wurde empfohlen, nicht den Code zu betrachten, um Testfälle zu erstellen, sondern Ihre Anforderungen zu prüfen. Dies wurde durch eine strukturelle Codeabdeckung unterstützt, um sicherzustellen, dass Sie alles abgedeckt haben.

DO-178B beinhaltete außerdem die bidirektionale Rückverfolgbarkeit zwischen Systemen, High- und Low-Level-Anforderungen, einschließlich Testfällen, und bis hinunter zum Code, um zu zeigen, dass alle Anforderungen umgesetzt wurden. Die Idee, für den Einsatz qualifizierte Tools bereitzustellen, wurde eingeführt.

Heute sind wir bei Revision C. DO-2012C wurde im Januar 178 veröffentlicht und entfernte zur Verdeutlichung ungenaue Formulierungen aus DO-178B. Es handelte sich auch um eine gemeinsame Anstrengung von RTCA und EUROCAE. Der Hauptunterschied zwischen DO-178B und DO-178C ist jedoch die Einführung eines modularen Ansatzes für ergänzende Leitliniendokumente. Sie haben jetzt ergänzende Standards, darunter die folgenden.

Dieser Leitfaden bietet einen komprimierten Überblick über die einzelnen Abschnitte von DO-178C und hebt die wichtigsten Erkenntnisse hervor.

Systemaspekte der Software-Entwicklung, Abschnitt 2

Abschnitt 2 befasst sich mit den Prozessen des Systemlebenszyklus, den erstellten Artefakten, ihrem Einfließen in den Softwarelebenszyklus und dem Informationsfluss zwischen diesen Prozessen. Ein großer Teil davon ist die Anforderungsanalyse, bei der die Anforderungen an das Softwaresystem zunächst aus den Systembetriebsanforderungen oder Kundenanforderungen entwickelt werden und wie diese Artefakte in den Softwarelebenszyklus einfließen.

Im Lebenszyklus einer Software werden die Anforderungen fortlaufend zerlegt, die Software wird verifiziert und schließlich zertifiziert.

Obwohl DO-178C den Fluss zwischen System- und Softwarelebenszyklen im obigen Diagramm erfasst, ist das Thema in der SAE ARP4754A-Norm, Richtlinien für die Entwicklung ziviler Flugzeuge und Systeme.

In Abschnitt 2 werden die folgenden Themen behandelt:

• Zuordnung der Systemanforderungen zur Software
• Informationsfluss zwischen den System- und Software-Lebenszyklusprozessen und zwischen den Software- und Hardware-Lebenszyklusprozessen
• Prozess zur Bewertung der Systemsicherheit, Fehlerbedingungen, Software-Level-Definitionen und Software-Level-Bestimmung » Architektonische Überlegungen
• Architektonische Überlegungen
• Softwareüberlegungen in Systemlebenszyklusprozessen
• Systematische Überlegungen in Software-Lebenszyklus-Prozessen

Ein weiterer wichtiger Teil von Abschnitt 2 ist die Bestimmung der Software-Level-Klassifizierung oder DAL. Katastrophale Folgen wären ein Ausfall der Flugsteuerungssoftware, bei dem ein Flugzeug abstürzen und viele Menschenleben verloren gehen würden. Dies würde als Software-Level A klassifiziert werden.

„Gefährlich“ ist eine Stufe darunter. Schwere oder tödliche Verletzungen einer relativ kleinen Zahl von Insassen außer der Flugbesatzung würden der Softwarestufe B entsprechen. Die Klassifizierung geht weiter hinunter bis zur Softwarestufe E, wo im Falle eines Fehlers keine Sicherheitsbedenken bestehen.

Eine andere Perspektive oder Seite dieser Klassifizierung ist die Qualitätssicherung. Mit jeder höheren Stufe von Stufe E zu Stufe A gibt es eine höhere Anzahl von Zielen, die erreicht werden müssen. Beispielsweise verbessert sich die Rückverfolgbarkeit zwischen Artefakten, die während der Produktentwicklung erstellt werden. Außerdem werden mehr Softwaretests durchgeführt. Die Software muss möglicherweise die Assembly- oder Objektcode-Abdeckung erfüllen, anstatt nur die Anweisungs-, Zweig- und MC/DC-Abdeckung.

Als Best Practice können Sie hier angeben: Wenn Ihre Software auf Level B oder niedriger eingestuft ist, sollten Sie versuchen, einige oder alle der nächsthöheren Softwarelevel-Ziele zu erreichen. Der zusätzliche Aufwand zwischen einigen der Entwicklungssicherungslevel ist möglicherweise nicht allzu groß und die Vorteile könnten sich durchaus auszahlen, wenn die Kundenanforderungen strenger werden.

Unten sehen Sie das bekannte V-Modell. Die rechte Seite zeigt die System- und Software-Designphasen, während die linke Seite die Verifizierungsphasen zeigt. Der Standard ARP4754 ist Ihr Referenzdokument für die Entwicklung von Flugzeugsystemen unter Berücksichtigung der gesamten Betriebsumgebung und Funktionen des Flugzeugs. Dazu gehören die Validierung der Anforderungen und die Verifizierung der Designimplementierung für die Zertifizierung und Produktsicherung.

Software-Lebenszyklus, Abschnitt 3

Abschnitt 3 behandelt die Aspekte des Software-Lebenszyklus. Die bekannte Abfolge des SDLC besteht aus Anforderungsmanagement, Design, Codierung und Integration. DO-178C empfiehlt keinen zu verwendenden Entwicklungsprozess. Es bleibt den Organisationen überlassen, diese Entscheidung auf der Grundlage ihrer eigenen Erfahrungen und Faktoren wie aktueller Technologie (z. B. Agile, DevSecOps, CI/CD) oder Kundenanforderungen zu treffen. Welchen Prozess Sie auch wählen, die zu erreichenden Ziele des Standards werden durch den Prozess nicht behindert.

Zu den Software-Lebenszyklusprozessen von DO-178C gehören die folgenden:

• Softwareplanungsprozess. Definiert und koordiniert die Aktivitäten der Softwareentwicklung und integralen Prozesse für ein Projekt.
• Softwareentwicklungsprozesse. Erstellen Sie das Softwareprodukt. Dieser Prozess besteht aus Prozessen für Anforderungen, Design, Codierung und Integration.
• Integrale Softwareprozesse. Stellen Sie die Richtigkeit, Kontrolle und Vertrauenswürdigkeit der Software-Lebenszyklusprozesse und ihrer Ergebnisse sicher. Dazu gehören Verifizierung, Konfigurationsmanagement, Qualitätssicherung und Zertifizierungsvermittlung.

Softwareplanungsprozess, Abschnitt 4

Abschnitt 4 behandelt die Ziele und Aktivitäten des Softwareplanungsprozesses. Die Ziele sind klar definiert und in Tabelle A-1 des Standards festgehalten. Es gibt sieben Ziele, die auf der Grundlage der Softwareebene (AD) erfüllt werden müssen. Zu diesen Zielen gehört die Definition der folgenden Punkte:

• Software-Lebenszyklusprozess
• Wechselwirkungen zwischen Prozessen
• Zu verwendende Methoden und Werkzeuge
• Entwicklungsstandards zur Gewährleistung der Sicherheit
• Überprüfung, ob die Software die Entwicklungsanforderungen erfüllt
• Überprüfung, ob die Organisationen, die diese Aktivitäten durchführen werden

Beim Softwareplanungsprozess sind außerdem viele Aspekte zu berücksichtigen, wie etwa die Absicht, zuvor entwickelte Software oder kommerzielle Standardsoftware (COTS) zu verwenden, die Tool-Qualifizierung und vieles mehr, was in Abschnitt 12 beschrieben wird.

In Tabelle A-1 des Standards sind die Ziele, die geltenden Softwareebenen und das erwartete Ergebnis dieser Aktivitäten erfasst. Dabei handelt es sich um einen Satz von Dokumenten mit Berichtsinformationen zu Organisation, Industriestandard, Softwareentwicklung, Tools, Verifizierungsergebnissen und Zertifizierung.

Softwareentwicklungsprozess, Abschnitt 5

Der Softwareentwicklungsprozess wird wie im Softwareplanungsprozess und im Softwareentwicklungsplan definiert angewendet. Unabhängig davon, ob Teams oder Organisationen eine Softwareentwicklungsmethode wie DevOps, Spiral, Waterfall oder eine andere wählen, müssen die folgenden vier aufgeführten Prozesse ausgeführt werden.

1. Softwareanforderungsprozess
2. Software-Design-Prozess
3. Software-Codierungsprozess
4. Integrationsprozess

Der Prozess der Softwareanforderungen beginnt mit der Erfassung aller Anforderungen von Stakeholdern, Aufsichtsbehörden, Standards usw. Diese Anforderungen werden in Domänen wie Hardware, Software, Mechanik, Chemie, Elektrik usw. organisiert und werden dann zu Ihren Anforderungen auf Systemebene.

Anforderungen auf hoher Ebene werden aus Systemanforderungen auf oberster Ebene abgeleitet. Sie zerlegen eine Systemanforderung in verschiedene funktionale und nicht funktionale Anforderungen auf hoher Ebene. Diese Phase der Anforderungszerlegung hilft bei der architektonischen Gestaltung des zu entwickelnden Systems.

Anforderungen auf hoher Ebene klären und helfen, das erwartete Verhalten sowie Sicherheitstoleranzen, Sicherheitserwartungen, Zuverlässigkeit, Leistung, Portabilität, Verfügbarkeit, Skalierbarkeit und mehr zu definieren. Jede Anforderung auf hoher Ebene ist mit der Systemanforderung verknüpft, die sie erfüllt. Darüber hinaus werden Testfälle auf hoher Ebene erstellt und mit jeder Anforderung auf hoher Ebene verknüpft, um sie zu verifizieren und zu validieren. Dies ist Teil des Software-Designprozesses, da jede Anforderung auf hoher Ebene weiter in Anforderungen auf niedriger Ebene zerlegt wird.

Low-Level-Anforderungen sind Softwareanforderungen, die aus High-Level-Anforderungen abgeleitet werden. Sie zerlegen und verfeinern die Spezifikationen des Verhaltens und der Servicequalität der Software weiter. Sie gehen auf eine andere Abstraktionsebene und ordnen sie einzelnen Softwareeinheiten zu. Der Codierungsprozess beginnt mit dem Schreiben von Codeeinheiten, um die detaillierte Gestaltung und Implementierung der Software zu erleichtern. Die Eingaben für den Codierungsprozess sind die Low-Level-Anforderungen und die Softwarearchitektur aus dem Software-Designprozess, dem Software-Entwicklungsplan und den Software-Codestandards.

Nachdem der Kodierungsprozess abgeschlossen ist, besteht der Integrationsprozess aus Folgendem:

Codierungsfehler müssen identifiziert und behoben werden. Unzureichende oder falsche Eingaben, die während des Integrationsprozesses erkannt werden, sollten den folgenden Softwareprozessen als Feedback zur Klärung oder Korrektur zur Verfügung gestellt werden:

• Voraussetzungen:
• Design
• Programmierung
• Planung

Eine bidirektionale Rückverfolgbarkeit, die von jeder Anforderung auf niedriger Ebene bis zu ihrer Anforderung auf höherer Ebene und bis zu den Tests auf niedriger Ebene oder Unit-Testfällen, die sie verifizieren und validieren, hergestellt wird, hilft bei diesem Unterfangen.

Stufe D

Rückverfolgbarkeit ist für DO-178C von entscheidender Bedeutung. Die Tiefe der Rückverfolgbarkeit variiert je nach Softwareebene. Bei der Rückverfolgbarkeit, die für DO-178C Level D erforderlich ist, müssen sich Organisationen nicht darum kümmern, wie die Software entwickelt wurde. Daher ist keine Rückverfolgbarkeit bis hin zu den Anforderungen auf niedriger Ebene, dem Quellcode oder der Softwarearchitektur erforderlich. Die Teams müssen lediglich von den Systemsoftwareanforderungen zu den Anforderungen auf hoher Ebene und dann zu den Testfällen, Testverfahren und Testergebnissen zurückverfolgen.

Stufe C und B

Für die Ebenen B und C ist es wichtig, wie der Quellcode entwickelt wurde. Die Teams müssen die Nachvollziehbarkeit erweitern, indem sie bidirektionale Links von den Anforderungen auf hoher Ebene zu den Anforderungen auf niedriger Ebene und zum Quellcode hinzufügen.

Level A

Bei Projekten der Stufe A müssen die Anforderungen die Rückverfolgbarkeit nicht nur bis zum Quellcode, sondern bis zum Assembler-/Objektcode ausdehnen. Dies liegt daran, dass Compiler höhere Programmiersprachen bekanntermaßen in Assemblercode umwandeln und übersetzen, der nicht auf den ursprünglichen Code zurückgeführt werden kann.

Parasoft bietet eine Assembler-Codeabdeckungslösung namens ASMTools an, die die Codeabdeckung auf Assemblersprachenebene automatisiert. Die Automatisierung dieses Vorgangs verringert den Arbeitsaufwand erheblich, wenn eine Codeabdeckung auf Assemblerebene erforderlich ist.

Zur Rückverfolgbarkeit der Anforderungen automatisiert Parasoft bei Bedarf die Verknüpfung zwischen Anforderungen, Testfällen und bis zur Quelldatei. Integrationen mit ALM-Tools wie Jama, Codebeamer und Polarion unterstützen diese bidirektionale Rückverfolgbarkeit und den Aufbau einer Rückverfolgbarkeitsmatrix für Verifizierungsanforderungen.

Software-Verifizierungsprozess, Abschnitt 6

Der Zweck des Softwareverifizierungsprozesses besteht darin, Fehler zu erkennen, zu melden und zu beheben, die während des Softwareentwicklungsprozesses aufgetreten sein können. Der Standard verwendet den Begriff „Verifizierung“ anstelle von „Test“, da Tests allein nicht die Abwesenheit von Fehlern nachweisen können. Die Verifizierung ist eine Kombination aus Überprüfungen, Analysen, Testfällen und Testverfahren.

Tests stellen die interne Konsistenz und Vollständigkeit der Anforderungen sicher, während Testausführungen einen Nachweis der Konformität mit den Anforderungen liefern.

DO-178C-Softwareverifizierungsprozess ermöglicht Folgendes:

• Die einer Software zugewiesenen Systemanforderungen müssen in übergeordnete Anforderungen zerlegt werden, die die Systemanforderungen erfüllen.
• Aus den High-Level-Anforderungen soll eine Softwarearchitektur entwickelt werden, aus den Low-Level-Anforderungen sollen die High-Level-Anforderungen erfüllt werden.
• Wenn eine oder mehrere Ebenen von Softwareanforderungen in Anforderungen auf hoher und niedriger Ebene zerlegt werden, erfüllt jede sukzessive niedrigere Ebene ihre Anforderungen auf höherer Ebene. Wenn Code direkt aus Anforderungen auf hoher Ebene generiert wird, gilt dies nicht.
• Die Softwarearchitektur und die Low-Level-Anforderungen sollen in Quellcode umgesetzt werden, der die Low-Level-Anforderungen und die Softwarearchitektur erfüllt.
• Der ausführbare Objektcode muss die Softwareanforderungen erfüllen und Vertrauen in die Erfüllung der beabsichtigten Funktionalität vermitteln.
• Der ausführbare Objektcode muss robust sein und korrekt auf abnormale Eingaben und Bedingungen reagieren.
  Die zur Durchführung der Überprüfung verwendeten Mittel müssen für jede ermittelte Softwareebene technisch korrekt und vollständig sein.
• Die zur Durchführung der Überprüfung verwendeten Mittel müssen für jede ermittelte Softwareebene technisch korrekt und vollständig sein.

Durch Softwaretests wird nachgewiesen oder „bestätigt“, dass die Software die Anforderungen erfüllt, und es wird mit hoher Sicherheit nachgewiesen, dass Fehler, die zu inakzeptablen Fehlerzuständen führen könnten, wie sie durch den Prozess der Systemsicherheitsbewertung festgestellt wurden, beseitigt wurden. Das folgende Diagramm zeigt Softwaretestaktivitäten mit Unterabschnitten.

Um jede Testaktivität detaillierter darzustellen, enthält der Standard eine Reihe von Tabellen mit klar definierten Zielen und Ergebnissen oder Artefakten, die zum Nachweis der Konformität erforderlich sind. Diese Ziele werden durch Softwaretests erreicht und können Folgendes umfassen:

• Durchführen einer statischen Analyse
• Unit-Test
• Integrationstests
• Systemtests
• Zielgerichtete Hardware
• Daten- und Steuerungskopplung
• Strukturelle Codeabdeckung (Anweisung, Zweig, MC/DC, Assembly)

Die Integration von Hardware und Software ist für die Gewährleistung von Sicherheit und Zuverlässigkeit von entscheidender Bedeutung.

Beachten Sie, dass alle diese Testmethoden durch die Tool-Suite von Parasoft automatisiert werden. Sie können einen Einblick in unsere C/C++-Lösung erhalten, indem Sie Tour durch den Parasoft C/C++-Test.

In den folgenden Tabellen sind die Ziele und erwarteten Ergebnisse basierend auf den einzelnen Software-Design-Sicherungsstufen aufgeführt, um die Flugtauglichkeit sicherzustellen.

Softwarekonfigurationsmanagementprozess, Abschnitt 7

Abschnitt 7 behandelt die Ziele und Aktivitäten des Softwarekonfigurationsmanagementprozesses. Sie müssen in der Lage sein, Konfigurationen der Software während des gesamten Softwarelebenszyklus zu definieren und zu steuern. Organisationen oder Teams müssen über Quell-Baselines, Versionierung, Änderungskontrolle, Änderungsüberprüfung, Schutz vor nicht autorisierten Änderungen, Problemberichterstattung und vieles mehr verfügen.

Dies sind die Aktivitäten des Softwarekonfigurationsmanagementprozesses:

1. Konfigurationsidentifikation
2. Baselines und Rückverfolgbarkeit
3. Problemberichterstattung, -verfolgung und Korrekturmaßnahmen
4. Kontrolle ändern
5. Überprüfung ändern
6. Konfigurationsstatusabrechnung
7. Archivieren, Abrufen und Freigeben

Diese Aktivitäten werden als Ziele und deren Ergebnisse weiter detailliert. Zu den Zielen gehören die Fähigkeit, Änderungen an Artikelmerkmalen zu kontrollieren, die Verarbeitung der Änderungskontrolle und den Implementierungsstatus aufzuzeichnen und zu melden.

Beachten Sie in Tabelle A-8 die Spalte „Kontrollkategorie nach Softwareebene“. DO-178C gibt an, welche Elemente basierend auf dem DAL des Projekts als Kontrollkategorie 1 oder 2 behandelt werden müssen. Elemente, die als Kontrollkategorie 1 (CC1) behandelt werden, müssen vollständige Problemberichtsprozesse, formelle Änderungsprüfungen und Freigabeprozesse durchlaufen. CC2-Elemente müssen diese formelleren Prozesse nicht durchlaufen, müssen aber dennoch den Anforderungen an Konfigurationsidentifizierung und Rückverfolgbarkeit entsprechen, vor unbefugten Änderungen geschützt sein und die geltenden Anforderungen an die Datenaufbewahrung erfüllen. Die Zuordnung zwischen CC1- und CC2-Daten finden Sie in der folgenden Tabelle.

Software-Qualitätssicherungsprozess, Abschnitt 8

Der SQA-Prozess wird im Software-Qualitätssicherungsplan festgehalten, der während des Softwareplanungsprozesses erstellt wird. Die Ergebnisse der SQA-Prozessaktivitäten müssen aufgezeichnet, ausgewertet und verfolgt werden. Es müssen Audits durchgeführt und etwaige Abweichungen von den Standards behoben werden. Der Prozess beinhaltet die Gewährleistung, dass:

• Softwarepläne und -standards werden entwickelt, überprüft und erfüllen die Anforderungen.
• Artefakte, Berichte und Beweise liegen mit Genehmigungen vor.
• Die Daten zu Softwareprodukten und Softwarelebenszyklen entsprechen den Zertifizierungsanforderungen.

Zertifizierungsverbindungsprozess, Abschnitt 9

In Abschnitt 9 werden der Zertifizierungsverbindungsprozess und seine Ziele erörtert. Zu diesen zählen unter anderem:

• Stellen Sie während des gesamten Software-Lebenszyklus eine Kommunikation und ein Verständnis zwischen dem Antragsteller und der Zertifizierungsstelle her, um den Zertifizierungsprozess zu unterstützen.
• Erzielen Sie eine Einigung über die Mittel zur Einhaltung der Vorschriften, indem Sie den Plan für Softwareaspekte der Zertifizierung genehmigen.
• Legen Sie einen Nachweis für die Einhaltung der Vorschriften vor.

Ihre Organisation muss den Plan für Softwareaspekte der Zertifizierung (PSAC) erstellen, der den Zertifizierungsverbindungsprozess enthält. Der PSAC enthält Pläne zur Lösung der vom Zertifizierungsverbindungsbeauftragten identifizierten Probleme und zur Erlangung einer Zustimmung zu dem Plan. In der folgenden Tabelle sind die Ziele und die erwarteten Ausgabeartefakte aufgeführt.

Die bewährten Vorgehensweisen zum Erhalt einer Zertifizierung laufen darauf hinaus, eng mit Ihrem Zertifizierungsbeauftragten zusammenzuarbeiten, der möglicherweise besser als Ihr Designated Engineering Representative (DER) bekannt ist. Dieser prüft die Einhaltung der Vorschriften, vertritt in Ihrem Namen die Interessen der Genehmigung und empfiehlt der FAA die Genehmigung Ihrer Zertifizierung.

Übersicht über den Zertifizierungsprozess, Abschnitt 10

Abschnitt 10 dient ausschließlich zu Informationszwecken im Zusammenhang mit dem Zertifizierungsprozess.

Darin werden die Arten von Systemen und Geräten aufgeführt, für die die Zertifizierung gilt. Es wird darauf hingewiesen, dass Zertifizierungsstellen Software nicht als eigenständiges Produkt zertifizieren. Sie muss Teil des Bordsystems oder -geräts sein.

„Die Zertifizierung bezieht sich auf Flugzeuge, Motoren oder Propeller und, im Hinblick auf einige Zertifizierungsstellen, auf Hilfstriebwerke. Die Zertifizierungsstellen betrachten die Software als Teil des Bordsystems oder der Ausrüstung, die auf dem zertifizierten Produkt installiert ist; das heißt, die Zertifizierungsstellen zertifizieren die Software nicht als einzigartiges, eigenständiges Produkt.“

Die Zulassung hängt auch von einer erfolgreichen Vorführung oder Überprüfung der hergestellten Produkte ab.

Software-Lebenszyklusdaten, Abschnitt 11

Abschnitt 11 befasst sich mit Artefakten wie den Daten und der Dokumentation, die während des Software-Lebenszyklus erstellt werden. Die Daten müssen eindeutig, vollständig, überprüfbar, konsistent, veränderbar und nachvollziehbar sein. Sie müssen außerdem in verschiedenen Formen vorliegen, beispielsweise elektronisch und gedruckt. Die automatische Berichterstellung und das Analyse-Web-Dashboard von Parasoft bieten viele der in verschiedenen Artefakten und Dokumenten benötigten Informationen.

Zu den Artefakten, die während des Software-Lebenszyklus erstellt werden, gehören der Quellcode, der Objektcode, Testfälle, Ergebnisse, Problemberichte und natürlich die Pläne. Hier ist die vollständige Liste.

• Planen Sie die Softwareaspekte der Zertifizierung
• Ausführbarer Objektcode
• Software-Entwicklungsplan
• Fälle und Verfahren zur Softwareverifizierung
• Software-Verifizierungsplan
• Ergebnisse der Softwareüberprüfung
• Softwarekonfigurationsmanagementplan
• Konfigurationsindex für die Software-Lebenszyklusumgebung
• Software-Qualitätssicherungsplan
• Standards für Softwareanforderungen
• Softwarekonfigurationsindex
• Standards für Softwaredesign
• Problemberichte
• Softwarecode-Standards
• Aufzeichnungen zur Softwarekonfigurationsverwaltung
• Daten zu Softwareanforderungen
• Aufzeichnungen zur Softwarequalitätssicherung
• Designbeschreibung
• Zusammenfassung der Softwareleistungen
• Quellcode
• Trace-Daten
• Parameterdatenelementdatei

Weitere Überlegungen, Abschnitt 12

Abschnitt 12 enthält zusätzliche Anleitungen und Überlegungen zu Themen, die Auswirkungen auf Ziele und Aktivitäten im Software-Lebenszyklus haben können. Beispielsweise die Verwendung oder Änderung zuvor entwickelter Software. Abschnitt 12 enthält zusätzliche Erläuterungen und durchzuführende Aktivitäten, die zur Gewährleistung der Sicherheit und erneuten Zertifizierung beitragen. Hier sind nur einige weitere Überlegungen:

Basierend auf diesen Überlegungen bietet Abschnitt 12 zusätzliche Ziele im Softwarekonfigurationsmanagement, der Softwarequalitätssicherung, der Qualifizierung von Entwicklungstools und mehr.

Abschnitt 12 behandelt die Bedeutung der „Tool-Qualifizierung“ und die Feststellung, ob diese erforderlich ist. Denn wenn ein Tool verwendet wird, das Prozesse eliminiert, reduziert oder automatisiert, müssen die Teams berücksichtigen, ob das Tool Fehler in den Lebenszyklus einbringen könnte.

Um die Wirkung des Tools zu bestimmen, sollten folgende Kriterien verwendet werden:

Es gibt fünf Stufen der Tool-Qualifizierung, TQL-1 bis TQL-5, die durch die Verwendung des Tools und dessen mögliche Auswirkung auf den Software-Lebenszyklus bestimmt werden. TQL-1 ist die strengste Stufe. Die Tool-Qualifizierungsstufe muss mit der Zertifizierungsstelle abgestimmt werden.

Die für jede Tool-Qualifizierungsstufe erforderlichen Ziele, Aktivitäten, Anleitungen und Lebenszyklusdaten werden in DO-330 „Überlegungen zur Software-Tool-Qualifizierung“ beschrieben.

Parasoft unterstützt DO-178C- und DO-330-konforme Tool-Qualifizierungsprozesse mit einem automatisierten Tool-Qualifizierungskit. Das Tool-Qualifizierungskit automatisiert den Prozess der Erstellung der unterstützenden Dokumentation, die für die Verwendung von C/C++test für statische Analysen, Unittests und Abdeckungsanforderungen erforderlich ist.

Das Tool Qualification Kit von Parasoft reduziert den Zeitaufwand für die Tool-Qualifizierung und das Potenzial für menschliches Versagen, indem die Automatisierung die Benutzer durch den folgenden Arbeitsablauf führt:

1. Geben Sie die Anwendungsfälle und Funktionen an, die im Projekt verwendet werden sollen.
2. Ordnen Sie bekannte Probleme des von Ihnen qualifizierenden Tools schnell den Funktionen des von Ihnen in der Entwicklung verwendeten Tools zu.
3. Planen und erfassen Sie die Ergebnisse manueller Testbemühungen.
4. Führen Sie automatisierte Tests durch.
5. Führen Sie alle Daten zusammen und erstellen Sie die wichtigen Dokumente.