Die 6 Probleme mit standardisierten Schnittstellen

Für Systems Engineers können standardisierte Schnittstellen ein Segen sein, denn diese bieten viele Vorteile. Sie erlauben das Kaufen von fertigen Komponenten, zum Beispiel eines Motitors, der über eine HDMI-Schnittstelle angeschlossen wird. Neue Technologien können leicht integriert werden, zum Beispiel LED-Technik statt LCDs. Bei einem Problem kann die Komponente schnell ersetzt und die die defekte Komponente in Ruhe repariert werden. Doch standardisierte Schnittstellen bergen auch Gefahren.

Physikalische und elektrische Schnittstellen – und dann noch Software

Zunächst muss zwischen physikalischen, elektrischen und Software-Schnittstellen unterschieden werden. Physikalische Schnittstellen sind seit Hunderten von Jahren im Betrieb, zum Beispiel die Spurbreiten in der Eisenbahn. Auch die Automobilhersteller haben schon vor 20 Jahren erfolgreich Fahrzeugplattformen eingeführt, die aber primär die physikalische Form standardisiert und mit Schnittstellen versehen haben. Das betraf dann Elemente wie Schrauben, Scharniere, usw. Kurz: wir beherrschen schon lange die physikalischen Schnittstellen.

Elektrische Schnittstellen beherrschen wir ebenfalls schon lange. Doch hier ist weniger sichtbar ob etwas passt oder nicht. Denn nur, weil ein Stecker in eine Steckdose passt wissen wir nicht, ob auch auf der elektrischen Ebene alles richtig läuft. Das weiß jeder, der schon mal einen Hohlstecker mit einer zu hohen Spannung an ein Kleingerät angeschlossen hat.

Zuletzt gibt es noch die Software-Schnittstelle, oder Application Programming Interface (API). Diese sind in der Regel um Größenordnungen komplexer als die zuvor beschriebenen.

Mischung der Schnittstellen

Die drei eben beschriebenen Arten von Schnittstellen können selbstverständlich auch kombiniert werden. Bei einer normalen Steckdose haben wir es mit einer Schnittstelle zu tun, die sowohl physikalische als auch elektrische Ausprägungen hat. Bei einem Standard wie USB spielen alle drei zusammen.

Gerade bezüglich des Internets der Dinge ist dies eine Herausforderung, weshalb ich kürzlich dazu schrieb im Artikel Die Summe ist mehr als die Teile: Orchestrierung für das Internet der Dinge.

Standardisierung

Standards sind „standardisiert“ – daher der Name. Doch auch hier gibt es Unterschiede. Im besten Fall ist eine gemeinnützige Organisation verantwortlich für den Standard, wie bspw. die Object Management Group (OMG), die auch die SysML und ReqIF standardisiert hat. Die Standards sind offen und entweder kostenfrei, oder über eine Gebühr zugänglich.

Auch Firmen schaffen Standards und pflegen diese. Lange Zeit wurde zum Beispiel Java von der Firma Sun (heute Oracle) gepflegt, ist allerdings inzwischen auch in der Hand einer Foundation.

Und zuletzt können sich Standards auch implizit formen, bzw. aus einer Implementierung abgeleitet werden. Bei mehreren Programmiersprachen gibt es eine Referenz-Implementierung, die dann für das standardisierte Verhalten verbindlich ist. Hier ist es hilfreich, wenn diese Implementierung quelloffen ist (Open Source).

Die Probleme mit Schnittstellen

Leider läuft es nicht immer so, wie wir es uns wünschen. Und auch das haben wir alle sicher schon in der einen oder anderen Form erlebt. Im Folgenden soll es nicht um triviale Probleme gehen: Zum Beispiel, dass ein amerikanischer Stecker ohne Adapter nicht in eine deutsche Steckdose passt. Hier geht es um die subtileren Probleme.

