Bill Lamie, CEO von Express Logic „Echtzeitbetriebssysteme haben eine gute Zukunft“

Redakteur: Franz Graser

Nur wenige Insider kennen das Echtzeitbetriebssystem-Segment (RTOS) so gut wie Bill Lamie, der CEO der amerikanischen RTOS-Schmiede Express Logic. Der Schöpfer diverser kommerziell erfolgreicher Echtzeitsysteme plaudert aus dem Nähkästchen.

Firmen zum Thema

William „Bill“ Lamie ist der Mitbegründer und CEO des US-Betriebssystemherstellers Express Logic. Er entwickelte das Echtzeitbetriebssystem ThreadX, das von Express Logic vertrieben wird, und das RTOS Nucleus, das Mentor Graphics heute vermarktet.
William „Bill“ Lamie ist der Mitbegründer und CEO des US-Betriebssystemherstellers Express Logic. Er entwickelte das Echtzeitbetriebssystem ThreadX, das von Express Logic vertrieben wird, und das RTOS Nucleus, das Mentor Graphics heute vermarktet.
(Bild: Express Logic)

Mister Lamie, was sind aus Ihrer Sicht die wichtigsten Entwicklungen im Embedded-Umfeld?

Das größte Ding ist im Augenblick die Middleware. Praktisch alles ist miteinander verbunden, entweder über TCP/IP oder USB oder Ähnliches. Deswegen würde ich sagen: die äußeren Schichten von Echtzeitbetriebssystemen (RTOS) sind wahrscheinlich die dicksten Dinger.

Die andere große Sache ist ARM. ARM ist überall, das ist eine unglaubliche Erfolgsgeschichte. Ich habe vor Jahren das RTOS Accelerated Technology Nucleus auf ARM portiert. Ich hätte nie gedacht, dass dieses kleine Ding mit dieser doch ziemlich merkwürdigen Architektur die Welt im Sturm erobern könnte. Im Hinblick auf die Prozessoren ist also ARM die wichtigste Story, in technischer Sicht ist es die Middleware.

Ich bin ein wenig überrascht. Ich hatte erwartet, dass Multicore in Ihrer Liste ganz weit oben steht.

Multicore ist auch sehr interessant. Insbesondere symmetrisches Multiprocessing (SMP), in diesem Marktsegment beobachten wir jährliche Wachstumsraten von etwa 50 Prozent. Aber es gibt ein paar weit verbreitete Wissenslücken im Bereich Multicore. Die Kunden glauben, sie bräuchten SMP, dabei ist es in Wirklichkeit gar nicht so. Die Kunden kaufen zum Beispiel eine SMP-Version von ThreadX und dann finden sie heraus, dass alle Threads auf ganz spezifischen Kernen laufen. Und das ist fast dasselbe, als würde man asymmetrisches Multiprocessing (SMP) in einer gemeinsamen Speicherumgebung laufen lassen.

Leider sind die Tools für Multicore wirklich schlecht. Das Debugging zum Beispiel, alles ist bei Multicore schwieriger. Wie gesagt: Man braucht SMP nicht unbedingt, obwohl ich das vielleicht nicht sagen sollte - wir verlangen einen höheren Preis für die SMP-Variante. SMP kommt dann in Frage, wenn die Kunden eine echte dynamische Lastverteilung benötigen. Aber das ist ein interessanter Wachstumsmarkt, ohne Frage.

Was hat sich für Sie als Betriebssystemhersteller geändert, als sich Multicore-Prozessoren durchsetzten?

Wir haben dieselben Probleme wie unsere Kunden. Wir haben ja auch das Problem mit den Tools. Wir mussten unser System ja auch an Multicore-Systeme anpassen. Das bedeutet, wir brauchen Tools – genau wie unsere Kunden.

Und die Komplexität von Multicore ist höher. Ein Betriebssystem für Ein-Kern-Prozessoren ist viel weniger problematisch als ein Multicore-Betriebssystem. Das Testen und die Validierung ist ein Stück anstrengender bei einem Multicore-Design. Wir sehen also dieselben Probleme wie der Anwender.

War das der Ursprung Ihres Tracing-Tools TraceX? Wollten Sie damit verifizieren, ob die Multicore-Portierung korrekt arbeitet?

