Systems Engineering

Brauchen smarte Produkte neue PLM-Systeme?

Auf dem jüngsten ProSTEP iViP-Symposium gab es eine interessante Podiumsdiskussion zum Thema Smart Engineering, in der hochkarätige Vertreter aus Wissenschaft und Forschung ziemlich offen die Immobilität der PLM-Hersteller angesichts der Herausforderung des Internet of Things (IoT) und der Entwicklung smart vernetzter Systeme kritisierten. O-Ton eines Teilnehmers: „Wir bräuchten Player mit neuen Ideen, die frischen Wind in den Markt bringen.“ Es fehle eine Art Google, der den ganzen PLM-Markt aufrolle, meinte ein andere. Welcher Hafer hat die denn gestochen?, dachte ich mir.

Einer der Vorwürfe an die Adresse der PLM-Hersteller, der aus dem Mund staatlich alimentierter und geförderter Wissenschaftler natürlich etwas befremdlich klingt, ist der, dass sie bei der Weiterentwicklung ihrer Systeme zu wenig in Vorleistung treten und immer nur das entwickeln, mit dem sich ziemlich unmittelbar Geld verdienen lässt. Abgesehen davon, dass Altruismus nicht unbedingt eines der Wesensmerkmale kapitalistischer Systems ist, halte ich den Vorwurf für nicht ganz zutreffend.

Erstens kenne ich den einen oder anderen PLM-Hersteller, der seine Software bereits um Module für Anforderungsmanagement, Funktionsmodellierung und andere Systems Engineering-Funktionen ergänzt hat, die sich nicht gerade verkaufen wie warme Semmeln.
Zweitens haben die wenigen Anwendervorträge zum Thema Systems Engineering auf dem Symposium einmal mehr deutlich gemacht, dass die Unternehmen immer noch in einer Findungsphase stecken und erst einmal klären müssen, was sie an IT-Unterstützung für die Entwicklung ihrer smarten Produkte benötigen. Ein Eindruck, der durch die Interviews bestätigt wird, die ich in den letzten Jahren zu dem Thema geführt habe.
Drittens wissen auch die Wissenschaftler noch nicht so genau, welche Partialmodelle aus der modellbasierten Entwicklung cyberphysischer Systeme mit welchen Informationen eigentlich ins PLM-System gehören. Sonst bräuchten wir ja wohl dotierte Forschungsprojekte wie mecPro² nicht, die genau das herausfinden sollen.

Richtig ist natürlich, dass die PLM-Hersteller genauso wie ihre Kunden gefordert sind, sich mit den Auswirkungen des IoT auf ihre Geschäftswelt auseinanderzusetzen. Sie müssen ihr Lösungsangebot anpassen, um agilere und kontinuierlichere Entwicklungsprozesse zu unterstützen, wie Stan Przybylinski von der amerikanischen Markforschungsfirma CIMdata kürzlich in einem Webinar zum Thema „The Internet of Things – What does it mean for PLM“ betonte. Doch was heißt das konkret für die Entwicklung der PLM-Software? Muss sie künftig in der Lage sein, unstrukturierte Informationen zu verwalten oder Unmengen an Sensordaten zu analysieren? Ich glaube, dafür sind andere Anwendungen besser geeignet.

Das IoT verspricht Wachstum ohne Ende. Grafik: CIMdata Inc. — Das IoT bietet ein riesiges Wachstumspotential, vor allem für industrielle Anwendungen. Grafik: CIMdata Inc.

Hauptaufgabe der PLM-Systeme ist und bleibt die Unterstützung der Produktentwicklung. Das Problem ist nicht so sehr, dass diese Produkte immer mehr Elektronik und Software enthalten, die sich ständig ändert, sondern dass Elektronik und Software zunehmend genutzt werden, um Produkte mit anderen Produkten und Systemen zu vernetzen und ihren Lebenszyklus dadurch weit über den Start of Production hinaus zu verlängern. Im Sinne eines vollständigen Product Lifecycle Managements muss auch diese Phase systemseitig unterstützt werden.

