„Assembly, Integration and Verification“ – Versionsunterschied

Assembly, Integration and Verification oder AIV beinhaltet alle Tätigkeiten, die zum Nachweis der Erfüllung aller Anforderungen der zu liefernden Produkte gegenüber dem Auftraggeber notwendig sind. Es umfasst formelle Verfahren, die in der Luft- und Raumfahrttechnik von jedem Auftragnehmer vertraglich gefordert werden. Die standardisierte Qualifikation und Abnahme wird auf allen Ebenen vom Bauteilen bis zum Gesamtsystem durchgeführt. Die Methodik wurde gleichermaßen von der ESA und NASA mit leicht unterschiedlichen Vorgehensweisen und Dokumententypen genormt. Es soll sicherstellen, dass ein System, beispielsweise ein Satellit, sowohl den Transport in den jeweiligen Orbit unbeschädigt übersteht, während der spezifizierten Betriebszeit seine Funktion erfüllt und schließlich entsorgt werden kann.

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 Ausführung der AIV-Aktivitäten. Die Verifikationstätigkeiten, die in den Spezifikationen definiert sind, werden nach formell akzeptierten Prozeduren mit eindeutigen Kriterien durch die verschiedenen Disziplinen Systemsengineering, AIT (Assembly, Integration und Test), QA (Quality assurance) und Operations durchgeführt und erbringen den Nachweis, dass die Spezifikationsparameter erfüllt werden. Die AIV-Organisation verwaltet alle Verifikations-Anforderungen und -Dokumente in einer Datenbank, die jederzeit den Status zeigt und die Basis für das COQ (Certificate of Qualification) bzw. COA (Certificate of Acceptance) darstellt.

Dieser Vorgang wird durch korrespondierende AIV Organisationseinheiten in gleicher Weise von der Geräte- bis System-Ebene durchgeführt, wobei jeweils die höhere Ebene die Ergebnisse der unteren Ebene überprüft und formell als Vertragserfüllung akzeptiert.

Der AIV-Zyklus beginnt bereits früh im Produktlebenszyklus zusammen mit der Erstellung der Spezifikationen, startet im ESA/NASA Phasenkonzept gegen Ende der Phase A und begleitet das Produkt bis zur Ablieferung.

Aufgaben des AIV in der Industrie

Die grundlegende Aufgabe der mit dem AIV betrauten Abteilung ist die Kontrolle und Dokumentation, dass das geplante Verifikationsergebnis für das Gerät/das System zu den jeweiligen Milestones vorliegt.

Bei Raumfahrtprojekten muss ein hoher Aufwand in die Verifikation gesteckt werden. Um die Vorgehensweise nicht für jedes Projekt neu festlegen zu müssen, gibt es eine von ESA und NASA festgelegte standardisierte Vorgehensweise für die Verifizierung, in der die Aufgaben, Methoden und Vorgehensweisen spezifiziert worden sind.

Hauptaufgaben des AIV

Anlegen der Verifikationsdokumentation

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 dem Auftraggeber-VCB (Verification-Control-Board) in Reviews, die Ergebnisse der jeweiligen Milestones zu überprüfen bzw. formell zu akzeptieren.

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.

Modellphilosophie

Bei der Festlegung der Testphilosophie bestimmt verantwortliche Organisationseinheit, welche Modelle und zu welchem Zeitpunkt dem Anwendungszweck benötigt und zur Verfügung gestellt werden müssen. Diese können sowohl virtueller als auch physischer Natur sein. Die Modellphilosophie leitet sich aus der Anforderungsspezifikation ab. Wann welche Modelle (virtuell oder breadboard oder EM) zur Verfügung stehen sollen, wird im Verifikationsplan festgelegt.

Da einige Tests nur mit hohem Aufwand ausgeführt werden können bzw. wegen nur im Orbit vorhandener Bedingungen am Boden nicht möglich sind, werden bestimmte Verifikations-Ergebnisse durch Computerprogramme erstellt; dabei muss das zu verifizierende Produkt in adäquater Genauigkeit modelliert werden.

Es wurde versucht auch on-orbit Tätigkeiten wie z. B. Ein-/Ausbau von Geräten im Columbus-Modul durch Computersimulation zu verifizieren; die Ergebnisse waren nicht überzeugend, sodass nur Untersuchungen im Neutral-Buoyancy-Becken akzeptable Ergebnisse lieferten.

Standardmodelle

• STM: Structural / Thermal Model auf System- und Geräteebene
• EQM: Engineering Qualification Model auf Gerätebene (identisch zu FM aber elektronische Bauteile nicht nach EEE-Standard)
• EM: Engineering Model auf Geräte und Systemebene (identisch zu FM – form, fit, function – aber reduzierter Qualitätsstandard / keine EEE-Bauteile)
• PFM: Proto-Flight Model auf System- und Geräteebene (Nach Benutzung für Qualification wird es als FM eingesetzt)
• QM: Qualification Model (identisch zu FM)
• FM: Flight Model

Analysen und Entwurfsbeurteilungen

Die verantwortliche 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

• planen des Personalbedarfs und der Fachkräfte
• buchen bzw. zur Verfügung stellen von Testeinrichtungen
• bereitstellen von Computern und Software
• Budgetplanung
• dynamische Koordination mit dem Projektzeitplan
• alternative Lieferanten und Komponenten definieren

Literatur

• Veralteter ECSS-Standard: ECSS-E-ST-10-02C, Stand 6. März 2009 der European Cooperation for Space Standardization, online (PDF; 514 kB) auf glast.pi.infn.it (englisch)
• Veralteter ECSS-Standard: ECSS-E-10 Part 1B (18. November 2004) online auf cesames.net (englisch)
• Veralteter 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