Collins Aerospace spart Zeit, Kosten und Arbeitsaufwand durch die Entwicklung einer einheitlichen Testarchitektur für elektromechanische Systeme

Collins Aerospace gehört zu den weltweit größten Anbietern hochentwickelter Luft- und Raumfahrtprodukte mit etwa 42.000 Mitarbeitern und erwirtschaftet Jahresumsätze von mehr als 14 Milliarden US-Dollar. Der Geschäftsbereich Actuation Systems entwickelt und fertigt Hochauftriebssysteme für Geschäftsreise-, Verkehrs- und Militärflugzeuge.  

Testanforderungen für die Luft- und Raumfahrt

Line Replaceable Units (LRUs), Komponenten und Controller in der Luft- und Raumfahrt müssen strengen Tests unterzogen werden. Unternehmen wie Collins Aerospace testen deshalb eine Vielzahl an Konfigurationen und Ausführungen einer Komponente für zahlreiche OEM-Luftfahrzeugprogramme, ob für Geschäftsreise-, Verkehrs- oder Militärflugzeuge. Collins Aerospace entwickelt zahlreiche Komponenten für Flugzeugsysteme. Die Actuation-Gruppe entwirft Systeme, die Steuerbefehle für das Cockpit in Bewegungen aller steuerbaren Vorflügel und Landeklappen übertragen. Diese Systeme bestehen aus SFECUs (Slat and Flap Electronic Control Units), zentralen PDUs (Power Drive Units) und Elementen für die Kraftübertragung, wie z. B. Torsionsrohre und Getriebe. Alle Systembausteine müssen einzeln und im Zusammenspiel auf System- und auf Flugzeugebene getestet werden.

Die Herausforderungen eines herkömmlichen Testansatzes

Die Entwurfs- und Testverfahren sind für alle Komponenten relativ ähnlich. Wir Mitarbeiter im Actuation-Bereich bedienen jedoch viele Prüfstände für unterschiedliche LRU-Tests, u. a. während der Entwicklung, Qualifizierung, Produktion und Reparatur. Zudem arbeiten wir bei großen Prüfsystemen (sowohl für den internen Gebrauch als auch für Kunden) mit hydraulischer Belastung, die zeit- und kostenaufwendig rekonfiguriert werden muss. Durch das erneute Erstellen von Architekturen und Verfahren zur Durchführung verschiedener Tests während des Produktentwicklungszyklus ging Zeit verloren.

Bei bestehenden Prüfständen wird für mechanische LRU-Tests z. B. hydraulische Belastung eingesetzt. Die Umrüstarbeiten für Tests waren häufig sehr ähnlich. Für Hydrauliksysteme mussten bei jeder Neukonfiguration der Teststation die Installation und die Verdrahtung geändert werden. Selbst für die Elektroniktests waren die Prüfstände mit im Flugzeug eingesetzter Hardware auszustatten, wodurch die Prüfsysteme unflexibel wurden. Nur wenige Tests waren automatisiert und der Support für verschiedene Konfigurationen begrenzt. Der herkömmliche Testansatz war kostspielig und zeitaufwendig. Unsere Gruppe sah sich einem engen Zeitplan sowie eingeschränkten Ressourcen gegenüber, die es nicht erlaubten, die fragmentierte bestehende Architektur entsprechend den wachsenden Anforderungen schnell genug zu modifizieren. Zudem benötigte Collins Aerospace noch einen Wettbewerbsvorteil gegenüber anderen Anbietern, damit Kosten- und Zeitaufwand für künftige Programme reduziert werden konnten. Somit sprach alles für die Entwicklung einer neuen Testarchitektur.

Die Vorteile einer einheitlichen Prüfplattform für die gesamte Entwicklung

Die Vorarbeiten und Investitionen in die neue D3-Architektur (verteilt, deterministisch und dynamisch) werden sich in einigen Jahren bezahlt machen. Wir sahen großes Potenzial darin, Tests durch Standardisierung auf eine einheitliche Testarchitektur für alle Komponententests zu optimieren. Die folgenden Tests wurden mit der D3-Architektur implementiert: Model in the Loop (MIL), Software in the Loop (SIL) und Hardware in the Loop (HIL), außerdem Validierungs- und Verifizierungstests (V&V) für die Hard- und Software (Fehlersimulation), Lebensdauertests, Tests im Systemintegrationslabor (Iron Bird), Systemintegrationstests auf Flugzeugebene, Hochauftriebssystemprüfstand einschließlich physikalischem Systemtest auf Flugzeugebene, Systemprüfstand inklusive Leistungs-, Dauer- und Ermüdungstests, Prüfstand für Klappen-Controller einschließlich Softwareentwicklungs-, Flugsimulator-, Softwarefunktions-, Regressions-, System- und Produktionstests (Abnahmetestverfahren) sowie physikalische Tests inklusive Tests einzelner Tragflächen und „rechtsseitiger“ Tests basierend auf einer linksseitigen Gesamtbelastung.

