Definition
Qualitätsmanagement-Stränge der ECSS-Familie. Wichtigste Untermengen: ECSS-Q-ST-10 (Qualitätssicherung), ECSS-Q-ST-20 (Quality Assurance Programme), ECSS-Q-ST-70 (Material- und Prozessauswahl), ECSS-Q-ST-80 (Software Product Assurance). Verzahnt sich nahtlos mit ECSS-E (Engineering) und ECSS-M (Management). Pflichtanwendung bei ESA-Projekten, oft Vertragsbestandteil bei Subunternehmen.
In der Praxis
Im ECSS-Q-Strang sehe ich zwei wiederkehrende Fehler. Der erste betrifft die Software Product Assurance nach ECSS-Q-ST-80: Sie wird als lästiges Beiwerk zur Entwicklung behandelt — der Entwicklungsleiter „macht das nebenbei" —, dabei ist sie als eigenständige Assurance-Funktion gedacht, die dem Entwicklungsprozess unabhängig auf die Finger schaut: Anforderungsqualität, Prozesseinhaltung, Verifikationsnachweise, Auslieferungszustand. Wer diese Unabhängigkeit nicht organisiert, hat das Konzept nicht umgesetzt, egal wie dick die Dokumentation ist. Der zweite Fehler betrifft die Material- und Prozessauswahl nach ECSS-Q-ST-70: In der Raumfahrt ist nicht jedes qualifizierte Industriematerial einsetzbar — Ausgasung, Strahlenfestigkeit und Langzeitverhalten im Vakuum sind eigene Prüfdisziplinen, und die verbotenen beziehungsweise zulässigen Werkstoffe sind nachzuweisen. Mein Rat: Behandeln Sie die Q-Standards nicht als Qualitätsbürokratie, sondern als das, was sie sind — die kondensierte Unfallgeschichte der europäischen Raumfahrt. Und verzahnen Sie die Q-Anforderungen früh mit Engineering und Management, denn im ECSS-Geflecht greifen die Stränge ineinander.
Häufige Fragen zu ECSS-Q-ST
Wie hängen ECSS-Q-ST-80 und DO-178C zusammen — brauchen wir beides?
Die beiden Dokumente kommen aus verschiedenen Domänen und sind keine Alternativen. DO-178C ist der Software-Standard der zivilen Luftfahrt: Er definiert den Entwicklungs- und Verifikationsprozess für Bordsoftware, gestaffelt nach Development Assurance Levels, und dient der behördlichen Zulassung durch EASA oder FAA. ECSS-Q-ST-80 ist die Software Product Assurance der europäischen Raumfahrt: Sie definiert die unabhängige Qualitätssicherungsfunktion über den Software-Lebenszyklus — Prozessüberwachung, Produktbewertung, Nachweisführung — und wird vertraglich in ESA-Projekten eingefordert. Ein Raumfahrt-Zulieferer arbeitet nach Q-ST-80, ein Avionik-Entwickler nach DO-178C; beides gleichzeitig kommt nur in Überschneidungsprojekten vor, etwa bei luftfahrtnahen Raumfahrtanwendungen. Die Denkweise ist verwandt — Prozessdisziplin, Rückverfolgbarkeit, Unabhängigkeit —, die Nachweislogik ist jeweils eine eigene.
Welche ECSS-Q-Standards sind für uns als Zulieferer typischerweise vertraglich relevant?
In der Praxis treffen Sie regelmäßig auf vier Stränge. ECSS-Q-ST-10 bildet das Rückgrat der Produktsicherung: Anforderungen an die QS-Organisation, Nichtkonformitätsmanagement, Nachweise und den Umgang mit Abweichungen — quasi die Pflichtlektüre für jeden Qualitätsverantwortlichen im Raumfahrtprojekt. ECSS-Q-ST-20 konkretisiert die Qualitätssicherungs-Programme auf Projektebene. ECSS-Q-ST-70 betrifft Materialien, mechanische Teile und Prozesse — relevant, sobald Sie physische Hardware liefern, von der Werkstoffauswahl bis zu Prozessqualifikationen. Und ECSS-Q-ST-80 ist die Software Product Assurance, sobald Ihr Arbeitspaket Software enthält. Welche davon in welchem Umfang gelten, ergibt sich aus der vertraglichen Anforderungsliste samt Tailoring — pauschal ist das nie zu beantworten. Prüfen Sie deshalb jedes Angebot auf die konkret referenzierten Dokumente, bevor Sie den Aufwand kalkulieren.
Wie organisieren wir die Software Product Assurance nach Q-ST-80, ohne ein eigenes Großteam aufzubauen?
Das Kernprinzip ist die Unabhängigkeit der Assurance-Funktion von der Entwicklung — nicht die Größe des Teams. In einem Mittelständler kann das eine einzelne Person sein, die organisatorisch nicht dem Entwicklungsleiter unterstellt ist und direkten Berichtsweg zur Qualitätsleitung oder Geschäftsführung hat. Diese Funktion prüft zu definierten Punkten des Lebenszyklus: Sind die Anforderungen vollständig und konsistent, werden die festgelegten Prozesse eingehalten, sind die Verifikationsnachweise schlüssig, ist der Auslieferungszustand kontrolliert? Wichtig ist, dass die Assurance nicht erst am Ende testet, sondern den Prozess von Anfang an begleitet — nachträgliche Qualitätssicherung findet nur noch Fehler, die teuer zu beheben sind. Nutzen Sie bestehende Strukturen Ihres EN-9100-Systems: Interne Audits, Konfigurationsmanagement und Nichtkonformitätsprozess lassen sich auf die Q-ST-80-Anforderungen mappen, statt parallele Welten zu bauen. Dokumentieren Sie die Rollenzuordnung — im ESA-Review wird genau danach gefragt.