Wir machen hier fast nahtlos weiter. Stellen Sie sich nur einmal für einen Augenblick vor, sie haben einen Seifenspender in Ihrer Toilette, der jedes Mal, wenn Sie ihn brauchen, in das Becken hineinkippt und erst für weiteren Gebrauch 'repariert' werden muss.

Da überlegen Sie doch auch nicht, nur einen neuen Seifenspender anzuschaffen. Die Lösung scheint doch zu sein, den nächsten an der Wand zu befestigen, oder? Sehen Sie, und genau so eine Teillösung für ein viel größeres Problem stellt das Konzept der 'Middleware' dar.

Ja, wie der Name schon sagt, sie befindet sich mittendrin. Und das Problem, das sie löst, ist durchaus mit dem bei alten Seifenspender zu vergleichen. Es ist der Kampf mit der Hardware, den jede(r) Programmierer/in auszufechten hat, die hardwarenah arbeiten muss.

Wir machen es uns gemütlich und nehmen diesmal ein Beispiel aus den Anfängen der Computertechnik. Der erste von Konrad Zuse brauchte gestanzte Löcher auf 35 mm breiten Filmrollen, um überhaupt das Problem zu verstehen, das er bearbeiten sollte.

Bei der zweiten, der revolutionären Maschine von Alan Turing konnten die Bits schon per Knopfdruck eingegeben werden. Da Ergebnis erschien dann ebenfalls in Bitform. Als eine große Erleichterung mag man es empfunden haben, komplette Bytes oder sogar hexadezimale Zahlen eingeben zu können.

Bei den Programmen musste man aber immer noch Befehle, die der Computer verstand, als Zahlen denken. Erst Compiler ergaben die Möglichkeit, von der reinen Maschinensprache wegzukommen. Man fing an, zu verstehen, was man selbst oder andere da programmiert hatten.

Nein, wir machen jetzt nicht weiter bis zu modernen Programmiersprachen, sondern konstatieren, dass es Möglichkeiten gibt, Programme zu schreiben, ohne sich um die Besonderheiten der zugrunde liegenden Hardware zu kümmern. Sie können sich die Vorteile sicherlich vorstellen.

Jetzt gibt es aber im Auto nicht nur Sensoren, Aktuatoren, sondern auch Controller, Treiber, Timer, Busse und Speicher und die müssen immer wieder im Laufe eines zu erstellenden Programms angesprochen werden. Wie schön wäre das, man könnte sich ignorant gegenüber diesen stellen.

Und genau diese Brücke baut dem/der Programmierer/in die Middleware. Aber natürlich hält sie nicht nur Vorteile für diese Gruppe bereit, sondern erleichtert entscheidend auch die Austauschbarkeit. Hardware und Middleware ändern sich, Anwendungssoftware nicht.

Übrigens, Automotive Middleware gab es schon, da dachte man noch gar nicht an das softwarebasierte Auto, obwohl es eine softwarebasierte Ebene ist. Middleware wurde umso nötiger, als im Auto Systeme mit verschiedenen Arten der Kommunikation aufeinandertrafen.

So entstanden CAN, LIN, FlexRay und Ethernet fürs Auto, den Bereich der Vernetzung betreffend. Ein Ethernet-Protokoll ist z.B. Salable Service-Oriented Middleware over Intergrated Platform. IP ist also eine Plattform, die Datenaustausch zwischen Anwendungen ermöglicht.

Während Netze im Auto zwar schnell sind, betritt man mit dem Data Distribution Service die Bereiche extrem niedriger Latenz- bzw. Reaktionszeiten. Es gibt keinen Master, hier 'Broker' genannt. Als Beispiel möge der Austausch von Daten vor Entscheidungen zum Autonomen Fahren dienen.

Beim Message Queung Telemetry Transport geht es um die datenmäßige Anbindung nach draußen, z.B. zu einer Cloud oder Over The Air. Es ist sehr wohl brokerbasiert, gilt aber als 'leichtgewichtig', also einen eher geringeren Overhead benötigend. Im Gegensatz zu DDS ist es nicht echtzeitfähig.

Zum Schluss noch Diagnostics over IP. Ethernet, schnelleres Übermittlungssystem als CAN-Bus, ermöglicht Werkstätten mehr Tempo bei der Analyse von Fehlern und sogar die inzwischen z.B. vom Werk durchgeführte Analyse am Auto in der Werkstatt.