Mehrere Ziele wurden erreicht. Zum einen erstellten wir eine einheitliche Prüfplattform, die eine durchgängige Testarchitektur und ein universelles Prüfgerät bietet. Dabei wurde derselbe SFECU-Prüfstand für die gesamte Entwurfsvalidierung und -verifizierung eingesetzt: Entwicklung, Abnahmetestverfahren, Iron-Bird-Tests, SITS (System Integration Test Stand), Tests produktionsreifer Controller und mechanischer Hardware. Zum anderen wurde modulare Hardware eingebunden, die wir warten und rekonfigurieren können. Dadurch ist eine Ausweitung zur Qualifizierung größerer Systeme sowie eine Neukonfiguration für verschiedene Systeme problemlos möglich. Auch Verdrahtung und Installation zur Anbindung von Systemkomponenten lassen sich vermeiden. Und schließlich verfügen wir über eine offene Softwarearchitektur, die sich leicht integrieren lässt. Die Spiegelspeicher-Architektur erlaubt eine vollständige Steuerung der Prüfstände mithilfe von Schreib- und Lesevorgängen. Wir können diese Architektur separat verwenden oder in größere Prüfsysteme integrieren und eine verteilte Steuerung erzielen, die bei wachsendem System mehr Rechenleistung ermöglicht.

Details der D3-Architektur

Bei der D3-Architektur handelt es sich um ein sehr anpassungsfähiges, modulares und universelles Prüfsystem, das ausgereifte Technologien aus der Industrie mit nur wenigen Anpassungen leicht integriert. Zu diesen Technologien gehören verteilte Steuerung und Regelung basierend auf den Erweiterungsmöglichkeiten von NI CompactRIO und FPGA-Hardware sowie eine direkte Schnittstelle zur servoelektrischen Laststeuerung mithilfe eines Antriebsschnittstellenmoduls der C-Serie und AKD-Servoantrieben sowie AKM-Servomotoren von Kollmorgen.

Der SFECU-Prüfstand ist eine im Rack montierte Plattform, die alle echten bzw. eine Kombination aus echten und simulierten Controllern umfasst. Wenn nur ein Controller vorhanden ist, kann der andere über CAN-Bus simuliert werden. Mit diesem System werden die elektromechanischen Komponenten des Flugzeugs simuliert. Die Fehlermodi des Flugzeugs simulieren wir mit proprietären Simulationsprogrammen. Der Prüfstand ist vollständig programmierbar und stellt so jeden automatisierten Tastgrad oder spezifischen Funktionstest bereit. In allen Fällen ist es möglich, die simulierte Hardware durch reale Hardware zu ersetzen und umgekehrt.

Die Hardware in diesen Prüfracks bietet Schaltmöglichkeiten auf echte Hardware des Flugzeugs oder auf simulierte Wandler, die in Subchassis des Prüfracks untergebracht sind. Die Prüfracks umfassen außerdem Hardware zur Überwachung von diskreten und analogen Spannungen und Strömen sowie von Signalen des Controllers im Flugzeug. Im Einzelnen beinhalten die Racks Folgendes: Chassis zur Steuerung, Regelung und Überwachung von Gleich- und Wechselstrom, Chassis für die Bremslastsimulation, -schaltung und -überwachung, interne Gleichstromquellen, Baugruppen für die Resolversimulation, -schaltung und -überwachung, Baugruppen für die diskrete Simulation, Schaltung und Überwachung, ARINC-429- und CAN-Sende- und -Empfangsbaugruppen, eine Baugruppe für die Notstoppsteuerung und -überwachung, Prüfboxbaugruppen, Datenerfassungsbaugruppen, generische LRU-Schnittstellen- zu benutzerdefinierten LRU-Adapterbaugruppen sowie einen Windows-basierten PC mit unterbrechungsfreier Stromversorgung.

Die Prüfracks bieten zudem externe elektrische Schnittstellen zum gemeinsam genutzten Desktop-Arbeitsbereich (Mensch-Maschine-Schnittstellen), Schnittstellen für reale Flughardware, externe ARINC-429-Quellen und -Senken sowie externe Baugruppen zur AC/DC-Stromversorgung für Tests der Netzqualität.

Der SFECU-Prüfstand wird mit auf LabVIEW basierender Software ausgeführt, sodass der Prüfstand sowohl manuell als auch automatisch konfiguriert und bedient werden kann. Des Weiteren können Prüfstandfunktionen auch über einen deterministischen Spiegelspeicher-Datenbus gesteuert und überwacht werden.

Einsatzmöglichkeiten für unterschiedliche grafische Benutzeroberflächen und Prüfstandkonfigurationen