Das war nicht der Start des Tools, aber wir haben es auch dafür verwendet. Wir haben eine Multicore-Variante von TraceX gebaut, die uns einen Einblick in diese Umgebung verschafft hat. Das ist ja das Problem: Es ist einfach verrückt, wenn man wissen will, was alles zur gleichen Zeit auf all diesen Kernen vor sich geht. Wir haben TraceX dafür erweitert, damit wir wenigstens eine Systemübersicht über das hatten, was alles vor sich ging. Es ist schön zu sehen, wie das System arbeitet.

„Preemption Threshold Scheduling gibt den Threads freie Fahrt“

Das Prinzip von Preemption Threshold Scheduling (PTS): Normalerweise wird ein Thread mit der Priorität 20 durch jeden Anwendungsstrang mit einer höheren Priorität unterbrochen. PTS erlaubt es aber, Prioritätsschwellen festzulegen. In diesem Fall kann der Thread mit der Priorität 20 erst ab dem Wert 14 und höher unterbrochen werden.
Das Prinzip von Preemption Threshold Scheduling (PTS): Normalerweise wird ein Thread mit der Priorität 20 durch jeden Anwendungsstrang mit einer höheren Priorität unterbrochen. PTS erlaubt es aber, Prioritätsschwellen festzulegen. In diesem Fall kann der Thread mit der Priorität 20 erst ab dem Wert 14 und höher unterbrochen werden.
(Bild: Express Logic)

Wenn man sich mit parallelem Multithreading beschäftigt – ist da noch die Notwendigkeit für den Preemption-Threshold-Mechanismus (PT) vorhanden, den ThreadX hat?

Ja, er kann immer noch nützlich sein, denn PT ist ein wirklich ein kritischer Bereich. Selbst in der Multicore- und der SMP-Welt gibt es immer noch kritische Bereiche, bei denen man alles andere abschalten möchte und den kritischen Thread einfach laufen lässt.

Man räumt mit PT den kritischen Threads einfach so etwas wie ein Vorfahrtsrecht ein.

Ja. Der Mechanismus gibt den Threads freie Fahrt, solange sie im kritischen Bereich sind.

Ich fand es interessant, dass ThreadX in vielen Subsystemen zuhause ist, die wiederum Bausteine größerer Systeme sind. Wir klein kann ThreadX minimal werden?

Die kleinste Variante von ThreadX, bei der man nur die grundlegenden Scheduling-Routinen nutzt, umfasst gerade 2,5 Kilobytes, das ist also sehr, sehr winzig. Da ist kein PT drin, keine Queues, keine Speichermanagement-Services, sondern nur grundlegendes prioritätsbasiertes Scheduling. Deshalb benutzen viele Bluetooth- oder Breitband-Chips intern ThreadX.

Ich habe gelesen, dass ThreadX in 1,5 Milliarden Geräten drin steckt. Das ist nur schwer vorstellbar.

Erst vor kurzem hat sich ein Hacker-Team ein Gerät vorgenommen, ich glaube, es war ein iPhone. Sie nahmen es auseinander und dann kamen sie zu den Chips, die früher Infineon geliefert hatte. In den älteren Versionen wurde Nucleus benutzt, in den neueren ThreadX. Die Hacker fanden das heraus. Sie haben damit nichts angestellt, sie haben sich nur das Innenleben angeschaut und sich gefragt: Was ist Nucleus? Was ist ThreadX? Es ist schon interessant, dass sie das herausgefunden haben.

Wir sind in vielen Geräten vertreten, in denen das Betriebssystem nichts mit der Verbindung zur Außenwelt zu tun hat. Es ist nur Scheduling, da kann man nichts Großartiges manipulieren. ThreadX hat keinerlei Verbindung zur Außenwelt, es ist alles intern. Die einzige Möglichkeit, das System zu hacken, wäre die Instruktionen der Applikation zu ändern, damit sie etwas anderes tut, oder die Instruktionen von ThreadX zu ändern.

Das ist interessant. In einem Gespräch mit einem anderen RTOS-Hersteller bekam ich die Aussage, die Connectivity sei heute die wichtigste Aufgabe.

Wir haben Partner, die sichere Sockets auf der Basis unserer TCP/IP-Sockets aufsetzen, so dass sichere Kommunikation möglich ist. Wir haben auch IPsec – wir können auf dem IP-Level alles verschlüsseln. Diese Standards haben natürlich alle ihre Schwächen, man kann IPsec knacken, man kann sichere Sockets knacken, wenn man genügend Rechenleistung hat oder die NSA ist. Das alles sind bekannte Größen. Das Risiko ist aber begrenzt. In den meisten Fällen reicht die Sicherheit für unsere Bedürfnisse aus. Wenn die Systeme gehackt werden, sind sie in der Regel sowieso schon altbacken.