Das wirkliche Produktleben lag für die Hersteller bislang auf der „dark side of the moon“, wie PTC-Chef Jim Heppelman sich einmal ausdrückte. Dieses Leben besser auszuleuchten, das heißt die Informationen aus dem Feld auszuwerten, in den Lifecycle einzusteuern und für die kontinuierliche Verbesserung der Produkte zu nutzen, das ist die riesige Chance des IoT und die wahre Herausforderung für die PLM-Hersteller. Es geht nicht um die Entwicklung oder Integration von noch ein paar Systems Engineering-Werkzeugen mehr, sondern um die Vernetzung der PLM-Systeme mit den IoT-Plattformen, auf denen diese Lifecycle-Informationen zusammenfließen.

Welche Plattformen das sein werden, ist noch ziemlich offen. Aber wenn man sich vor Augen hält, dass IBM mal eben schlappe drei Milliarden US-Dollar in den Aufbau einer eigenen IoT-Organisation investiert, kann man sich ungefähr ausmalen, welches Kaliber die Player in diesem Markt haben werden. Ein Markt über dessen Größe die aberwitzigsten Zahlen kursieren. Cisco sprich von 19 Billionen US-Dollar im Jahr 2020, McKinsey immerhin noch von 2,7 bis 6,2 Billionen. Einig sind sich alle Auguren, dass der größte Anteil davon auf die Fertigung entfallen wird: Vielleicht war das mit Industrie 4.0 doch keine so schlechte Idee.

Viel Lärm um Nichts

Von meiner letzten Reise in die USA habe ich ein tolles, neues Schlagwort mitgebracht: Servitization. Es beschreibt die beinahe kafkaeske Verwandlung von Produkten, die immer mehr eingebettete Software enthalten und über das Internet der Dinge miteinander kommunizieren, in hybride Produkt- und Serviceangebote. Im Extremfall kauft der Gebäudebetreiber keine Klimaanlage mehr, sondern zahlt für die Klimatisierung eines bestimmten Raumvolumens. Der Hersteller übernimmt die Verantwortung für die korrekte Auslegung der Klimatechnik und die Wartung der Anlage. Sie ist mit zig Sensoren ausgestattet und meldet Unmengen an Daten zurück, aus denen intelligente Software-Lösungen dann die Auffälligkeiten (z. Bsp. ein offenes Fenster) herausfiltern.

An diese Brave New World musste ich denken, als ich in meinem Appartementzimmer in New York morgens um 5 Uhr durch die ratternde Klimaanlage geweckt wurde. Genau genommen wurde ich nicht durch sie geweckt, sondern durch den Verkehrslärm auf der 3rd Avenue, der etwa ab dieser Uhrzeit die Klimaanlage übertönte. Wer New York kennt, kennt auch die etwas vorsintflutliche Gebäudetechnik: Die mehrfach verglasten Schiebefenster werden einfach hochgeschoben und fest arretiert, um die kastenförmigen Klimaanlagen einzubauen, womit zwar das Leben des Untermieters gesichert ist, nicht aber das eigene Überleben im Brandfall, weil der Zugang zur traditionellen Feuerleiter vor dem Fenster blockiert ist. Es sei denn, man schafft es, sich durch den engen Spalt rechts oder links des Geräts zu zwängen, der nur mit einer dünnen Plastikblende verschlossen ist. Schall- und Wärme-Isolierung gleich null.

Alte und neue Fassaden in New York. Bild: Wendenburg