Die Software lässt sich so anpassen, speichern und rekonfigurieren, dass viele verschiedene grafische Benutzeroberflächen- und Prüfstandkonfigurationen unterstützt werden. So ist es beispielsweise mit dem SFECU-SITS möglich, den Hauptprüfstand zusammen mit einem PDU-Modell zu verwenden, das im Prüfstand ausgeführt wird, und alle Messumformer und diskreten Signale komplett zu simulieren. Wir können System-, Überdrehzahl-, Unterdrehzahl- sowie andere Oberflächenfehler mithilfe des SITS-Cockpits (Flughardware) und der Simulation umkehren, um den Befehl des Klappensteuerhebels an die SFECU und das Modell zu senden. Alle Fehler können auf die SFECU angewendet werden, um die EICAS-Logik (Engine Indicating and Crew Alerting System) zu validieren. Des Weiteren können wir Wartungsanzeigen mithilfe des über die SFECU verbundenen Prüfstands testen, da wir die gesamte Kommunikation, Lasten, diskrete Signale und Messumformer simulieren können. Für die Abnahmetestverfahren der SFECU können wir den Prüfstand für Klappen-Controller verwenden, um so dieselben Abnahmetestverfahren durchzuführen, die in der Produktionsstätte laufen. Verschiedene Abnahmetestverfahren stehen zur Wahl, z. B. schaltungsweise oder eine komplette Simulation mit Flugsoftware (Flugsimulatortest). Tests können zudem mithilfe einer anwenderdefinierbaren, minimalistischen grafischen Benutzeroberfläche und einem Prüfsequenzprogramm automatisiert werden, das Python-Skripte ausführt.

Darüber hinaus bietet die D3-Architektur Konfigurationen für den integrierten Prüfstand zur Systemtestzertifizierung, die erneute Verwendung der SFECU nach der Wartung (z. B. zur Ermittlung von Fehlerbedingungen, die einen selbsthaltenden Fehler verursachten) sowie die Protokollierung und Anzeige (Spiegelspeicher-Konfigurationsprogramm für die Datenprotokollierung zur Aufzeichnung von Reflective-Memory-Werten mit einer Rate von 200 Hz). Ebenfalls verfügbar sind Konfigurationen für das CAN- und ARINC-Datenprotokollierung, die Datenanzeige (die grafische Benutzeroberfläche des Flugzeugs zeigt die Werte für jeden Resolver, Ströme, Spannungen usw. an; ausgehend von den Bausteinen gängiger benutzerdefinierter Bausteine können Benutzeroberflächen erstellt, angepasst und gespeichert werden) und die Automatisierung (Skripterstellung über TestStand, Python oder eine andere beliebige Sprache über Socket- und JSON-Serialisierung, Automatisierung durch externe Anwendungen/Systeme mit Zugriff auf das RFM, Stimulusprofile zur Ausführung des Controllers mit benutzerdefiniertem LabVIEW-Code, Makro-Aufzeichnung und -Wiedergabe, automatisierte Softwarefunktionalität und automatisierte Abnahmetestverfahren).

Einsparungen von Collins Aerospace bei Kosten, Zeit und Arbeitsaufwand

Mit den verteilten Mess-, Steuer- und Regelprodukten von NI konnten wir die Dauer der Testneukonfiguration von einigen Wochen auf einen Tag reduzieren. Unsere D3-Architektur lässt sich universell einsetzen (dieselben Belastungstabellen für das System, die Abnahmetestverfahren und den Iron Bird, derselbe SFECU-Prüfstand für die Entwicklung, Abnahmetestverfahren, Iron Bird, SITS, ESIM). Sie ist modular (keine Verdrahtung oder Installation zur Anbindung; Hard- und Software bauen auf Designs auf, die für viele Flugzeuge üblich sind), lässt sich leicht integrieren (offene Softwarearchitektur; Skripterstellung in beliebiger Sprache; bewährte RFM-Architektur, dank der der Prüfstand im getrennten oder integrierten Modus ausführbar ist) und warten (herkömmlicher Aufbau mit Kabelbaum aufgrund umfangreicher Nutzung von Leiterplatten nicht mehr erforderlich) und ist zukunftsgerichtet (das Team besitzt patentierbare Designs).

Durch die Entwicklung einer einheitlichen Prüfplattform für unsere HIL-, Verifizierungs- und Validierungs-, Systemintegrations- und Produktionsprüfanforderungen für verschiedene Projekte und Flugzeugarchitekturen konnten wir die Entwicklungszeit für unsere Prüfsysteme reduzieren und uns gleichzeitig besser für künftige Anforderungen aufstellen, u. a. für ein stärker digitalisiertes Prüflabor. Wir konnten etliche Monate an Entwicklungszeit und hunderttausende Dollar an Ausgaben für neue Plattformen sparen. Zugleich fiel weniger Arbeitsaufwand im Prüflabor an. Wir haben eine Architektur realisiert, auf der ein komplettes Testlabor auf einer Reihe einheitlicher mobiler Front-Ends ausgeführt werden kann. Dadurch können wir das Problem veralteter, stationärer Elektronik umgehen, die nur eine Funktion auf einem einzigen mechanischen Prüfstand ausführt. Aktuell arbeiten wir daran, die Integration dieser neuen Architektur in unsere täglich verwendeten Systeme abzuschließen, um ein vollständig automatisiertes Prüflabor zu verwirklichen, in dem Bedenken aufgrund der Arbeitskosten der Vergangenheit angehören und Kapital für weitere Innovationen freigesetzt wird.

Informationen zum Autor:

Scott Christensen
Collins Aerospace