Der nächste Schritt wird der Einbau des Prioritäten-Managers in den Mikrocontroller sein. Das bedeutet zum einen den Einbau in den Simulator. Dazu müssen weitere Trap-Routinen zum Starten von Threads entworfen werden. Außerdem soll der Scheduler in die Pipeline in Hardware integriert werden.
Zudem muß das Zusammenwirken der Scheduling-Techniken in der Middleware mit dem Hardware-Scheduler untersucht werden. In einem großen System wird es viele Threads geben, die auf die vier zur Zeit in Hardware vorgesehenen Kontexte abgebildet werden müssen.
Es wäre zu untersuchen, wie man Algorithmen wie Earliest Deadline First oder Least Laxity First mit deutlich weniger Bits für ihre Parameter - also die Deadline und gegebenenfalls die Laufzeit - nutzen kann und wie sich das auf die Echtzeitfähigkeit auswirkt. Je höher die verwendeten Prozessoren getaktet werden, um so wichtiger wird diese Frage, da sich die Zeit, die man durch Zählen der Taktzyklen überbrücken kann, dadurch verringert.
Möglicherweise können auch ganz neue Scheduling-Algorithmen gefunden werden, die eine gute Durchmischung der Befehle verschiedener Threads für einen großen Bereich von Anwendungen garantieren können. Diese könnten einen mehrfädigen Mikrocontroller optimal ausnutzen. Der Einfluß der Durchmischung ist wahrscheinlich noch nicht vollständig ausgereizt, insbesondere in Bezug auf die Klasse maximal.
Soll der Controller für weiche Echtzeitsysteme eingesetzt werden, wie sie etwa bei Multimediaanwendungen auftreten, wäre es auch möglich andere Schedulingverfahren einzusetzen, die keine harten Echtzeitbedingungen unterstützen. So könnte das in Kapitel 2 angesprochene Problem der lokalen Sichtweise des Prioritäten-Managers möglicherweise durch einen adaptiven Algorithmus gelöst werden, wie er zum Beispiel in [SLST99] vorgeschlagen wird.