PTC

Systems Engineering - PTC

Grundlage dieses Whitepapers war ein Gespräch mit Andrew Wertkin. Andrew Wertkin (Foto: Sendler) ist Chief Technology Officer (CTO) der PTC Business Unit Integrity. So heißt das Produkt des im Juni 2011 von PTC übernommenen Anbieters MKS, das auf das Application Lifecycle Management (ALM) in der Softwareentwicklung zielt. Andrew Wertkin war zuletzt CTO bei MKS.

Zuvor war er Mitgründer und CTO von Synapsis Technology, einem Unternehmen, das mit seinen Produkten die softwaretechnische Berücksichtigung von Compliance in der Produktentwicklung unterstützte. 2008 wurde Synapsis von PTC übernommen.

Andrew Wertkin studierte Bio-Engineering an der Universität von Pennsylvania.

In Stichworten:

PTC hat mit MKS den Anbieter eines Systems für Application Lifecycle Management, Integrity,  übernommen. Der Vertrieb erfolgt vorläufig weiterhin als Gesamtsystem in Ergänzung zu den PLM-Tools, vor allem Windchill und Creo.

PTC sieht eine wichtige Anforderung des Marktes darin, hinsichtlich des Systems Engineerings offen zu sein und alle von den Kunden eingesetzten Tools unterschiedlicher Anbieter für Modellbildung, Analyse, Test und Simulation zu unterstützen.

Die wichtigsten Funktionalitäten, die PTC für das Systems Engineering bietet, sind:

  • Requirements Engineering und Requirements Management
  • Testerstellung und Testmanagement
  • Dokumentation aller Modelle, Tests und Simulationen auf Basis der Requirements
  • Nachvollziehbarkeit der gesamten Systementwicklung auf Basis der Requirements
  • Integration des Systems Engineerings ins PLM

Die Roadmap der weiteren Entwicklung und der Integration von PLM und ALM wird mit einem globalen, beratenden Gremium von PTC-Kunden abgestimmt.

Die Bedeutung des Systems Engineering

Für PTC hat Systems Engineering hohe Priorität. Aus der Sicht von Andrew Wertkin sind die Zeiten vorbei, da Software nur ein zusätzlicher Punkt in der Stückliste war. Wo für PLM die Stückliste der Mittelpunkt der Welt war, sei heute das System auf dem Weg, zum Mittelpunkt der Welt zu avancieren. Alles andere, die Stückliste, das Teil, die Komponente das Produkt ist nun Teil des Systems. Und das lässt Systems Engineering für PTC zu einem strategischen Thema werden, bei dem PLM ins Spiel kommt.

Systems Engineering selbst ist schon rund 60 Jahre alt und hat seinen Ursprung in der Welt der Luft- und Raumfahrt und der Rüstungsindustrie, wofür es im Englischen das Kürzel A&D gibt: Aerospace & Defense. Gegenüber den damaligen sind allerdings die heutigen Systeme wesentlich komplexer. Die Treiber dieser Komplexität sind einerseits der Trend, immer mehr Innovationen durch Software zu realisieren, andererseits die Tatsache, dass moderne Produkte zunehmend miteinander und mit der Umwelt kommunizieren und interagieren. John Deere zum Beispiel spricht nicht mehr von Landmaschinen, sondern von High-Tech-Landwirtschaftslösungen mit Anschluss an Satelliten und integriertem GPS.

Neben der Komplexität sind es vor allem der Druck hoher Qualitätsanforderungen und gesetzliche Bestimmungen, die die Industrie zwingen, sich mit Systems Engineering auseinanderzusetzen.

Branchenrelevanz

Die beschriebene Tendenz gilt branchenübergreifend für nahezu alle Industrien. Deshalb gibt es aus Sicht von PTC keine speziellen Zielbranchen für die Unterstützung des Systems Engineering. Aber hinsichtlich der Reife des methodischen Vorgehens werden große Unterschiede gesehen. In vielen Unternehmen wird noch kein regelrechtes Anforderungsmanagement betrieben. Oft unterscheiden sich Anforderungen etwa in ihrer Bedeutung lediglich dadurch, ob sie in einem Textdokument fett gedruckt sind oder nicht. Auf der anderen Seite haben Firmen längst die durchgängige Prozesskette im Systems Engineering vor Augen. Dementsprechend unterscheidet sich die Kundenansprache von PTC.