Absolute Sicherheit wird wahrscheinlich nie zu erreichen sein.

IPsec und sichere Sockets erschweren das Hacken erheblich. Es ist sicher nicht unmöglich, aber doch sehr unbequem. Aber zu jeder Zeit hat der Mensch geglaubt, er habe so etwas wie ein sicheres Protokoll, aber sie waren nie ganz sicher. Es ist ein Irrtum zu glauben, dass die Dinge wirklich ganz sicher sein könnten. Wenn man tatsächlich daran glaubt, dann lebt man mit dem Risiko einer bösen Überraschung.

„Als erstes schrieb ich das Benutzerhandbuch“

In einem früheren Interview sagten Sie, bei der Entwicklung von ThreadX hätten Sie als erstes das Benutzerhandbuch geschrieben. Wie kamen Sie auf diese Idee?

Reines Genie (lacht). Nun, ich habe das schon einmal so gemacht. Bei Nucleus bin ich genauso vorgegangen. Dafür gibt es zwei Gründe: Ich weiß, dass es sehr lange dauert, die Dokumentation zu schreiben. Also muss man die Softwareentwicklung und die Dokumentation parallel laufen lassen. Das ist der pragmatische Grund.

Es gibt aber auch einen Grund, der die Usability im Blick hat: Wenn man als erstes das Handbuch schreibt, sieht man augenblicklich, welche Kopfschmerzen man dem Anwender bereitet. Man sagt dem Anwender: So musst du das System benutzen – oh, das ist aber schlecht. Also wieder löschen und neu ansetzen – Ja, das ist viel besser.

Und letztendlich dient das Handbuch als Design-Dokument. Und ich würde es jederzeit wieder so machen. Als ich Nucleus entwickelte, habe ich es zum ersten Mal in dieser Reihenfolge gemacht. Ich bin mir zwar nicht sicher, ob der pragmatische Grund für mich damals nicht der wichtigere war. Aber nach Nucleus erkannte ich den Benefit, den man daraus zieht: Das Produkt wird dadurch einfach viel besser benutzbar.

Und andererseits kann man das Handbuch auch als so etwas wie eine Aufgabenliste ansehen.

Ja. Und es hilft noch in einer anderen Hinsicht. Bei ThreadX hatte ich eine ganze Reihe von Ideen, die ich umsetzen wollte. Aber als ich das Handbuch schrieb, half es mir wirklich, klar zu sehen, was ich im ersten Release verwirklichen konnte. Ich konnte das Problem also einschränken. Wenn man sich dazu zwingt, wirklich in die Details dessen einzusteigen, was man gerne abliefern möchte, dann bekommt man die Sache besser in den Griff.

Glauben Sie, dass ThreadX den richtigen Umfang hat? Denn die erste Version von Nucleus (RTX) war, wie Sie einmal sagten, ein wenig zu leichtgewichtig, die zweite (Plus) zu schwergewichtig.

Ja, diesmal hat es genau hingehauen. Ich hatte ja schon vorher andere Echtzeitbetriebssysteme verwendet. Und manche Dinge mochte ich, andere nicht. Ich hatte also bestimmte Vorstellungen, was ich in Nucleus RTX tun wollte. Aber als ich durch das Feedback von Geschäftskunden verstand, wie man die Dinge etwas besser machen konnte, sagte ich mir: Dies und jenes hätte ich tun müssen.

Bevor ich Nucleus Plus entwickelte, machte ich also eine Übersicht von allem, was kommerziell vertrieben wurde und auch von einigen freien Betriebssystemen. Ich schrieb also eine Liste mit allen Features, die sie hatten. Und dann sagte ich: Ich mache das alles. Warum auch nicht?

Das schien anfangs eine gute Idee zu sein. Aber später, als das System ausgeliefert wurde, sah ich, dass wir ein Problem hatten, weil es alle Features an Bord hatte und nur heruntergestrippt werden konnte. Es enthielt auch eine Menge Assembler-Code, denn die Tricks, zu denen ich greifen musste, benötigten mehr Assembler-Code als bei ThreadX. Es war also sehr schwer auf andere Architekturen zu portieren und es war im Vergleich zu ThreadX sehr umfangreich.

Und im Hinblick auf die Performance war Nucleus Plus wegen seiner Input/Output-Architektur relativ langsam. Ich durchlief also eine kurze Phase schlechten Gewissens. Man hat nicht immer die Chance, in den Wettbewerb mit einem alten Produkt zu treten, aber glücklicherweise hatte ich diese Möglichkeit. Und ThreadX hat davon letztlich profitiert.

