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?

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

Systems Engineering und der Innovationseffet

Elektronik und Software sind zum Motor der Innovation geworden – nicht nur im Automobil, sondern auch in vielen anderen Produkten. Und wie beim Billard stößt eine Innovation die andere an, auch wenn die Effets nicht immer vorhersehbar ist. Die softe Revolution erlaubt die schnelle Integration von zusätzlichen Funktionen, die den Produktlebenszyklus verlängern, und erleichtern gleichzeitig die funktionale Differenzierung der Produktpalette. Wie viel Pferdestärken ein Motor auf die Straße bringt, das hängt heute auch und vor allem von der eingebetteten Software ab.

Image

In einem Fahrzeug der Oberklasse stecken inzwischen mehr Zeilen Programmcode als in manchem PLM-System. Die eigentliche Herausforderung ist jedoch nicht die Menge an Software, die sich wesentlich schneller entwickeln lässt als andere Produktbestandteile, sondern das perfekte Zusammenspiel von Software, Elektrik/Elektronik und Mechanik. Ihre Abstimmung erfordert neue Werkzeuge, Methoden und Prozesse für die interdisziplinäre Produktentwicklung. Systems Engineering (SE) heißt das Schlagwort, das in aller Munde ist, auch wenn jeder SE-Experte es etwas anders definiert.

Verwunderlich ist die Definitionsvielfalt nicht, denn letztlich geht es genau darum: Erst einmal eine gemeinsame Sprache zu finden. Eine gemeinsame Sprache, mit der man komplexe Produkte als Gesamtsystem beschreiben und überprüfen kann, unabhängig davon, wie und mit welchen Werkzeugen die beschriebenen Funktionen und Eigenschaften nachher umgesetzt werden. Eine Sprache, die es den unterschiedlichen Disziplinen erlaubt, ein gemeinsames Verständnis für die bestehenden Abhängigkeiten zwischen Anforderungen, Funktionen, Bauteilen etc. zu entwickeln und gerade bei Änderungen einfacher miteinander zu kommunizieren. Sozusagen ein Esperanto für die Produktentwicklung.

Ganz gleich welche Sprache(n) und Sprachwerkzeuge zum Einsatz kommen, müssen sie in die Product Lifecycle Management-Lösungen integriert werden, um die beschriebenen Anforderungen und die daraus abgeleiteten Funktionen und Eigenschaften des Produkts über den gesamten Entwicklungsprozess verfolgen und die Wechselwirkungen von Änderungen beurteilen zu können. In diesem Sinne ist das Systems Engineering zum Motor für die Innovation der PLM-Technologie geworden, die lange Zeit einseitig auf die Datenverwaltung und Prozessteuerung in der Mechanikentwicklung fokussiert war. Die meisten PLM-Lösungen unterstützen heute ein disziplinenübergreifendes Anforderungs-Management und ermöglichen die Abbildung einer funktionalen Sicht auf das Produkt.

Anforderungen abzubilden und in Beziehung zu anderen Anforderungen, Funktionen, Bauteilen etc. zu setzen, ist weniger eine technische Herausforderung. Die PLM-Datenmodelle sind dafür ausreichend flexibel. Die Kunst besteht darin, dies so zu tun, dass die Systeme für die Anwender noch bedienbar sind. Oder anders ausgedrückt: Zu vermeiden, dass man den Teufel mit dem Belzebub austreibt. Schließlich soll das Systems Engineering die Komplexität der Produktentwicklung besser beherrschbar zu machen. Wenn die IT-Werkzeuge zur Unterstützung der Systementwicklung dadurch so komplex werden, dass sie für die Anwender kaum noch zu beherrschen sind, ist nichts gewonnen.

Die PLM-Hersteller müssen sich darüber Gedanken machen, wie sie die Definition der Beziehungen zwischen Anforderungen und anderen PLM-Objekten und vor allem die Visualisierung der komplexen Zusammenhänge besser unterstützen. Die Anwender benötigen komfortable grafische Eingabehilfen und neue Peripheriegeräte mit taktilen Oberflächen, um die Beziehungsgeflechte großformatig darstellen und mit ihnen direkt interagieren zu können.  Mit anderen Worten genau die Art von Produkten, deren Entwicklung ein interdisziplinäres Vorgehen im Sinne des Systems Engineering erfordert.