Johannes Fritz, Markus Schwarz

Johannes Fritz, Markus Schwarz

Foto:AVL List GmbH

Gelebtes Systems Engineering in der Testsystem-Entwicklung

Das Zusammenwirken mechanischer, elektronischer, informations- und datentechnischer Elemente ermöglicht es heute, maßgeschneiderte und kosteneffiziente Systeme mit den dazugehörigen Diensten zu realisieren. Dies erhöht allerdings auch die Komplexität der technischen Lösung und somit die Komplexität der Leistungserbringung. Mit dieser Herausforderung sind die Automobilindustrie, die Luft- und Raumfahrt, der Anlagenbau und viele andere Branchen konfrontiert. Bei der Entwicklung komplexer Systeme ist die enge Kollaboration unterschiedlicher Fachdomänen unumgänglich, auch wenn die zusammenarbeitenden Entwicklungsteams und Entwicklungsstätten oftmals weltweit verteilt sind. Dies hat nicht nur Einfluss auf den Entwicklungsprozess und die Organisation. Hier müssen geeignete Methoden und Werkzeuge gefunden werden, die es in Folge im Unternehmen zu etablieren gilt.

Entwicklung von Antriebs- und Testsystemen

AVL ist das weltweit größte, unabhängige Unternehmen für Entwicklung, Simulation und Testen von Antriebssystemen (Hybrid, Verbrennungsmotor, Getriebe, Elektroantrieb, Batterien, Brennstoffzelle und Regelungstechnik) für Pkw, Nutzfahrzeuge, stationäre Motoren, Großmotoren sowie deren Integration in das Fahrzeug. Das Unternehmen verfügt über jahrzehntelange Erfahrung in der Entwicklung und Optimierung von Antriebssystemen. Dazu stellt AVL als weltweiter Technologieführer komplette und durchgängige Entwicklungsumgebungen, Mess- und Testsysteme sowie modernste Simulationsmethoden zur Verfügung.

Die Produktentstehung wird in der Automobilindustrie gerne anhand des V-Modells dargestellt, welches sich aus den wesentlichen Phasen Systementwurf, domänenspezifischer Entwurf und Systemintegration inklusive Verifikation und Validierung zusammensetzt, siehe Abbildung 1. Ausgehend von der Festlegung der Anforderungen für das Gesamtfahrzeug erfolgt die Festlegung der Ziele zuerst für die einzelnen Systeme und in Folge für Subsysteme und Komponenten. Testsysteme sind hier traditionell am rechten Ast des V-Modells angesiedelt. Für verschiedene Entwicklungsaufgaben kommen spezifische Testumgebungen in unterschiedlichen Ausprägungen zum Einsatz, u.a. Komponenten-, Motoren-, Antriebsstrang, Fahrzeugtestsysteme und der Fahrversuch.

Stand in der Vergangenheit die Forderung nach kürzeren Entwicklungszyklen im Vordergrund, tritt derzeit der Innovationsdruck als starker Treiber auf. Dies liegt in den sich ändernden gesetzlichen Anforderungen und damit einhergehend im Schwenk zu neuen Antriebssystemen begründet. Mit den neuen Antriebssystemen ändert sich die bisher vorherrschende Architektur des Antriebsstrangs und somit die des Fahrzeugs. Elektrifizierte Antriebsstränge, ob als Hybrid (HEV, PHEV), mit Traktionsbatterie (BEV) oder mit Brennstoffzelle (FCEV), ermöglichen neue Fahrzeugarchitekturen (z.B. SkateboardArchitektur).

Aufgrund der sich nun verändernden Architektur fehlt es an belastbaren Erfahrungswerten und industrialisierten Abläufen, wie es die Automobilindustrie in den letzten Jahren gewohnt war. Die dafür notwendigen Investitionen erzeugen einen enormen Druck auf Simula-

tion und Test. Sie müssen hier die frühzeitige Absicherung des Fahrzeugentwurfs und dessen Integration gewährleisten, um anhand der gestellten Anforderungen und getroffenen Annahmen die bestmögliche Architekturvariante zu identifizieren.