Bei High Tech Electronics stehen Anforderungsmanagement und Validierung der Anforderungen im Vordergrund. Luft- und Raumfahrt kennen das Thema am längsten und sind die Haupttreiber von Standardisierungsbemühungen. Die Automobilindustrie scheint heute aber hinsichtlich der Methodik am weitesten zu sein. Requirements Engineering ist hier Standard. Jetzt geht es bereits um die Verknüpfung der Domänen und um die Verkettung der Prozesse vom Konzept über Änderungsmanagement, Test und Absicherung bis hin zum Kunden.

Requirements Engineering - Kern der Systementwicklung

Für PTC ist die wichtigste Phase der Systementwicklung diejenige, die beim V-Modell ganz oben links erscheint, die Phase der Erfassung der Anforderungen an das Produkt (Requirements) und der Auslegung einer dafür passenden Systemarchitektur. Andrew Wertkin: „Nur wenn hier methodisch sauber gearbeitet wird, können richtige Entscheidungen für die Zergliederung des Systems oder auch für Varianten getroffen werden. Die ‚Warums‘ des Systems Engineering finden hier ihre Antworten begründet. Alle Entscheidungen in den nachfolgenden Prozessen hängen davon ab, dass der Kern in der Konzeptphase richtig definiert, das System richtig ausgelegt ist. Deswegen liegt unser Schwerpunkt darin, vor allem diese ersten Entscheidungen zu unterstützen, die getroffen werden, bevor irgendeine Software und erst recht Hardware entwickelt wird. Bisher ist gerade diese Phase weitgehend von PLM getrennt.“

Integrity verfügt für das Requirements Engineering über ein eigenes, umfassendes Modul, das Andrew Wertkin von seinem Funktionsumfang mit DOORS von IBM vergleicht. PTC vertreibt es wie vorher MKS nicht als separates Modul. Die Stärke von Integrity liege gerade in der Integration aller wichtigen Teile des Systems. Insbesondere darin, dass das Requirements Engineering eine durchgängige Grundlage darstelle für alle anderen Schritte der Systementwicklung.

tl_files/plm/img/Hintergrundtexte/PTC/andrew 2.jpgAndrew Wertkin (Foto: Sendler) gibt ein Beispiel: „Manche Anbieter betrachten die Wiederverwendung von Teilen oder Sourcecode als Frage von Copy and Paste. Sie helfen dem Anwender, bestimmte, bereits entwickelte Objekte schnell zu finden und dann für irgendeinen Zweck zu klonen und erneut zu verwenden. Aber auf diese Weise werden möglicherweise auch Fehler vererbt. Oder es wird eine Variante oder Abwandlung einer Komponente verwendet, die nur für einen ganz bestimmten Zweck gedacht war. Wir bauen dagegen schon aus den Requirements einen regelrechten Strukturbaum auf. Verwende ich eine Anforderung für einen bestimmten Zweck, für den ich sie verändern muss, dann wird in unserem System ein Zweig gebildet. Der Anwender kann zurückverfolgen, wo in der Entwicklung und zu welchem Zweck etwas festgelegt oder verändert wurde. Und damit kann er exakt die richtige Komponente erneut verwenden.“

Dieses methodische Vorgehen in der Auslegung des Systems ist die Grundlage für alle Arten von Analyse, Test und Simulation, die dann folgen.

Modellbasierte Systementwicklung und Dokumentation

Eine wichtige Frage des Systems Engineering betrifft das modellbasierte Arbeiten. Welche Modelle werden an welcher Stelle der Entwicklung genutzt und wofür? Sind die Modelle miteinander verknüpft oder nicht? Dienen sie über Fachbereichsgrenzen hinweg oder nur innerhalb eines Bereichs?

PTC geht in dieser Frage von folgender Prämisse aus:

  • Systems Engineering kommt in erster Linie dort zum Tragen, wo völlig neue Produkte ‚erfunden‘ und entwickelt werden.
  • Die Frage der Nutzung von Modellen stellt sich hauptsächlich dort, wo die Komplexität sehr groß wird, wo sehr spezifische Probleme zu lösen sind, oder wo eine Sprunginnovation realisiert werden soll.

Wo bislang überhaupt nicht mit Modellen gearbeitet wurde, ist es wenig sinnvoll, nun nachträglich solche Modelle zu implementieren. Dort, wo schon modellbasiert gearbeitet wird, verfügen die Kunden in den meisten Fällen über entsprechende Tools oder nutzen bestimmte Modelliersprachen. PTC sieht den Bedarf der Kunden deshalb nicht so sehr in der Modellbildung, sondern in der Nutzung, Kopplung und Verfolgung (Tracking) der Modelle.

