Bei dem Versuch, dieses Problem zu beheben, weist der Systemdesigner nun dem lokalen HMI eine niedrigere Priorität zu als dem Remote-Überwachungsagenten. Allerdings führt dieser Ansatz zu einem inakzeptablen Performance-Level für das HMI. Auch der Versuch, den Remote-Überwachungsagenten sowie den Sensor-Scanner und das HMI mit einer mittleren Priorität auszustatten, erweist sich als nicht gangbare Lösung, da somit die Performance aller drei Prozesse leidet. Da eine Veränderung der Prioritäten das Problem nicht behebt, muss das Entwicklungsteam zur nächsten Maßnahme übergehen und versuchen, das Thread- Verhalten zu ändern – im Stadium der Integration eine kostenintensive Lösung.
Partitionierung liefert einen Weg, diese Problempunkte bei der Integration zu umgehen. Beispielsweise kann der Systemdesigner für jedes Subsystem eine Partition einrichten und ein CPU-Budget für jede der vier Partitionen festsetzen: 10 Prozent des Budgets für die HMI-Partition, 10 Prozent für die Partition der Remote-Überwachung, 30 Prozent für die Partition des Sensor-Scanners und 50 Prozent des Budgets für die Motorsteuerungs- Partition, wie in Abbildung 2 gezeigt.
Bei diesem Ansatz kann jede Partition gemäß ihres CPU-Budgets getestet werden. Wenn die Systeme schließlich bei der Integration zusammen gebracht werden, erhalten alle Prozesse anteilig ihr vorher bestimmtes Budget an CPU-Zeit. Konkret bedeutet das, dass der Remote-Überwachungsagent nicht länger von CPU-Zeit abgeschnitten wird, sobald das System vollständig ausgelastet ist.
Zudem können die Entwickler die Budgets der einzelnen Partitionen ohne weiteres ändern, sollte die Reaktionszeit des lokalen HMI gegen eine bessere Remote-Update-Zeit eingetauscht werden, etwa um das System auf das gewünschte Performance-Niveau abzustimmen.
Richtig implementiert erlaubt ein Partitionierungs-Scheduler den Entwicklern eine Anpassung während der Laufzeit vorzunehmen – und zwar ohne dabei die Applikationen oder den Systemaufbau neu gestalten zu müssen. Es lässt sich durchaus argumentieren, dass ein adäquates Systemdesign und eine sorgfältige Zuweisung von Prioritäten das Problem in diesem relativ simplen System beheben kann. Die vielen Interaktionen in einem wesentlich komplexeren System münden jedoch in Problemen mit der Abarbeitung von Aufgaben, die wesentlich schwieriger zu korrigieren und zu beheben sind. Folglich sind es diese Systeme, die am meisten von der Partitionierung profitieren.
Häufig führte eine Verzögerung der Abarbeitung zu einem unregelmäßigen, unerklärlichen Verhalten und nur selten zu einem kompletten Versagen des Systems. Entsprechend schwierig ist es, die nötigen Daten für eine nachfolgende Fehlersuche zu sammeln. Meist sind zur Fehlersuche breit gefächerte und tiefgehende Systemkenntnisse erforderlich. Anhand dieses Beispiels zeigt sich deutlich, wie diese Problemstellungen rasch zu Entwicklungsverzögerungen führen können.
Überdies beinhaltet dieses Beispiel lediglich vier Threads – viele industrielle Steuerungssysteme umfassen Dutzende von Threads, die auf mehr als hundert Arten interagieren, während sie um CPU-Zeit konkurrieren. Entsprechend ist es normal, dass Thread-Ausfälle auch in mäßig großen Systemen auftreten. Indem verhindert wird, dass ein Subsystem einem anderen Subsystem den Zugang zur CPU-Zeit abschneidet, schafft die Partitionierung einen effizienten Weg, diese Problemstellungen zu beheben.
Es gibt unterschiedliche Arten von Partitionierungs-Schedulern: Einige setzen strikt und zu jeder Zeit die CPU-Budgets um, so dass jede Partition ihr volles Budget verbraucht, auch wenn keine Aufgaben vorliegen. Andere Implementierungen sind flexibel und können ungenutzte CPU-Zyklen dynamisch anderen Partitionen zuweisen. Dadurch wird die gesamte CPU-Auslastung maximiert und das System in die Lage versetzt, auch Bedarfsspitzen abzuwickeln. Manne Kreuzer