Wird der Blick auf die Testsysteme gerichtet, so bleibt deren Kernaufgabe bestehen. Im Zentrum steht nach wie vor das korrekte, reproduzierbare Erfassen von Messdaten in der geforderten Genauigkeit, die in automatisierten Testzyklen bei akzeptablen Kosten und der notwendigen Flexibilität zur Evaluierung weiterer Prüfparameter erzeugt werden. Dennoch führen die Veränderungen in der Automobilindustrie auch zu einem Umbruch bei den benötigten Testsystemen. Mit den neuen Entwicklungsaufgaben ergeben sich auch neue Anforderungen an Testsysteme. Das zunehmende Verlagern von Entwicklungsaufgaben in frühere Phasen des Entwicklungsprozesses bedingt die verstärkte Einbindung von Simulationsumgebungen am Prüfstand, um die real noch nichtexistierenden Aspekte, Eigenschaften und Komponenten virtuell nachbilden zu können (z.B. Fahrstrategien, Fahrzeugkomponenten, Fahrzeugumwelt). Hinzu kommt die inhärente Komplexität des Prüflings und die für dessen Betrieb notwendige Konnektivität mit der Umwelt (z.B. Sensorik, Aktuatorik, Restbussimulation), die es in der Testumgebung handzuhaben gilt.

Des Weiteren wandeln sich auch die Anforderungen an den Betrieb von Testsystemen. Die flexible Nutzung des Testsystems für verschiedene Entwicklungsaufgaben, (semi-)autonome Betriebskonzepte, IoTA nw e n du n g s f ä l l e , adaptive, durch KIunterstützte Prüfverfahren, automatisierte Logistikprozesse, die entsprechende Sicherheitstechnik und die Einbindung in die Gebäudeautomatisierung sind in diesem Zusammenhang ausgewählte Treiber. Darüber hinaus steht der ressourcenschonende Betrieb immer mehr im Vordergrund (z.B. Energieeffizienz und -rückgewinnung, Schadstoffnachbehandlung, reduzierter Medienverbrauch). Verändertes Zusammenspiel zwischen Kunden und Anbieter Die Kundenausschreibungen für BEVund FCEV-Testsysteme unterscheiden sich wesentlich von bekannten Ausschreibungen im Bereich Verbrennungsmotor und Antriebsstrang. Bei Testsystemen für konventionelle Antriebssysteme bestehen viele Kundenbeziehungen seit vielen Jahren und gegenseitiges Wissen über Bedürfnisse und Erwartungen ist weitestgehend vorhanden. Anders stellt sich die Situation bei den neuen Technologien dar. Neue Hersteller drängen in den Markt, ohne klare Konzepte über die Testanforderungen in den unterschiedlichen Entwicklungsstadien für ihre Produkte zu haben. Hier wird von einem Anbieter wie AVL erwartet beratend aufzutreten und ein Gesamtkonzept anzubieten, im Rahmen dessen sämtliche Entwicklungsaufgaben effizient und effektiv abgedeckt werden können.

Bei traditionellen Automobilherstellern sind neue Fachbereiche mit neuen Ansprechpartnern für die Ausschreibungen der Entwicklungsprojekte zuständig. Testsysteme werden aufgrund der Unsicherheit, welche Anforderungen für welche Tests zukünftig maßgeblich sein werden, teilweise bis auf die Sensorebene spezifiziert. Die Erfahrung zeigt, dass es bei dieser Kategorie von Ausschreibungen essentiell ist, sämtliche Anforderungen genau zu extrahieren und zu analysieren. In vielen Fällen steigt der Preis von Komponenten und deren Integrationsaufwand überproportional an, wenn Messbereiche und Genauigkeiten verlangt werden, die über die Mindestanforderungen hinausgehen. Hier besteht die Herausforderung dann darin, beim Kunden Überzeugungsarbeit für eine wirtschaftlichere Lösung zu leisten und entsprechend die Abweichungen zur Ausschreibung festzuhalten. Anwendungsfall- und Anforderungsanalyse Dieser Ansatz kann aber nur funktionieren, wenn die zugrundeliegenden Anwendungsfälle des Kunden genau analysiert, diskutiert und von Anbieter- wie auch Kundenseite verstanden worden sind, siehe Abbildung 2. Das Wissen um die eigentlichen Anwendungsfälle ermöglicht es, Aufwand, Kosten und Risiken in der Vertriebsphase niedrig zu halten. Mit diesem Wissen können die Anforderungen leichter mit bestehenden Referenzlösungen abgeglichen werden. Für solche Referenzlösungen existieren standardisierte Angebote, Schnittstellen, Abbildung 1 V-Modell nach VDI 2206 Abbildung 2 Prinzipielles Vorgehen zur Analyse von Kundenanforderungen

Engineering- und Fertigungsdokumente, Lieferantenausschreibungen und Installations- und Inbetriebnahme-Prozeduren, wobei durch deren Wiederverwendung die EngineeringAufwände und das Risiko in der Projektphase beträchtlich sinken.

