Nehmen wir ein Beispielszenario mit zwei Threads, A und B, bei dem A eine geringfügig höhere Priorität aufweist als B. Sobald A mit Aufgaben überflutet wird, wird er den Thread B, als auch alle weiteren Threads mit niedrigeren Prioritäten, vom Zugang zur CPU-Zeit abschneiden. In einem industriellen Steuerungssystem könnte A der Regelkreis des Roboterarms sein und B die Mensch-Maschine-Schnittstelle (HMI). Wenn nun der Regelkreis zu viele CPU-Zyklen belegt, wird die HMI daran gehindert Updates anzuzeigen oder sie wird nicht mehr auf Bedienereingaben reagieren.
Da Steuerungssysteme zunehmend komplexer werden und Designteams wachsen, wird die Zuweisung und Pflege von Prioritäten für eine große Anzahl von Threads immer schwieriger. Systementwickler haben erkannt, dass die ungeregelte Zuweisung von Prioritäten zu chaotischen Zuständen oder sogar zu einem funktionsunfähigen System führt. Daher sind sie bemüht, die Anzahl der verwendeten Prioritäten auf eine überschaubare Zahl zu beschränken. Diese Lösung hat jedoch einen ungewollten Nebeneffekt: erhöhte Latenzzeit.
Da viele Threads dieselbe Priorität haben, kann die Warteliste der bereiten Threads mit einer bestimmten Priorität sehr lang werden. Ein bereiter Thread muss demzufolge warten, bis er an die vorderste Position der Warteliste vorgerückt ist, bis er ausgeführt werden kann.
Mit der Zeitpartitionierung können Designer ein Betriebssystem gestütztes CPU-Budget für jedes Softwaresubsystem definieren. Zudem kann jedes Team sein Subsystem testen, um sicherzustellen, dass dasselbe innerhalb des jeweiligen definierten Budgets funktioniert. Zum Zeitpunkt der Integration wird das RTOS die Ressourcen-Budgets umsetzen und so verhindern, dass eines der Subsysteme Ressourcen belegt, die von anderen Subsystemen benötigt werden. Jedes System wird erwartungsgemäß – wie durch die Tests belegt – arbeiten.
Im Ergebnis erleichtert die Partitionierung so den Entwicklerteams die parallele Arbeit. Der Entwickler muss sich dabei nicht länger Gedanken über die Prioritäten der Threads außerhalb seines Subsystems machen: Diese Threads werden die Performance seines Subsystems nicht mehr beeinflussen. Auch dann nicht, wenn diese eine höhere Priorität besitzen. Innerhalb der Partition werden die Threads nach den bisherigen Regeln eines Steuerungsprogramms prioritätsbasiert abgearbeitet. In der Folge wird jede Partition quasi zu einem virtuellen Prozessor, der es jedem Designteam erlaubt, ein geeignetes Prioritätsschema auf Subsystemebene zu definieren. Damit wird die Umsetzung eines globalen Prioritätsschemas obsolet.
Partitionierungsbeispiel
Um die Vorteile zu veranschaulichen, lässt sich ein einfaches System heranziehen, das ohne die Verwendung von Zeitpartitionierung aufgebaut wurde. Das System, dargestellt in Abbildung 1, umfasst die folgenden Prozesse:
Während der Integrationsphase arbeitet das Web-Überwachungssystem zufrieden stellend – allerdings nur bis zu dem Zeitpunkt, an dem der Benutzer das lokale HMI benutzt. Dann stoppt das Überwachungssystem häufig und zeigt keine weiteren Informations- Updates mehr an. Bei der Fehlersuche stellt sich heraus, dass der Remote-Überwachungsagent keine CPU-Zeit mehr zugewiesen bekommt, sobald über die HMI Befehle abgesetzt werden, die zu einer erhöhten Beanspruchung der Motorsteuerung führen. Eine Durchsicht der Prioritäten zeigt, warum dies der Fall ist: Da der Remote-Überwachungsagent die niedrigste Priorität hat, wird ihm der CPU-Zugang abgeschnitten, sobald das System auf voller CPU-Last arbeitet.