Vergeblich versuchte ich, den Kopf unter das Kopfkissen zu stecken und noch ein bisschen weiter zu schlafen. Mein unsanft aufgeweckter Geist suchte fieberhaft nach einer innovativen Lösung zur Senkung des Geräuschpegels. Kissen in die Aussparungen rechts und links neben der Klimaanlage zu knuffen, war weder besonders innovativ noch effektiv. Mir kam der Vortrag eines hochrangigen Airbus-Mitarbeiters über des Kabinenkonzept für das Jahr 2050 in den Sinn: Die komfortablen Sitze im Airbus der Zukunft sollen durch Gegenschallwellen von plärrenden Kindern und schnarchenden Nachbarn abgeschottet werden. Wenn man doch die amerikanischen Klimaanlagen mit Geräuschsensoren ausstatten und die Schallwellentäler des notorischen Brummens mit den Wellenbergen des Straßenlärms synchronisieren könnte? Das wäre wirklich mal eine Innovation, die diesen Namen verdient, mit schön viel Elektronik und eingebetteter Software.

Man könnte die Vision noch weiter spinnen und aus den Big Data sämtlicher New Yorker Klimaanlagen und ihren Positionsinformationen die Verkehrsdichte der jeweiligen Avenue berechnen, um die Verkehrströme in der Stadt besser zu lenken. Das Verkehrschaos in New York ist zu bestimmten Zeiten nämlich unbeschreiblich. Die Klimaanlage würde zum Herzen eines komplexen cyberphysischen Verkehrsleitsystems. Es darf nur keiner auf die Idee kommen, den Straßenbelag auszubessern, um den Geräuschpegel zu senken. Das würde die Berechnung total verfälschen.

Was ich eigentlich damit sagen will, ist dass die technischen Innovationen im allgemeinen und ganz besonders das Internet der Dinge mit einer gewissen Zwanghaftigkeit zur Entwicklung von immer komplexeren Systemen führt. Das mag zwar gut sein für die Hersteller von PLM- und Service Lifecycle Management-Systemen, die davon leben, diese Komplexität wieder beherrschbar zu machen. Aber manchmal fragt man sich wirklich, ob es unbedingt notwendig ist, auch noch die letzte Glühbirne mit Internet-IP und Wifi-Ersatz auszustatten, um sie über eine App in unserem Smartphone individuell ansteuern zu können? Auch ohne den ökologischen Fußabdruck mit PLM berechnet zu haben, bin ich mir ziemlich sicher, dass Entwicklung und Fertigung dieser smarten Produkte mehr Gehirnschmalz und Energie verbraucht haben als sie je in ihrem Lifecycle einsparen werden.

Homo informaticus hat ein quasi sado-masochistisches Verhältnis zur Komplexität. Wir jammern ständig darüber, dass alles immer komplexer wird, lassen uns aber wollüstig stöhnend von Complexitas in Ketten legen. Zum Glück gibt es Rettung. Im Jahr 2020 sollen bereits 70 Prozent der weltweiten Nachfrage nach Gütern und Dienstleistungen aus den Emerging Countries kommen. Im Zuge von Globalisierung und Personalisierung der Produktentwicklung bringen die Unternehmen immer mehr Produkte für diese Länder auf den Markt, deren Innovation im wesentlichen darin besteht, dass sie einfacher und kostengünstiger sind. Und plötzlich stellt man fest, dass es in unserer entwickelten Welt dafür einen Markt gibt und importiert sie zurück. Auch dafür haben die Amis ein schönes Schlagwort kreiert: Reverse Innovation.

Beim Systems Engineering menschelt es

Wenn man verstehen will, warum Systems Engineering so in Mode ist, braucht man sich nur Produkte anzuschauen, mit denen wir uns täglich umgeben. Nicht nur im Automobil, sondern auch in Hausgeräten, medizintechnischen Apparaten oder Maschinen und Anlagen stecken immer mehr Funktionen, die durch Elektronik und Software gesteuert werden. Von elektronischen Konsumgütern ganz zu schweigen. Damit sind Elektronik und Software auch zur wichtigsten Ursache möglicher Fehler und Fehlfunktionen geworden.

