Interview mit ARMs Firmengründer und CTO Mike Muller »Kein mbed-OS für konkurrierende Architekturen«

ARM stellte zwei SW-Komponenten für das IoT vor, mit denen Daten von Endknoten sicher in die Cloud gebracht werden können. Im Exklusiv-Interview mit der Elektronik ging es auch um die Abgrenzung von ARM zu der von Intel dominierten Big-Data-Analyse.

Elektronik: Als ich Ihre Übersichts-Folie von mbed-OS das erste Mal gesehen habe, war mein Eindruck, ARM fokussiert sich in der IoT-Wertschöpfungskette auf die linke Seite („little Data“) mit der Datenerfassung und –Übertragung und Intel auf die rechte Seite („big Data“) mit Datenanalyse in der Cloud. Stimmen Sie mir zu?

Mike Muller: Wir fokussieren uns in der Tat auf die Frage, wie bekommen wir „little Data“ in die Cloud, dazu brauchen wir mbed-OS und mbed-Server. Sie haben auch Recht, wir wollen nicht mit Firmen, die Big-Data-Analyse betreiben, konkurrieren.

Elektronik: Dann kommen wir zu mbed-OS. Wie stellte sich die Entwicklung dar?

Muller: Die Grundlagen wurden in einem Forschungsprojekt in unserer Forschungs-Gruppe bei ARM gelegt, dann kam die Tools-Gruppe dazu, denn mbed-OS setzt ja auch CMSIS auf.

Elektronik: Sie sagen, mbed-OS läuft auf Cortex-M-basierenden Controllern, gilt das wirklich für alle Cortex-M-Cores vom M0+ bis hin zum M7?

Muller: mbed-OS nutzt nicht die DSP-Erweiterungen des M4 oder M7, der M0+ reicht vollkommen aus, realistisch benötigen Sie RAM-Speicher im zweistelligen Kilobyte-Bereich und 128 KB Flash, möglicherweise etwas mehr, wir sind noch dabei, das zu optimieren. Nichtsdestotrotz ist das sicherlich die Untergrenze, wir haben das Thema Security von Grund auf neu entwickelt und es gibt eine Untergrenze dafür, was Sie benötigen, um eine wirklich sichere Datenübertragung garantieren zu können.

Elektronik: Die Konnektivität ist sehr flexibel, d.h. Sie unterstützen mehrere Standards, die unterschiedliche Software-Stacks benötigen. Liefern Sie unterschiedliche Derivate von embed-OS aus?

Muller: Lassen Sie es mich so sagen: mbed-OS ist Teil eines Build-Systems, bei dem Sie die benötigten Komponenten auswählen und das Ihnen dann Ihr mbed-OS zusammenstellt.

Elektronik: Gibt es eine grafische Benutzeroberfläche, wo Sie als Kunde einfach per Drag-und-Drop Ihr Wunsch-mbed-OS zusammenstellen?

Muller: Nein, es ist kein Mathlab, die Anzahl der Auswahlmöglichkeiten ist auch sehr limitiert, es handelt sich um ein Script-basierendes System. Sie sagen dem Programm, ich brauche diese und jene Komponenten, und dann wird das Ganze mit Ihrem Anwendungsprogramm zusammengelinkt.

Elektronik: mbed-OS ist kostenlos für ARM-Cortex-M-basierende Controller. Was würde passieren, wenn ein Wettbewerber von Ihnen z.B. Imagination kommen würde und sagen, ich möchte mbed-OS für MIPS-CPUs lizensieren? Würden Sie eine Lizenz zu einem realistischen Preis verkaufen?

Muller: Wir haben kein Interesse, mbed-OS für konkurrierende Architekturen zu lizensieren. Wir haben es architektonisch total auf Cortex-M optimiert. Wenn Sie ein System offen halten wollen, müssen Sie Portabilität architektonisch von Grund auf berücksichtigen. Das generiert Overhead, den wir nicht wollten. Es geht gar nicht um die wirtschaftlichen Fragen, mbed-OS ist technisch nicht portabel gebaut.

Elektronik: Jetzt ist es ja so, dass Cortex-M3/M4 im Vergleich zum M0+ einen erweiterten Befehlssatz aufweisen. Heisst das, dass mbed-OS diesen gar nicht nutzen kann?

Muller: Natürlich können Sie das Projekt für Ihre Ziel-CPU kompilieren, aber Sie haben Recht, auf unterster Ebene gibt es einige handcodierte Low-Level-Routinen in Assembler-Code, der nur auf den Minimal-Befehlssatz des Cortex-M0 zurückgreift.

Elektronik: Welche CPUs sehen Sie eigentlich primär in den von Ihnen addressierten IoT-Anwendungen für „little Data“? Nur M0+ und M0?

Muller: Wir sehen auch den Cortex-M3.

Elektronik: Der Zugriff auf mbed-OS erfolgt mit Hilfe von APIs. Für welche Funktionen haben Sie APIs entwickelt? Geht es um die intelligente Aufbereitung von Roh-Sensordaten?

Muller: Nein, es obliegt ja der Anwendung zu entscheiden, wieviel Intelligenz ich am Sensor-Knoten implementieren will und ob ich mehr Rohdaten oder schon vorverarbeitete Daten in die Cloud schicken will. Daher haben wir uns auf die Datenübertragung in die Cloud konzentriert.

Elektronik: Die zweite Komponente ist der mbed-Device-Server. Was genau tut der?

Muller: Ich möchte das am Beispiel einer Kaffeemaschine erläutern. Nehmen Sie an, Sie sind daran interessiert, zu wissen, wieviele lila Kaffee-Kapseln verbraucht wurden. Um an diese Info ranzukommen, müssen Sie über das Internet an die Maschine herantreten und ihr sagen, bitte liefere mir die Zahl. Während auf der Seite der Kaffeemaschine die Software prüfen muss, ob eine lila Kapsel verbraucht wurde und über die APIs eine Erhöhung der lila Kapseln um eins versenden muss, muss sich der Anwendungsprogrammierer auf der mbed-Device-Seite um die ganzen Übertragungsprotokolle, Sensoren etc. nicht kümmern: Er sagt einfach, nenne mir die Zahl der lila Kapseln.

Elektronik: Wie der Programmierer Software auf das Device und den Device-Server verteilt, interessiert Sie nicht?

Muller: Richtig, das obliegt dem Entwickler. Wir stellen mit beiden Komponenten nur sicher, dass er sich um die sichere Datenübertragung über das Internet nicht zu kümmern braucht.

Elektronik: Dann bleibt noch die Schnittstelle zu Big-Data-Analyse z.B. von IBM…

Muller: Richtig. Für den mbed-Device-Server ist sichergestellt, dass alle diese Daten für die Datenbank-Software gleich aussieht, egal ob Daten von Millionen Kaffeemaschinen, Strassenleuchten oder Pumpen eingesammelt wurden. IBM muss sich nicht mehr um die Millionen unterschiedliche Endgeräte kümmern.

Elektronik: Herr Muller, vielen Dank !