Zeigt sich hier wieder die alte Pareto-Regel, dass man 80 Prozent der Zeit benötigt, um die letzten 20 Prozent der Arbeit richtig hinzubekommen?

Genau. Man muss sich auch meinen Hintergrund ansehen. Als ich Nucleus RTX schrieb, hatte ich keine Erfahrung im kommerziellen RTOS-Umfeld. Als ich Nucleus Plus schrieb, hatte ich zwei Jahre Erfahrung. Als ich ThreadX entwickelte, waren es schon fünf oder sechs. Und das ist gut. Als ich Nucleus RTX schrieb, konnte ich niemandem sagen, welchen Anwendungsfall es erfüllen sollte. Ich wußte zwar, was ich selbst mochte, aber nicht, was typisch war und was nicht.

Ein interessanter Aspekt von ThreadX ist ja, dass man Prioritäten einigermaßen flexibel vergeben kann. Haben Sie diesen Punkt bei anderen Betriebssystemen vermisst?

Nein, nein. Ich schrieb das Dokument für ThreadX und ich kam zu dem Kapitel, in dem es um das Abschalten oder Ausführen kritischer Bereiche ging. Und dann kam mir ein Gedanke: Normalerweise verteilen sich kritische Bereiche nur auf eine Handvoll von Threads, beileibe nicht auf alle. Und dann fragte ich mich: warum soll man das komplette übrige Scheduling aussperren, wenn man nur einen begrenzten Bereich des Scheduling aussperren kann? Lasst doch einfach die Threads laufen, die an dem kritischen Bereich beteiligt sind, und um die anderen muss man sich nicht kümmern.

Und ich dachte, das ist doch einfach umzusetzen. Die Implementierung ist ein bisschen schwieriger, aber auf dem API-Level ist das ziemlich einfach. Ich dachte einfach, dass es ein einfacher Weg sein könnte, den Benutzern eine gewisse Granularität zu geben. Ich betrachtete es aus der Warte der Responsivität. Man konnte immer noch Responsivität haben, auch wenn sich das System in einem kritischen Bereich befand.

Und jetzt zeigt sich, dass dieser Aspekt noch andere Dinge mit sich bringt. Ich habe nach kurzer Zeit erkannt, dass man damit die Zahl der Context-Switches reduzieren konnte. Andere Forschungen haben gezeigt, dass man das Scheduling mit Hilfe von PT und Prioritäten garantieren konnte. Das System gibt einem Thread zwei Prioritäten: Eine Priorität, während er läuft und eine Priorität, bevor er läuft. Es ergaben sich also noch weitere Vorteile. Der originale Aspekt war aber die Responsivität.

Manche Leute beklagen sich über die Softwarequalität und über die steigende Komplexität der Software. Sie haben Betriebssysteme für harte Aufgaben geschrieben. Was würden Sie zum Thema Softwarequalität sagen?

Ich habe hier nicht viele gute Ratschläge zu bieten. Ich würde aber sagen, dass Einfachheit der Schlüssel ist. Der alte Spruch „Keep it simple“ ist eine gute Praxis. Das ist auch die Nummer 1.

Dann würde ich die Leute ermuntern, als Erstes das Handbuch zu schreiben. Jeder Entwickler sollte seine Aufgabe als ein Produkt sehen. Deshalb sollten sie ein Handbuch dafür schreiben und eine gut definierte Interface-Schicht entwickeln, so dass niemand sieht, was sich hinter dem Interface verbirgt.

Sie sollten ein Include-File einbinden, das das Mapping für die API enthält. Und das ist es. Auf diese Weise kann man den ganzen Spaghetti-Code vermeiden. Und man kann die Produkte wiederverwenden, man hat eine Reihe kleiner Produkte, die man in anderen Applikationen verwenden kann, eben weil sie dokumentiert sind, weil sie ein gut definiertes Interface haben und der Code gut organisiert ist. Ich bevorzuge die komponentenorientierte Methode. Das ist aber alles andere als Raketenwissenschaft, eine Menge Entwickler machen das.

„Wir leben zwischen Barebones-Applikationen und Linux“

Das klingt plausibel. Wie würden Sie die Zukunft von Echtzeitbetriebssystemen sehen? Manche Experten denken ja, die Bedeutung von Virtualisierungslösungen würde zunehmen und mehr und mehr würde sich auf der Applikationsschiene abspielen.