Die verwendeten Ansätze zur Analyse und Beantwortung von Ausschreibungen haben gemeinsam, dass abgeleitete Anforderungen exakt dokumentiert und bewertet werden müssen. Dies ist insbesondere notwendig um in großen Angebotsprojekten Übersicht und Nachvollziehbarkeit zu schaffen und die Zusammenarbeit im Angebotsteam zu erleichtern. Eine Anforderung führt entweder zum Anbieten eines konkreten Commercial-of-the-Shelf-Produktes, das die Anforderung erfüllt, eines Systems, das exakt mit den gewünschten Eigenschaften gestaltet wird, oder einer alternativen Lösung, die ebenfalls den zugrundeliegenden Anwendungsfall, nicht aber die konkrete Anforderung erfüllt und somit als Abweichung nachvollziehbar festgehalten und dem Kunden kommuniziert wird.

Die Abgabe des Angebots stellt einen Zwischenschritt im Lebenszyklus einer Anforderung dar. Kommt es zum Kundenauftrag, muss diese im Projekt umgesetzt werden. Dieser Zyklus folgt im Wesentlichen dem VModell und reicht von Spezifikation und Entwurf über die Implementierung und Dokumentation bis hin zur Integration, Verifikation und schließlich Validierung der jeweiligen Anforderung mit dem Kunden. Ziel ist es, die Entwicklung von Anforderungen nachvollziehbar zu gestalten: Was war der Ursprung der Anforderung? Welche Zielsetzung wird verfolgt? Wie wird sie erfüllt und wie soll ihre erfolgreiche Umsetzung nachgewiesen werden?

Des Weiteren müssen relevante Lieferbestandteile mit den entsprechenden Anwendungsfällen bzw. Anforderungen verknüpft sein. Dazu zählen u.a. Bedien- und Betriebskonzepte, Ablauf- und Funktionsbeschreibungen inklusive der Referenz auf die leistungserbringenden Einheiten auf Komponenten-, Subsystem- und/oder System-Level, und Abnahmekriterien. Darüber hinaus gilt es den Überblick über Änderungen und Gültigkeit der Anforderungen zu behalten: Was ist der abgestimmte Stand der Anforderung, welchen Einfluss hat die Änderung auf weitere Anforderungen und ist die Anforderung noch aktuell. Gerade im Kontext von Änderungen kommen neben den technischen oftmals auch vertragsrechtliche und kommerzielle Überlegungen zum Tragen.

Viele Kundenausschreibungen unterliegen generellen Normen und Standards. Diese können sich aus regionalen und länderspezifischen Normen und Standards ergeben, und können darüber hinaus spezifisch für einzelne Kunden oder Kundenstandorte zutreffend sein.

Oft werden auch (Teil-)Lösungen von verschiedenen Kunden angefragt, deren Anforderungen aufgrund ähnlicher Entwicklungsaufgaben und -vorgehen kaum zu unterscheiden sind. Solche Anforderungen werden initial einmalig erfasst, analysiert und entsprechend dokumentiert. In der Folge können die Anforderungen und darauf basierende Lösungen effizient wiederverwendet werden. Aufwände und Risiken können so in der Projektausführung niedrig gehalten werden. Sollte es relevante Erfahrungen aus Projekten geben, müssen diese auch in die Referenzlösungen zurückfließen.

Die Systemstruktur im Zentrum des Handelns

Neben dem Verstehen der Anwendungsfälle und Anforderungen stellt deren Zuordnung zur generischen Systemstruktur den Dreh- und Angelpunkt dar, siehe Abbildung 3. Die Systemstruktur beschreibt Testsysteme unabhängig von ihrem Typus anhand der hierarchischen Gliederung in vier logisch-funktionalen Ebenen: Gesamtsystem (inkl. Gebäude und Infrastruktur), System, Subsystem und Komponente. Mit der Zuordnung der Anforderungen zur Systemstruktur erfolgt der Übersetzungsprozess der Kundensicht in die AVL-eigene Sicht. Dies vereinfacht die Beurteilung und spätere Wiederverwendbarkeit von bereits bestehenden (Teil-)Lösungen. Des Weiteren bildet die Systemstruktur die Grundlage für Wertschöpfungsprozesse, wesentliche Lieferbestandteile und die dahinterliegenden IT-Werkzeuge sowie die Definition von Verantwortlichkeiten. Die Eignung für diese Aufgaben ergibt sich durch die logische Struktur sowie das Regelwerk, welches den Umgang mit und die Adaptionsmöglichkeiten an der Systemstruktur klar definiert.

