Assembly, Integration and Verification

Assembly, Integration and Verification oder AIV ist ein Verfahren zum Qualitätsmanagement in der Luft- und Raumfahrttechnik. Es beschreibt ein standardisiertes Vorgehen zur Qualifikation von Bauteilen und der anschließenden Integration der Systemkomponenten zum Gesamtsystem. AIV wird vorrangig in der Raumfahrtindustrie angewandt und wurde gleichermaßen von der ESA und NASA mit leicht unterschiedlichen Vorgehensweisen genormt. Es soll sicherstellen, dass ein System beispielsweise ein Satellit sowohl den Transport in den jeweiligen Orbit unbeschadet übersteht, als auch in der vorgesehenen Betriebszeit seine Funktion erfüllt.

Begriffsklärung AIV

AIV steht für Assembly (engl. für Aufbau), Integration (engl. für Einbinden, Integrieren, Vernetzen) and Verification (engl. für gewährleisten, nachprüfen, überprüfen).

Frei übersetzt bedeutet AIV so viel wie Aufbau der Systemstruktur, Integration der Systemkomponenten und Verifizieren der Systemfunktionalität.

Definition AIV

Unter AIV versteht man den systematischen und methodengestützten Prozess der Planung, Vorbereitung und Qualifizierung der Modelle und Verifikationsressourcen zur Qualitätssicherung einer Einzelunternehmung oder Kleinstserie in der Luft- und Raumfahrtindustrie.

Der AIV-Zyklus beginnt bereits früh im Produktlebenszyklus, startet im ESA/NASA Phasenkonzept gegen Ende der Phase A und begleitet das Produkt in der Regel über die gesamte restliche Projektlaufzeit. Das AIV ist im Produktlebenszyklus rein administrativer Natur und beschäftigt sich vor allem mit der Planung und der Beschaffung bzw. das zur Verfügung stellen von benötigten Materialien, Ressourcen und Einrichtungen.

AIV findet Anwendung, wenn ein Versagen einer kritischen Komponente eines Systems zum Gesamtverlust der Investition und/oder katastrophalen Auswirkungen für Mensch bzw. Umwelt führt. Daher werden die Komponenten des Systems durch mindestens ein Standardqualifikationsprogramm – unter der Leitung des AIV – geprüft, bevor sie für die Betriebsphase frei gegeben werden.

Aufgaben des AIV in der Industrie

Die grundlegende Aufgabe der mit dem AIV betrauten Abteilung und verantwortlichen Person ist der Nachweis, dass die Unternehmung/das System zu den jeweiligen Milestones die zugrunde liegenden oder die bis zu diesen Zeitpunkt vereinbarten Spezifikationen und Anforderungen erfüllt, bzw. erfüllen wird.

Hierfür gibt es ein von ESA und NASA festgelegtes standardisierte Vorgehensweise, in der die Aufgaben, Methoden und Vorgehensweisen spezifiziert worden sind.

Hauptaufgaben des AIV

Anlegen der Verifikations-Dokumentation

Dem Standard entsprechend werden verschiedene Dokumente angelegt, um den gesamten Prozess für die Milestones und den Kunden zu dokumentieren. Dies stellt sicher, dass alle erforderlichen Planungsschritte vollzogen werden und macht diese für Dritte sowohl nachvollziehbar als auch überprüfbar. Dies ermöglicht externen Expertenkommissionen in Reviews, die Ergebnisse der jeweiligen Milestones anhand des Vorgehens und der zugrunde liegenden Testspezifikationen zu bewerten und nachzuvollziehen.

Spezifizierte Dokumente

• Verification plan (VP)
• Assembly, integration and test (AIT) plan
• Verification control document (VCD)
• Test specification (TSPE)
• Test procedure (TPRO)
• Test report (TRPT)
• Analysis report (ARPT)
• Review of design report (RRPT)
• Inspection report (IRPT)
• Verification report (VRPT)

Der Inhalt dieser Dokumente ist genormt und kann beispielsweise im ECSS-E-ST-10-02C Annex A–F und ECSS-E-ST-10 – ECSS-E-ST-10-03 nachgelesen werden.

Modellphilopsophie