Ein Beispiel? Mit meinem neuen Smartphone kann man kommunikationstechnisch so ziemlich alles machen, was man sich vorstellen kann – nur eines nicht: Telefonieren. Die Sprachqualität ist so hundsmiserabel, dass man sie nicht mal mit dem Umstand entschuldigen kann, dass es sich um ein vergleichsweise kostengünstiges Einsteigermodell handelt. Im Vergleich dazu bietet selbst mein dummes altes Finnen-Handy geradezu HiFi-Klangqualität. Nun frage ich mich natürlich, wer dieses Desaster zu verantworten hat?

Immer mehr funktionsfähige Mobiltelefone werden ausrangiert. (Bild: iStocks)

Schuld bin natürlich in erster Linie ich selbst, weil ich die Katze im Sack gekauft habe bzw. den wohlwollenden Kritiken bei Amazon & Co. vertraut habe. Die waren bestimmt gesponsert. Aber in welchem Handyladen kann man die Geräte überhaupt noch testen? Geschweige den so ein ausgefallenes Gerät wie mein Dual Sim-Handy, das die Möglichkeit bietet, parallel zwei SIM-Karten zu betreiben. (Na ja, nicht wirklich parallel, wie ich inzwischen weiß). So ein Gerät scheuen die Provider wie der Teufel das Weihwasser, weshalb man sie auch nie im normalen Sortiment findet.

Der Hauptschuldige ist allerdings der Hersteller, dessen koreanischen Namen ich an dieser Stelle verschweigen möchte. Oder genauer gesagt, die Produktentwickler des betreffenden Unternehmens, die das Systems Engineering, das heißt die interdisziplinäre Entwicklung von komplexen mechatronischen oder cybertronischen Produkten wohl noch nicht so ganz beherrschen. Wobei kurioserweise die cybertronischen Systemkomponenten, die mein Handy wunderbar mit anderen Systemen vernetzen, wesentlich besser funktionieren als so banale Bauteile wie Mikrofon oder Lautsprecher. Von der Kameralinse ganz zu schweigen, die man getrost vergessen kann.

An welcher Stelle im Systems Engineering-Prozess das Desaster bei der Sprachübertragung meines Handys seinen Ausgang nahm, ist mir nicht ganz klar. Ich vermute mal schon im Requirements Engineering bzw. bei der Definition der Testkriterien zur Absicherung der Anforderungen. Vielleicht haben die Systemingenieure auch bei der Modellierung der Systemarchitektur mit SysML übersehen, dass sie die vorhandenen Systemfunktionen für die Sprachübertragung in einem neuen Kontext nicht einfach wieder verwenden können, sondern simulieren müssen, ob sie Zusammenspiel mit den neuen Funktionen noch ihren Dienst versehen. Dabei sollte doch klar sein, dass ein leistungsfähiges Konfigurationsmanagement der Schlüssel zur Wiederverwendung der SE-Artefakte darstellt.

Ich möchte an dieser Stelle also mal einen Engineering Change Request stellen, mit der Bitte, die Funktionen zur Sprachübertragung meines Handys in der nächsten Generation deutlich zu verbessern. Sonst muss ich schon wieder den Hersteller wechseln, was immer mit einem riesigen Aufwand für die Datenmigration verbunden ist. Nicht dass ich große Hoffnungen hege, dass mein ECR zügig in einen Änderungsantrag einfließen wird. Und selbst wenn, dann hätte die Änderung wahrscheinlich ungeahnte Folgen für andere Systemfunktionen. Dann könnte man vielleicht wieder wunderbar telefonieren, aber nicht mehr so gut navigieren.

Ein Tipp an den Hersteller: Um die Auswirkungen von solchen Änderungen frühzeitig beurteilen zu können, müssten die Werkzeuge und Methoden des Systems Engineering nahtlos in die PLM-Umgebung integriert werden, mit der die Änderungsprozesse gesteuert werden. Das weiß man zwar, aber davon sind die meisten Unternehmen noch ziemlich weit entfernt. Oder wie einer meiner Gesprächspartner neulich sagte: „Human Based Systems Systems Engineering machen wir schon lange. Jetzt geht es darum, in den IT-Systemen bzw. den zugrunde liegenden Modellen die Traceablílity zu erreichen.“