Echtzeitbetriebssysteme haben immer noch eine gute Zukunft. Das beste Beispiel dafür ist wahrscheinlich das iPhone, das so viele Komponenten-Chips hat. Ich denke aber, dass das RTOS als zentrales Betriebssystem eines Smartphones keine gute Zukunft hat. Das werden Linux oder Android oder iOS sein, auf jeden Fall kein RTOS.

Aber die Peripherie-Chips werden immer Aufgaben vom zentralen Prozessor übernehmen, und da spielen Linux oder Android typischerweise keine Rolle. In diesen Bereichen haben Echtzeitbetriebssysteme eine starke Zukunft.

Im traditionellen Embedded-Segment trifft man immer auf RTOS, wenn es um eine dedizierte Aufgabe geht, die zeitkritisch und antwortzeit-kritisch ist und wo es auf kleine Größen ankommt. Wir behaupten also unser Terrain.

Als Linux aufkam, gab es eine richtige Schlacht, weil keiner wusste, wie man Linux einschätzen sollte und wie man ein RTOS einschätzen sollte. Und manche versuchten, Linux überall und in jeder Nische einzusetzen. Aber das hat sich jetzt gelegt. Wir haben jetzt auch gute Freunde im Linux-Bereich.

Es gibt Experten, die ein deterministisches Verhalten auch für Linux nachgewiesen haben – zumindest empirisch.

Ich bin mir nicht sicher, ob man Linux wirklich als deterministisch ansehen kann. Aber nehmen wir mal an, es ist so deterministisch, dass es einen Context-Switch in 200 Mikrosekunden garantiert. Was ist aber, wenn der Kunde einen Context-Switch in 10 Mikrosekunden braucht?

Der Code-Umfang, der im Linux-Kernel steckt, kann unmöglich auf die Größe eines RTOS heruntergebrochen werden. Es kann also nicht schneller werden.

Echtzeit bedeutet ja: Es gibt Echtzeitbeschränkungen für bestimmte Aufgaben, kann das System das liefern? Und für manche Aufgaben kann Linux das durchaus. Wenn das System 200 Mikrosekunden als Grenze für Context-Switches benötigt und wenn es deterministisch ist, dann ist Linux eine gute Lösung. Und wenn genug Speicher vorhanden ist.

Aber es wird immer Applikationen geben, die mit weniger auskommen müssen. Es gibt sogar Barebones-Applikationen, die gar kein Betriebssystem benötigen. Und in diesem Spektrum zwischen den Barebones-Apps und Linux liegt das Reich der Echtzeitbetriebssysteme. Klopfen wir auf Holz – ich hoffe, dass es so bleibt.

Der Trend geht ja Hardware-seitig zu Systems on a Chip. Haben RTOS auch dort eine Existenzberechtigung?

Wir haben bereits eine Reihe von Portierungen auf verschiedene SOCs gemacht. Ein gutes Beispiel ist der TI AM 335X, der auf einem ARM Cortex A8 oder A9 basiert. TI arbeitet sehr stark mit Linux. Sie zielen mit diesem Chip auf Linux-basierte Applikationen. Aber ein gewisser Prozentsatz wird für andere Dinge eingesetzt. Und hier kommen wir ins Spiel. Auf der anderen Seite gibt es auf den ARM-Cortex-M-Chips Komponenten, die für Linux zu klein sind.

Ist Virtualisierung für Sie auch ein Thema? Ein Betriebssystem mit kleinem Footprint könnte einen guten Hypervisor abgeben.

Eine Menge unserer Kunden schalten zwischen Linux und ThreadX hin und her. Wenn man harte Echtzeitanforderungen hat, nimmt man ThreadX, und dann schaltet man zurück zu Linux.

Liefern sie dafür den Hypervisor?

Nein. Wir arbeiten mit Partnern zusammen, manche Kunden haben Hypervisoren von Partnern genommen, aber wir stellen das nicht selbst her.

Könnte das in Zukunft ein Geschäftsfeld für Sie sein?

Ich weiß nicht, ob sich das auszahlt. Es ist viel Arbeit, es ist nicht einfach, und wir wissen nicht, wieviel Geschäft wir daraus generieren können – speziell im Multicore-Umfeld. Multicore ist quasi des Hypervisors schlimmster Feind. Denn wenn Multicore-Chips so billig geworden sind – warum teilt man einen Prozessor auf, wenn man zwei oder vier Kerne zur Verfügung hat? Ich bin mir nicht sicher, wie die Zukunft für Hypervisoren aussieht.

(ID:42239895)