Es kommt häufig vor, dass es mehr als einen Standard gibt. Auch da sind Steckdosen wieder ein wunderbares Beispiel. Diesem Problem kann man mit Adaptern zu Leibe rücken, jedoch ist das nicht immer so einfach wie bei der Stromversorgung. Denn gerade komplexere Standards haben oft eine Ausprägung für bestimmte Anwendungsfälle, so dass sich nicht alle Funktionen abbilden lassen. Mathematisch gesprochen können zwei Standards zwar eine gemeinsame Schnittmenge haben, aber es gibt Funktionen, die der andere Standard nicht kann. So war es in den 90ern mit Zeichensätzen, die lediglich den westlichen Zeichensatz gemeinsam hatten (ASCII), aber weitere Zeichen enthielten die sich nicht aufeinander abbilden ließen. Dieses Problem wurde heute mit dem Unicode-Standard gelöst.

Solche Situationen können zu dem Versuch führen, einen neuen Standard zu erstellen, der alle Szenarien abdeckt. Bei Unicode hat es funktioniert, doch häufig geht es auch schief, wie dieser Cartoon zeigt:

Bildquelle: xkcDE, CC-BY-NC

Um noch mal das Beispiel mit dem Hohlstecker: Hier wurde zwar die Form standardisiert, jedoch nicht die Spannung. Wenn man nicht aufpasst, schließt man ein 24V-Netzteil an ein Gerät an, das für 5V ausgelegt ist. In diesem Beispiel würde mit großer Wahrscheinlichkeit das Gerät zerstört werden.

Ein ähnliches Problem bestand (und besteht!) mit dem European Train Control System, ein Standard für den grenzübergreifenden Zugverkehr. Markus Boll berichtete auf dem TdSE 2016 über die Probleme.

Besonders bei Software ist es ein Problem, dass diese kontinuierlich weiterentwickelt wird. Die neuen Features sollen dann möglichst über die Schnittstelle auch nach außen weitergegeben werden, doch das würde ja die Schnittstelle verändern.

Heutzutage werden Softwareschnittstellen typischerweise versioniert, wodurch das Problem stark abgefedert wird. Das war nicht immer so, und in der Anfangszeit von Windows wurden Programmbibliotheken nicht standardisiert, was als DLL-Hölle bezeichnet wurde.

Idealerweise sollte eine Komponente eine „Black Box“ sein, die über die Schnittstellen beschrieben wird und dessen Innenleben man nicht erkennen kann (oder soll). Doch in der Praxis schlagen doch hin und wieder Eigenschaften aus dem Innenleben nach außen durch. Ein Beispiel dazu sind Trafo- und Schaltnetzteile, die sich je nach Belastung sehr unterschiedlich verhalten können.

Gerade bei Software (APIs) kommen oft Implementierungsdetails durch, was gerne von Crackern für illegale Aktivitäten missbraucht wird.

Manchmal werden Standards von Firmen erschaffen und kontrolliert. Das muss kein Problem sein, kann aber eines werden. Es hängt ein bisschen davon ab, warum die Firma den Standard geschaffen hat. Zum Beispiel stellen viele Softwares Schnittstellen zur Integration zur Verfügung. Da hier eine Einladung zur Integration gemacht wurde kann davon ausgegangen werden, dass der Standard ordentlich gepflegt wird. Doch vielleicht wird die Firma akquiriert und die Schnittstelle vom neuen Eigner stillgelegt, um den Markt der Integratoren selbst zu bedienen?

Noch extremer ist der Fall, wo der Hersteller die Schnittstelle eigentlich gar nicht veröffentlichen möchte, zum Beispiel bei Tintenpatronen für Drucker. Dort findet dann oft ein Katz-und-Maus-Spiel zwischen dem Hersteller des Geräts und des Herstellers von Whitelabel-Patronen statt.

Unter diesem Begriff wurde die Technik von Microsoft bezeichnet, Standards in einer Art und weise zu erweitern, so dass aus einem offenen Standard eine proprietärer wurde. Oder um den Standard sterben zu lassen.

Fazit

Diese Liste ist wahrscheinlich nicht vollständig, gibt aber einen Überblick über die wichtigsten Probleme, die mit Standards auftauchen können. Doch trotz allem sind standardisierte Schnittstellen eine Bereicherung und ein extrem nützliches Mittel für den Systems Engineer.