In der Vertriebs- und in der Projektphase rücken unterschiedliche Ebenen für den Kunden und die AVL in den Vordergrund. So liegt der Fokus beim Erstellen des Konzeptentwurfs stärker auf den höheren Ebenen um dem Kunden die Gesamtheit des Angebots kompakt darzustellen, während für die dahinterliegende

Kalkulation auch Kosten und Aufwände aus den darunterliegenden Ebenen aggregiert werden. Mit der Erteilung des Kundenauftrags und somit zu Beginn des EngineeringProzesses werden die Umfänge der definierten Systeme und Subsysteme geprüft. Für jedes dieser Subsysteme wird ein Subsystemverantwortlicher für die interdisziplinäre Planung und Integration der Funktionsbausteine, Komponenten und Baugruppen nominiert. In dessen Verantwortung liegt einerseits die interdisziplinäre Koordination der Komponenten- und Schnittstellenverantwortlichen, insbesondere während der Systementwurfs- und der domänenspezifischen Entwurfsphase, sowie andererseits die vorausschauende Planung der Integrations- und Abnahmeschritte für das jeweilige Subsystem.

Übergeordnet, auf Gesamtsystem- und Systemebene, agiert der Systemintegrator, der für die vorausschauende und korrekte Integration der Subsysteme zu einem funktionierenden Gesamtsystem in der Kundenumgebung Sorge trägt. Auch wenn der Titel Systemintegrator dazu verleitet, diese Rolle stark am rechten Ast des V-Modells zu verorten, ist der angestammte Wirkungsbereich im linken Ast zu finden. Im Sinne des Frontloading liegt sein Fokus auf der Vertriebs- und Systementwurfsphase, um die Anwendungsfälle, Anforderungen und Akzeptanzkriterien des Kunden entsprechend aufzunehmen, diese für die nachfolgenden Phasen aufzubereiten und entsprechend der Systemstruktur herunterzubrechen.

Wie auch für den Subsystemverantwortlichen gelten für den Systemintegrator die Koordination der wiederkehrenden interdisziplinären EngineeringAktivitäten (z.B. Design Reviews, Risikobewertung) und die übergeordnete Planung der Integrationsund Testkampagne bis hin zur Kundenabnahme als zentrale Aufgaben, beginnend mit der Vertriebsphase.

Um Designs vorab validieren zu können und die Akzeptanz des Kunden für eine geplante Lösung bereits frühzeitig zu erhalten, kommen vermehrt Virtual Reality Applikationen zum Einsatz. Neben dem Durchwandern des Testsystems in realer Größe können hiermit auch die Interaktion mit Equipment und die Simulation von Arbeitsabläufen bereits in den frühen Phasen erprobt werden. In den späteren Phasen verschiebt sich der Einsatz von Virtual Reality hin zu Design Reviews, Detailbetrachtungen von Arbeitsabläufen (z.B. Ergonomieuntersuchungen) und als virtuelle Trainingsumgebung, siehe Abbildung 4.

Dipl.-Ing. Johannes Fritz, BSc Senior Systems Engineering Method Manager bei AVL

Dipl.-Ing.

Markus Schwarz Department Manager System Design Software & Systems Engineering bei AVL

Autoren:

Dipl.-Ing. Johannes Fritz, BSc hat Maschinenbau an der Technischen Universität Graz und IT & IT-Marketing an der Fachhochschule Campus02 in Graz studiert. Er ist „Senior Systems Engineering Methods Manager“ bei AVL in Graz, Österreich, wo er für die Entwicklung und Einführung von Systems Engineering Methoden und Werkzeugen im Bereich Global Project Operations für Testsysteme verantwortlich ist. Neben seiner Tätigkeit bei AVL ist Johannes Fritz Lektor für „Model-Based Engineering“ am Masterstudiengang Automatisierungstechnik an der Fachhochschule Campus02. Dipl.-Ing. Markus Schwarz hat an der Technischen Universität Graz Telematik studiert. Er hat die Position „Department Manager Systems Engineering & System Design Software“ bei AVL in Graz, Österreich, inne. Zu den Aufgaben seiner Teams im Bereich Global Project Operations für Testsysteme gehört die Entwicklung von Standards und projektspezifischen Applikationen im Bereich der Testautomatisierung sowie Anforderungsanalysen, Spezifikationen und Systemintegrationen für komplexe mechatronische Systeme.