Durch die Festlegung der Modellphilosophie, durch die mit dem AIV betraute Ressource, wird eindeutig bestimmt, welche Modelle und zu welchem Zeitpunkt dem Anwendungszweck bzw. Testzweck entsprechend benötigt und zur Verfügung gestellt werden müssen. Diese können sowohl virtueller als auch physischer Natur sein. Die Modellphilosophie leitet sich eindeutig aus der Anforderungsspezifikation ab. Wann welche Modelle (virtuell oder breadboard) zur Verfügung stehen sollen, wird im Verifikationsplan festgelegt.

Da moderne Software-Programme in der Regel die Wirklichkeit in ausreichender Genauigkeit widerspiegeln, wird aus Kostengründen mehr und mehr auf physische Modelle zugunsten virtueller oder hybrider Modelle verzichtet.

Standardmodelle

• STM: Structural / Thermal Model
• EQM: Electronic Qualification Model
• EM: Engineering Model
• PFM / FS: Proto-Flight Model / Flight Spare Model
• FM: Flight Model
• GRM: Ground Reference Model

Analysen und Entwurfsbeurteilungen

Die AIV-Ressource muss bereits in frühen Phasen des Projekts Analysen zur Verfügung stellen, um die „Machbarkeit“ eines Projekts nachzuweisen. Neben ersten Simulationen des Arbeitsablaufes, über die der Funktionsnachweis erbracht werden kann, spielen die numerischen Verfahren eine immer größere Rolle in der Planung und Bewertung von Systemkomponenten. Durch immer mächtigere Analyse-Werkzeuge und den Einsatz von Datenbanken, durch die eine schnelle und einfache Vergleichbarkeit aktueller und früherer Projekte bzw. Komponenten (Legacy Systeme) möglich ist, können Kosten gesenkt und Fehlerrisiken minimiert werden. Weiterhin können durch diese Methoden und Werkzeuge die Systemkomplexität besser erfasst und verstanden werden und Daten aus den Analysen und Simulationen gewonnen werden. Das stellt eine kostengünstige Alternative zu realen Experimenten dar.

Bekannte Methoden sind unter anderem

• Ablauf-Simulation
• Thermal-Simulation (z. B. ESATAN)
• FEM/FVM/FDM-Simulation
• CFD-Verfahren
• Mehrkörpersimulation
• 3D-Kinematiksimulation

Ressourcenplanung

Zur Verifikation müssen natürlich auch die entsprechenden Ressourcen geplant, geordert und zu dem entsprechenden Zeitpunkten zur Verfügung stehen.

So müssen zu den geplanten Modellen auch entsprechende Einrichtungen und Fachkräfte bereitgestellt werden. Diese Planung muss eng mit dem tatsächlichen Projektfortschritt koordiniert werden und erfordert daher eine enge Zusammenarbeit des Projektleiters mit der AIV-Ressource. Neben den eigentlichen Testressourcen müssen auch alternative Subsysteme in enger Zusammenarbeit mit der jeweiligen Stelle definiert werden, falls eine Komponente den zugrunde liegenden Anforderungen – die sich im Laufe des Projekts ändern können – nicht genügt oder in den Qualifikationsprogrammen versagt.

Aufgaben in diesem Bereich

• Planung des Personalbedarfs und der Fachkräfte
• Buchen bzw. zu Verfügung stellen von Testeinrichtungen
• Bereitstellen von Computern und Software
• Budgetplanung
• Dynamische Koordination mit dem Projektzeitplan
• Alternative Lieferanten und Komponenten definieren

Literatur

• ECSS Standard: ECSS-E-ST-10-02C, Stand 6. März 2009 der European Cooperation for Space Standardization, online (PDF) auf glast.pi.infn.it (englisch)
• ECSS Standard: ECSS-E-10 Part 1B (18. November 2004)
• ECSS Standard: ECSS-E-10-03A (15. Februar 2002), online (PDF) auf eop-cfi.esa.int (englisch)
• Willi Hallmann, Wilfried Ley: Handbuch Raumfahrttechnik, Hanser, 1999, ISBN 3-446-21035-0
• Ulrich Walter: Systems Engineering, Skript, TU München
• Horst Baier, Frank Schiller, Rudolf Schilling: Modellbildung und Simulation, Skript, TU München
• Richard Maier, Andreas Ehrhardt: SA AIT/AIV im Projekt VECTOR, TU München