Treiber, Systemsoftware und Echtzeitplattformen

Was umfasst plattformübergreifende Treiberentwicklung für Industriegeräte?

Plattformübergreifende Treiberentwicklung für Industriegeräte umfasst die Middleware und die Betriebssysteme, auf denen sie laufen.

Dazu gehören Treiber auf beiden Seiten der Kernel-Grenze, der Paket- oder Transferpfad unter einem Protokollstack, das Scheduler- und Interruptverhalten, das den Jitter bestimmt, und die Middleware darüber. Eine typische Echtzeit-Linux-Optimierung, die wir liefern, fährt einen Netzwerkzyklus von 80 µs bei 20 µs Jitter mit einem eigenen NIC-Treiber. Typische Projekte sehen so aus:

• Ein Windows-Treiber. Entwicklung eines NDIS-Miniport-Treibers, wenn das Gerät der Adapter ist, eines Intermediate-Treibers, wenn es über einem Adapter liegen muss, oder eines Kernel-Mode-Treibers für ein Gerät, das keine Netzwerkkarte ist.
• Ein Linux-Kernel-Treiber. Entwicklung von Netzwerktreibern für den Linux-Kernel oder von Geräte- und Plattformtreibern für USB-Geräte mit Bulk-Transfer sowie für serielle, Netzwerk- und hybride Hardware mit angebundenem FPGA.
• Echtzeitoptimierung und Validierung. Optimierung und Validierung von Echtzeitplattformen, gemessen unter Last, mit Konfiguration und Messwerten in einer Übergabe.
• Eine RTOS-Portierung. Portierung von Treibern auf FreeRTOS, Entwicklung unter eCos, Arbeit an Zephyr, micro-C/OS oder SYS/BIOS TI-RTOS, meist nach einer Plattformmigration.
• Eine Plattformmigration. Migration auf Windows IoT Enterprise LTSC für einen Maschinenbauer, dessen Version aus dem Support gefallen ist.
• Redundanz. Redundanz für hochverfügbare Steuerungen, wenn ein Knotenausfall überstanden werden muss; ihn zu erkennen reicht nicht.

Der Unterschied zum typischen Umfang bei Embedded-Systemen: Die Seite zu Embedded-Systemen behandelt die Software auf dem eigenen Chip des Geräts, diese Leistung die Software, mit der der Host mit dem Gerät spricht. Viele Produkte brauchen beides, und oft erledigen dieselben Ingenieure beides, es bleiben aber getrennte Disziplinen mit eigener Entwicklung und eigenen Fehlerbildern.

Kann Windows eine Echtzeit-Deadline halten?

Nicht in dem Sinn, in dem die Frage meist gemeint ist, und eine differenzierte Antwort hilft mehr.

Windows arbeitet standardmäßig mit einem Takt von 15,6 ms, der sich bis auf 1 ms herunter konfigurieren lässt. Das ist die Timer-Auflösung, nicht die Zykluszeit, und beides sind verschiedene Größen. Ein durchgerechnetes Beispiel: Die reine Windows-Plattform von openPOWERLINK dokumentiert für einen reinen Software-Stack einen erreichbaren Zyklus oberhalb von 10 ms. Diese 10 ms sind keine Untergrenze, die der Timer setzt. Sie ergeben sich aus der Netzgröße und der PDO-Konfiguration:

Es ist also ein Kriterium, das von den Entwurfsvorgaben abhängt, und keine feste Grenze.

Gelöst wird das mit einer hybriden Architektur. Der Kommunikationscontroller wandert ganz aus Windows heraus auf Hardware ohne Betriebssystem, hier ein FPGA mit einem Softprozessor, und Windows tastet die Netzdaten je nach Netzgröße mit 1 ms bis 5 ms ab, während der Determinismus in der Hardware bleibt. Im selben openPOWERLINK-Beispiel erreicht die Windows-Plattform mit einer externen Lösung aus NDIS-Miniport über PCIe 250 µs, gegenüber mehr als 10 ms als reine Software. Das ist ein Ergebnis einer Open-Source-Implementierung mit veröffentlichten Zahlen, hier als Bestätigung der Architektur angeführt.

Welche NDIS-Treiberklasse passt zu meinem Netzwerkgerät?

Das hängt davon ab, ob der Adapter fest zugeordnet oder geteilt ist, und die beiden Klassen tauschen Determinismus gegen Flexibilität.

