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 unbeschädigt ü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 oder dem Zurverfügungstellen 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 freigegeben 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 diesem Zeitpunkt vereinbarten Spezifikationen und Anforderungen erfüllt, bzw. erfüllen wird.

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 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.

Modellphilosophie

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 Computerprogramme 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 auf System- und Geräteebene
  • EQM: Engineering Qualification Model auf Geräteebene (identisch zu FM aber elektronische Bauteile nicht nach EEE-Standard)
  • EM: Engineering Model auf 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 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

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
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.