Der Erfolg von Linux in der Industrie wäre ohne Echtzeiteigenschaften nicht denkbar gewesen. Wobei Echtzeit hier (wie in der DIN-Norm 44300 auch) als deterministisches Verhalten definiert wird. Oder anders gesagt – es muss sichergestellt sein, dass auf ein äußeres Ereignis innerhalb einer bestimmten Zeit reagiert wird. Und das Ergebnis muss korrekt sein.
Grundsätzlich gibt es zwei Ansätze, um Linux echtzeitfähig zu machen:
Im Mikrokernel Ansatz werden alle Echtzeitaufgaben in einem eigenen RTOS (Kernel) gehandhabt, Linux wird innerhalb dieses RTOS als niederpriore Task geschedult. Genau genommen muss hier also nicht von Echtzeit Linux, sondern vielmehr von Echtzeit neben Linux gesprochen werden.
Der In-Kernel Ansatz verfolgt das Ziel, Linux an sich echtzeitfähig zu machen (ohne darunterliegenden Mikrokernel). Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar und Thomas Gleixner. Vor allem Thomas Gleixner ist heute die treibende Kraft bei der Entwicklung von PREEMPT_RT. Die Linux Foundation unterstützt in der Realtime Linux Working Group (RTL) seit Jahren diesen Ansatz und die vollständige Integration in den mainline Kernel.
Einen sehr guten Überblick über dieses Thema gibt Ihnen ein Vortrag auf der Embedded Linux Conference 2016 und weitere Artikel unter Linux und Echtzeit und Embedded Software Engineering.
Wenn Sie sich erstmalig mit dem Gedanken tragen, Linux als Echtzeitsystem zu verwenden, dann ist dies hier ein guter Startpunkt: https://wiki.linuxfoundation.org/realtime/start
Zum Testen der Echtzeiteigenschaften eines Prozessors unter Linux hat sich das Tool cyclictest eingebürgert. Wird dieses Tool zusammen mit anderen Programmen wie hackbench oder pingfloot genutzt, so ergibt sich ein sehr realitätsnahes Abbild der Eigenschaften der Hardware unter Lastbedingungen.
Die folgenden zwei Grafiken zeigen das Verhalten eines ARM Prozessors unter Linux V5.x mit und ohne Preempt-RT.
Die Latenz auf ein externes Ereignis beträgt beieinem Kernel ohne Preempt-Rt Patch im worst case 4665 µsek., mit dem Patch verringert sie sich auf maximal 79 µsek. in unserem Beispiel. Viel wichtiger aber ist, dass es sich bei dem Wert mit Preempt-RT Patch um einen worst case Wert handelt, also einen Wert, über den die CPU nicht hinausgehen wird.
Interessant in diesem Zusammenhang sind sicher auch die Langzeit Messungen des Open Source Automation Development Lab (OSADL).
Der große Vorteil von Preempt-RT ist der, dass das Linux an und für sich nicht verändert wird. Das heißt das Programmiermodel bleibt erhalten. Sie können genau so entwickeln und testen wie für ein übliches Linux. Und das Linux auch genauso härten und absichern.
Bei einem Dual-Kernel Ansatz ist das anders. Dort müssen Sie – wenn Sie die zeitlichen Vorteile nutzen wollen – alles im Kernelkontext entwickeln und testen. Und Sie haben dann auch nicht die Linux Subsysteme und deren Treiber zur Verfügung.
Moderne Linuxkernel erlauben die Isolation von Cores, um auf diesen ungestört Echtzeit Aufgaben ausführen zu können. Dies erhöht die Performance nochmals. Und sollte das noch nicht ausreichen, so kann man einen Core auch komplett isolieren und auf diesem dann einen bare-metal Code ablaufen lassen. Ob dies im Kontext eines Hypervisors (siehe auch die Artikel zu Virtualisierung und Jailhouse sowie Echtzeit und Jailhouse) geschieht oder durch Konfiguration des Linux Systems, das klären wir mit Ihnen ab.
Solch eine Lösung benötigt einen Kommunikationsmechanismus zwischen bare-metal und Linux Anwendung. Linutronix bietet Ihnen hierfür eine Open Source Lösung an. Damit vereinfacht sich der Aufwand zur Umsetzung dieser Lösungen deutlich.
Wir beraten Sie gerne, welcher Ansatz für Sie der optimale ist.