Günstiger mit Ressourcen-Partitionierung

Bedingt durch die parallele Softwareentwicklung, treten in der Integrationsphase häufig Performance-Schwierigkeiten auf. Durch ein Betriebssystem- gestütztes CPU-Budget für jedes Softwaresubsystem ist sichergestellt, dass kein Subsystem Ressourcen belegt, die von anderen Subsystemen benötigt werden – das erleichtert den Entwicklerteams die parallele Arbeit deutlich.

Bedingt durch die parallele Softwareentwicklung, treten in der Integrationsphase häufig Performance-Schwierigkeiten auf. Durch ein Betriebssystem- gestütztes CPU-Budget für jedes Softwaresubsystem ist sichergestellt, dass kein Subsystem Ressourcen belegt, die von anderen Subsystemen benötigt werden – das erleichtert den Entwicklerteams die parallele Arbeit deutlich. 

Ein modernes industrielles Steuerungssystem kann Dutzende oder sogar hunderte von Softwareaufgaben umfassen, die alle um einen begrenzten Umfang an Speicher und CPU-Zeit konkurrieren. Um die Entwicklung solcher komplexen Systeme zu beschleunigen, teilen viele Unternehmen die Arbeit unter mehreren Entwicklungsteams auf und weisen jedem Team die Erstellung eines separaten Softwaresubsystems zu.

Bedingt durch die parallele Entwicklung treten jedoch in der Integrationsphase häufig Performance- Schwierigkeiten auf. Hervorgerufen werden diese aufgrund der Tatsache, dass die verschiedenen Subsysteme nun erstmalig untereinander um die Systemressourcen wetteifern. So können Subsysteme, die isoliert gut arbeiteten, jetzt eine lange Reaktionszeit zeigen oder einfach nicht mehr funktionieren.

Die Diagnose und Behebung solcher Probleme ist grundsätzlich schwierig. Die Designer müssen mit den Prioritäten der einzelnen Aufgaben jonglieren, unter Umständen das Thread-Verhalten im System ändern und ihre Modifikationen dann erneut testen und verfeinern. Der gesamte Prozess kann durchaus mehrere Wochen, manchmal sogar Monate in Anspruch nehmen, so dass die Kosten steigen und die Produktentwicklung verzögert wird.

Die Partitionierung von Ressourcen bietet eine Möglichkeit, diese komplexen Probleme bei der Integration zu bewältigen. Systementwickler isolieren dabei Softwaresubsysteme in separate Bereiche oder Partitionen und weisen diesen dann jeweils ein garantiertes Budget an Speicher oder CPU-Zeit zu. Der Designer kann beispielsweise eine Reihe an Threads, die einen gemeinsamen Zweck haben, wie etwa die Bewegungssteuerung, in einer Partition platzieren und ihr 50 Prozent der gesamten CPU-Kapazität zuweisen. Der Partitions-Scheduler stellt dann sicher, dass diese Partition stets die zugewiesene CPU-Leistung erhält.

Somit verfügt jede Partition über eine stabile, bekannte Laufzeitumgebung, die das Entwicklerteam individuell aufbauen und prüfen kann. Wenn also die Softwareprozesse innerhalb der Partition während den Tests der Einheit gut funktionieren, dann werden sie diese Performance mit großer Wahrscheinlichkeit auch bei der Integration zeigen. Unvorhergesehene Konkurrenzsituationen um Ressourcen zwischen Subsystemen können so beseitigt werden.

Prioritäten für Threads

Um die Vorzüge der Zeitpartitionierung zu verstehen, muss man sich vor Augen führen, wie Threads in einem typischen Steuerungssystem zeitlich festgelegt sind. In den meisten Fällen nutzt das System einen prioritätsbasierten Scheduler, der jeweils dem Thread mit der höchsten Priorität das Vorrecht auf CPU-Zeit einräumt. Diese Art von Priorisierung wird weitläufig verwendet und ist gut verstanden. Sie sorgt dafür, dass jeweils die zeitkritischen Threads ihre Deadlines erfüllen. Dadurch wird jedoch ein Problem aufgeworfen: Wenn ein Thread lediglich eine Prioritätsstufe höher ist als ein anderer, kann er den weniger zeitkritischen Thread um die nötige CPU-Zeit bringen.