Eine besondere Bedeutung haben Modelle vor allem dort, wo die Software eine große Rolle spielt. Zum Beispiel bei der Entwicklung von Steuerungen oder zur Modellierung der Interaktion von Komponenten, ob es sich dabei um elektronische Subsysteme handelt, um physikalische Komponenten oder um Teilsysteme. Oft wird dann angestrebt, aus einem entsprechenden Modell automatisiert den benötigten Sourcecode zu generieren.

Das  Ziel von PTC ist ein ‚hybrides System‘, das in der Lage ist, Modelle unterschiedlichster Herkunft und Art miteinander zu verbinden und zu nutzen. Wertkin: „Der Schlüssel ist Offenheit! Die Kunden erwarten nicht einen One-Stop-Shop für Systems Engineering, und das gilt vielleicht auch für PLM.“

Die Hauptaufgabe sieht PTC dabei in den folgenden Punkten:

  • Dokumentation der Modelle
  • Einbetten der Modelle in Änderungs- und Konfigurationsmanagement
  • Verfolgen der Modelle in Hinsicht auf die zugrundeliegenden Anforderungen (Tracking)
  • Verstehen der Auswirkungen von Anforderungsänderungen auf die Modelle
  • Verstehen der Auswirkungen von Fehlern in Tests auf die Modelle

PTC will ein sehr flexibles Modell für die Nachvollziehbarkeit der Entstehungs- und Änderungshistorie (Traceability) bieten, das in der Lage ist, das große Netzwerk von Informationen, das im Systems Engineering entsteht, in all seinen Knoten und Verknüpfungen nachvollziehbar zu machen. Aus Sicht der Anforderungen sollen alle nachfolgenden Modelle im Blick gehalten werden, einschließlich der auf sie angewandten Analysen und Tests. Und diese Nachvollziehbarkeit soll geboten werden auf Systemebene, für die Subsysteme und bis hinunter auf die Ebene sämtlicher Komponenten in Hard- und Software.

Dazu gehört die Dokumentation und damit einfache Zugänglichkeit dieses komplexen Informationsnetzwerks. Eine Dokumentation, die die Frage beantwortet, auf welchem Modell und welchen Anforderungen ein bestimmtes Teil zu einem bestimmten Zeitpunkt seiner Entwicklung basiert – Schlagwort Baselining.

PTC bietet mit Integrity auch die Tools zur Erstellung und Dokumentation von Test-Cases und zum Management der Testausführung. Als Beispiel nennt Andrew Wertkin das ‚Hardware in the Loop Testing‘. Hier sind möglicherweise noch gar keine Komponenten entwickelt. Ein Modell generiert automatisch einen Sourcecode,  und dann wird die Software mit Hardware in the Loop Testing als Gesamtsystem getestet, an einer ECU, die die entsprechenden Signale von einem virtuellen Fahrzeug bekommt. Dieser Test bringt ein Ergebnis. Und dieses Ergebnis wird nun zurück ins System gebracht, zum Beispiel als Sollergebnis, das mit dem System später tatsächlich erreicht werden  soll. Das kann nun weiter verfolgt und mit den tatsächlichen Ergebnissen verglichen werden. Wenn dann das Teil im wirklichen Fahrzeug verbaut ist, sollten die erzielten Resultate exakt denen aus dem Test entsprechen.

Funktionssimulation

Einer der zentralen Unterschiede zwischen herkömmlicher, mechanischer Produktentwicklung und Systems Engineering ist das Primat der Funktion gegenüber der Form und Geometrie. Simulation ist der einzige Weg, frühzeitig zu erkennen, ob die ins Auge gefasste Entwicklung von Komponenten in ihrem Zusammenwirken so funktioniert, dass die bei der Systemauslegung zugrunde gelegten Anforderungen erfüllt werden.

Überall werden solche Simulationen heute durchgeführt. In jedem Fachbereich. Oft allerdings getrennt voneinander, also noch nicht in einer Form, die die Beiträge der einzelnen Disziplinen zur jeweiligen Gesamtfunktion gemeinsam darstellt. Viele Kunden nutzen auch bereits Modelica oder eine andere höhere Modelliersprache, um ein komplexes System in seiner Funktion zu simulieren, einschließlich Elektronik, Softwarekomponenten und natürlich auch von Hardware. Aber für Andrew Wertkin ist es eine Tatsache, dass die Industrie noch nicht über einen guten Weg verfügt, die Ergebnisse der Simulationen und Tests und die Zusammenhänge zwischen ihnen zu dokumentieren und im Sinne des Gesamtsystems aufzuarbeiten.

