Definition
Komplementärer Standard zu DO-178C — für komplexe elektronische Hardware in der zivilen Luftfahrt (FPGAs, ASICs, programmierbare Logikbausteine). Strukturiert den Entwicklungsprozess in fünf Phasen (Planung, Anforderungen, konzeptionelles Design, detailliertes Design, Implementierung) mit DAL-A-bis-E-Objektiven analog zur Software-Seite. Pflicht bei Hardware-Komponenten, die zur Sicherheitsfunktion eines Flugzeugs beitragen.
In der Praxis
DO-254 wird in der Praxis gern unterschätzt, weil „Hardware" für viele Entwickler nach Leiterplatte klingt — dabei geht es um komplexe elektronische Hardware: FPGAs, ASICs, programmierbare Logik, deren Verhalten im Design definiert wird und deshalb wie Software behandelt werden muss. Der häufigste Fehler: COTS-IP-Cores und gekaufte FPGA-Blöcke werden als „ist ja nur gekaufte Logik" abgehakt, bis im Zulassungsgespräch klar wird, dass auch sie Design Assurance brauchen — dann fehlen Anforderungen, Verifikationsnachweise und Konfigurationsstände. Zweiter Dauerbrenner: Hardware- und Software-Teams entwickeln an derselben Funktion, ohne ihre Assurance-Level abzustimmen. Eine DAL-A-Funktion mit DO-178C-konformer Software auf einem FPGA, der faktisch ohne DO-254-Prozess entstanden ist, ist ein Zertifizierungsrisiko. Mein Rat: Behandeln Sie komplexe Logik mit derselben Lebenszyklus-Disziplin wie Software — Anforderungen, konzeptionelles Design, detailliertes Design, Implementierung, Verifikation — und stimmen Sie die DAL-Zuordnung funktionsübergreifend ab, bevor die Architektur steht.
Häufige Fragen zu DO-254
Wo liegt der Unterschied zwischen DO-254 und DO-178C?
DO-178C regelt den Lebenszyklus von Software, DO-254 den von komplexer elektronischer Hardware — also FPGAs, ASICs und programmierbaren Logikbausteinen, deren Funktion durch Design entsteht statt durch klassische Fertigung. Beide Standards teilen dieselbe Logik: fünf Development Assurance Levels, gestaffelte Ziele für Entwicklung und Verifikation, Konfigurationsmanagement und Nachweisführung gegenüber der Behörde. Der Grund für zwei Dokumente ist historisch und technisch: Hardware-Design folgt anderen Phasen und Methoden als Software-Entwicklung, etwa Synthese, Place-and-Route und Timing-Analyse. Einfache, deterministisch prüfbare Hardware fällt nicht unter DO-254 — die Komplexität ist das Kriterium. In der Praxis treffen beide Standards an jeder Schnittstelle zwischen Logik und Code aufeinander, weshalb ihre Prozesse abgestimmt gehören.
Gilt DO-254 auch für gekaufte FPGA-IP-Cores und COTS-Komponenten?
Grundsätzlich ja, sobald die Komponente zu einer Funktion mit Sicherheitsrelevanz beiträgt — der Einkauf entbindet nicht von der Design Assurance. Für komplexe elektronische Hardware, die in zertifizierte Luftfahrzeuge eingebaut wird, erwarten EASA und FAA den DO-254-Prozess als anerkanntes Mittel der Konformitätsdarstellung. Bei COTS-IP-Cores liegt die Krux im Detail: Sie haben keinen Einblick in den Entwicklungsprozess des Anbieters, also müssen Sie die Assurance anders erbringen — etwa über zusätzliche Verifikation, Architekturmaßnahmen oder dokumentierte Betriebserfahrung, je nach DAL und Zulassungskontext. Das frühzeitig mit der Behörde oder dem DOA-Kunden abzustimmen, ist Pflichtprogramm. „Gekauft, also nicht unser Problem" ist die teuerste falsche Annahme in diesem Umfeld.
Wie stimmen wir Hardware- und Software-Assurance in einem gemeinsamen Projekt sauber ab?
Beginnen Sie auf Systemebene: Die Safety Assessment nach ARP 4761 und der Systementwicklungsprozess nach ARP 4754A ordnen jeder Funktion ihren DAL zu — erst dann wird entschieden, welcher Teil in Hardware und welcher in Software realisiert wird. Diese Zuordnung gehört in ein gemeinsames Planungsdokument, damit beide Seiten mit denselben Assurance-Zielen arbeiten. Richten Sie eine funktionsübergreifende Konfigurationssteuerung ein: Schnittstellen zwischen FPGA und Software sind der klassische Ort, an dem Änderungen einer Seite die Nachweise der anderen kippen. Planen Sie gemeinsame Verifikations-Reviews, bei denen Hardware- und Software-Ergebnisse zusammen betrachtet werden. Und dokumentieren Sie die Abstimmung — im Audit zählt nicht, dass die Teams gesprochen haben, sondern dass die Abstimmung nachweisbar ist.