• Ein Miniport-Treiber steuert den physischen Adapter direkt. Er ist die bessere Wahl, wenn feste Echtzeitleistung verlangt ist, denn jede weitere Schicht im Pfad ist eine weitere Warteschlange, die Ihren Frame aufhalten kann.
• Ein Intermediate-Treiber ist an seiner oberen Kante ein Protokolltreiber und an seiner unteren ein virtueller Miniport und liegt über einem echten Miniport. So können mehrere Anwendungen einen Adapter teilen, und das ist die richtige Wahl, wenn Virtualisierung verlangt ist.

Wir liefern beide Klassen.

Was gehört zur Migration einer Windows-Plattform?

Eine Windows-Migration besteht vor allem darin, den Neuaufbau der Systemhärtung zu planen, nicht darin, die Anwendung zu portieren.

Ein Maschinenbauer, der noch auf einer abgekündigten Windows-IoT-Version ausliefert, hat diese Plattform meist, weil sie noch funktioniert. Sie bekommt aber keine Sicherheitsupdates mehr und fällt womöglich bei der Beschaffungsprüfung eines Kunden durch. Ein geplanter Ausstieg bedeutet die Migration auf Windows IoT Enterprise LTSC, und dort sind die Daten das Argument: Die Version 2021 wird bis 2032 unterstützt, die Version 2024 bis 2034. Das eigentliche Ziel der Migration ist selten die Anwendung. Es ist die Konfiguration zur Systemhärtung, mit der sich die alte Maschine wie ein geschlossenes Gerät verhielt, also Unified Write Filter, Shell Launcher, Assigned Access, Keyboard Filter, Device Guard und Credential Guard, dazu die Laufwerksverschlüsselung, wenn das Gerät Kundendaten speichert. Diese Konfiguration wird für die neue Version neu aufgebaut.

Worin unterscheidet sich Echtzeit-Linux von Windows?

Der Unterschied liegt in der Architektur: Windows stellt verzögerte Arbeit in Warteschlangen und unterbricht nach Priorität, Echtzeit-Linux verkürzt seine nicht unterbrechbaren Abschnitte.

Unter Windows liegt das Verhalten, das über den Determinismus entscheidet, in den Warteschlangen für Deferred Procedure Calls und auf Interruptebene und darin, wie ein Thread mit hoher Priorität andere unterbrechen darf. Den Paketpfad beider Systeme zeigt die Grafik im ersten Abschnitt dieser Seite. Echtzeit-Linux geht dasselbe Problem an, indem es die nicht unterbrechbaren kritischen Abschnitte des Kernels verkürzt. Besser wird dadurch die Latenz im ungünstigsten Fall unter Last; der durchschnittliche Durchsatz kann dafür etwas sinken. Der von uns gemessene Jitter auf einer optimierten Echtzeitplattform liegt unter Last unter 20 µs, und die fortlaufenden Tests der OSADL QA Farm unter Last durch Timer, Speicher, Netz und Dateisystem bestätigen öffentlich Ergebnisse dieser Klasse. Die beiden Richtungen des Datenpfads werden unterschiedlich optimiert. Auf der Empfangsseite heißt Optimierung, auf einen Mechanismus ohne Kopieren wie AF_XDP umzusteigen oder, wo Hardware oder Betriebssystem das nicht unterstützen, auf Polling wie bei DPDK, wobei Optimierung gegen Portabilität steht. Auf der Sendeseite sind drei Mechanismen in Gebrauch: Launch Time auf Intel i210 und i225, zeitbasierte Ablaufsteuerung nach IEEE 802.1Qbv und die Linux-qdiscs ETF und taprio, die sie ansteuern. Die Arbeit am Determinismus oberhalb dieser Ebene, also Qbv-Zeitpläne, Benchmarks und Prüfung Hop für Hop, behandelt die Seite zu Echtzeit-Ethernet.

Was gehört zur Portierung eines Treibers auf ein RTOS?

Dieselben Aufgaben wie bei einem Betriebssystemtreiber werden gegen die HAL eines Herstellers gelöst statt gegen ein Treibermodell des Kernels.

Die eigentliche Gerätesteuerung lässt sich gut wiederverwenden. Vier Dinge lassen sich nicht übernehmen:

1. Das Speichermodell wird statisch statt dynamisch.
2. Die Interruptbehandlung wird chipspezifisch.
3. Die Behandlung der DMA-Deskriptoren wird gegen die HAL neu geschrieben.
4. Eine Änderung verlangt einen vollständigen Neubau und Neustart, wo sich ein Kernel-Modul im Betrieb neu laden ließe.

Der Tausch ist ausgeglichen. Es gibt keinen Aufwand für die Kompatibilität mit Kernel-Versionen, was über die Lebensdauer eines Produkts echte Einsparung ist, dafür eine Bindung an die HAL des Herstellers, was echte Kosten sind.