Warum wurde eine Simulation gefahren? Was war im Einzelnen der Input? Was waren die Ergebnisse und der Output? Wenn es eine Diskrepanz gibt zwischen den vorher gestellten Annahmen und dem Ergebnis, wie kam es dazu? Und wenn alle Schlüsse gezogen sind, dann sollten sie für künftige Projekte weitergegeben werden können. Vielleicht wird daraus ein Teil eines künftigen FMEA-Prozesses. Vielleicht resultiert daraus auch eine Art Template für ein bestimmtes Teil.

PTC sieht sich nicht gefordert, neue Werkzeuge zur Simulation zu liefern, sondern Simulationen im Zusammenhang des Systems, seiner Anforderungen und seines Zusammenwirkens zu dokumentieren und ihre Nachvollziehbarkeit zu gewährleisten.

Synchronisation der Disziplinen

Die Synchronisation der Fachdisziplinen, die an einer Systementwicklung beteiligt sind, geschieht durch die Zuordnung von Requirements zu den einzelnen Disziplinen; durch koordiniertes Change Management zwischen den Disziplinen, so dass beispielsweise nachvollziehbar ist, ob eine Änderung in einer Disziplin Auswirkungen auf andere hat; und durch die Koordination von Tests aller Disziplinen.

Viele Tests und Analysen, die in der einzelnen Disziplin auf Komponentenebene durchgeführt werden, haben Einfluss auf das System. Die Ingenieure, die da an ihrem Teil arbeiten, müssen jeweils einen Blick haben auf die anderen Disziplinen. Und sie müssen gleichzeitig in der Lage sein, ihren fachspezifischen Werkzeugkasten zu nutzen, um ihre eigene Arbeit zu erledigen.

Ein Beispiel: In einem Test wurde ein Fehler identifiziert. Er könnte hardwaremäßig beseitigt werden, aber meistens ist es viel günstiger, das Problem mit Hilfe der Software zu lösen. Der Fokus von PTC richtet sich darauf, dass entsprechende Entscheidungen und die zugrundeliegenden Ereignisse zurückverfolgt und mit dem System verknüpft werden können. Andrew Wertkin: „Eine Änderung muss immer beim System ansetzen, so dass Analysen möglich sind. Das ist auch der Hauptgrund, der Systems Engineering zum Bestandteil von PLM macht. Solange die Entscheidungen separat bleiben, ist es kein wirkliches System.“

PLM und Systems Engineering

Bei der Integration von Integrity und Windchill soll das Beste aus beiden Architekturen allen Kunden zur Verfügung gestellt werden. Dabei können sich die beiden Ansätze gut ergänzen. Und PTC kann von Kunden lernen, die diese Integration bereits vor der Übernahme von MKS für sich realisiert haben. So ist Continental einer der größten Kunden sowohl für Windchill als auch auf der Integrity-Seite. Das Ziel ist, den Kunden Lösungen zur Verfügung zu stellen, die funktionieren. Die Integration soll nicht mehr ein Projekt für den Kunden sein, sondern eine Lösung, die ihm angeboten wird.

Einerseits wird auf diese Weise Softwareentwicklung mit all ihren Facetten in den Lebenszyklus eines Gesamtproduktes integriert, was den Weg ebnet, tatsächlich alle Disziplinen einer Systementwicklung als Ganzes zu behandeln. Andererseits wird auch PLM von etlichen Besonderheiten profitieren, die aus der Softwareentwicklung stammen. So soll die Funktionalität des Requirements Managements für Windchill verfügbar gemacht werden.

Die nächsten Schritte der Integration werden in Abstimmung mit einer beratenden Gruppe globaler PTC-Kunden festgelegt. Ihr gehören Unternehmen der Branchen Aerospace & Defense, Fahrzeugbau, Hightech Electronics und Medizingeräte an. Als nächster großer Schritt sind für März 2012 eine erste Integration des Requirements Engineering mit PLM sowie die Verfügbarkeit einer System-Stückliste geplant.

© PLMportal

Add your Content here

Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu.