FALL 01 / boot-optimizationBSP- & Yocto-Optimierung
Boot-Zeit-Architektur auf Yocto-Geräten
NXP i.MX8M Plus · Yocto Scarthgap 5.0
Problemstellung
Auf einem Industriegerät stellt ein mit einer Standard-Yocto-Distribution erzeugtes Image die Bedienoberfläche erst Sekunden nach dem Einschalten bereit. Wird das Gerät mehrmals täglich aus- und eingeschaltet, ist das keine Komfortfrage mehr, sondern Zeit bis zur Einsatzbereitschaft.
Architektur-Ansatz
U-Boot Falcon Mode nimmt den vollen U-Boot-Ablauf vom kritischen Pfad, SPL lädt den Kernel direkt. Die Kernel-Kompression wechselt von zlib zu LZ4. Das Rootfs wechselt von ext4 zu SquashFS mit tmpfs-Overlay. Der User Space wird mit musl libc und BusyBox neu gebaut.
Falcon Mode · LZ4 · SquashFSNXP i.MX8M Plus · Yocto
Falcon ModeBootloaderVoller U-Boot-Ablauf vom kritischen Pfad
LZ4Kernel-KompressionStatt zlib
SquashFSRootfsRead-only + tmpfs-Overlay
Operationale Auswirkung
Die Boot-Zeit wird zur Architekturentscheidung. Ein Read-only-Rootfs senkt strukturell das Risiko einer Dateisystembeschädigung bei plötzlichem Spannungsverlust; in die Build-Pipeline eingebundene Boot-Graph-Messung fängt Regressionen vor dem Release ab.
FALL 02 / edge-ai-inferenceEdge-KI & Computer Vision
Inferenz-Pipeline-Architektur auf einem eingeschränkten Edge-Gerät
NVIDIA Jetson Orin NX · TensorRT · JetPack
Problemstellung
Auf einer SWaP-C-Plattform liefert Standard-FP32-Inferenz nicht den Durchsatz, den Echtzeit-Detektion und -Tracking brauchen. Und Geschwindigkeit ist nicht alles: Das Leistungsbudget begrenzt die Missionsdauer unmittelbar, weshalb fps pro Watt die entscheidende Metrik ist.
Architektur-Ansatz
INT8-Quantisierung wird mit einem repräsentativen Datensatz kalibriert angewendet. Engine-Serialisierung entfernt die Neuübersetzung beim Start. CUDA Graphs fassen die Kernel-Launch-Kette pro Frame zusammen. Geeignete Schichten wandern auf die DLA, die Vorverarbeitung auf die GPU.
INT8 · CUDA graphs · DLAJetson Orin NX · TensorRT
INT8QuantisierungAm Kalibrierungsdatensatz geprüft
CUDA GraphsKernel-LaunchEin Graph pro Frame
DLALastverteilungCo-Execution mit der GPU
Operationale Auswirkung
Im selben Leistungsbudget passt mehr gleichzeitige Wahrnehmungsarbeit. Der INT8-Kalibrierungs- und Validierungsablauf entsteht als wiederverwendbare Pipeline, Modellupdates nehmen denselben Weg.
FALL 03 / rtos-latencyRTOS & Deterministische Systeme
Interrupt-Latenz und die deterministische Regelschleife
TI AM6442 · TI-RTOS
Problemstellung
In einem mehrachsigen Motorsteuerungssystem ist nicht die Latenz selbst das Problem, sondern ihre Schwankung von Zyklus zu Zyklus. Akkumulierter Jitter wird im Dauerbetrieb zu Positionsfehlern, eine verpasste Deadline löst einen Watchdog-Reset aus.
Architektur-Ansatz
TI-RTOS HWI Direct Dispatch nimmt den Scheduler-Overhead vom kritischen ISR-Pfad. Die Regel-ISR erhält die höchste NVIC-Priorität. Tickless-Modus wird aktiviert, Timer-Coalescing deaktiviert. Unkritische Arbeit wandert in einen SWI-Deferred-Handler, gemeinsame Mutexe erhalten das Priority-Ceiling-Protokoll.
HWI dispatch · NVIC · ticklessTI AM6442 · TI-RTOS
HWI DispatchInterrupt-PfadScheduler verlässt den kritischen Pfad
NVICPrioritätsauslegungTick-Preemption-Risiko geschlossen
Priority CeilingGemeinsame RessourcenPrioritätsinversion geschlossen
Operationale Auswirkung
Ziel ist ein Worst Case, der begrenzt und reproduzierbar bleibt. Die Latenz wird über einen GPIO-Toggle-Ausgang mit externer Messtechnik erfasst; Software-Zeitstempeln wird nicht vertraut.
FALL 04 / railway-inspectionSynthetische Datengenerierung & Computer Vision
Hinderniserkennung am Gleis: synthetische Trainingsdaten
Echtes Führerstandsvideo · Ego-Path · weltfeste Platzierung · Polygon-Labels
Problemstellung
Ein Modell zur Hinderniserkennung im Gleis braucht viele annotierte Frames mit Steinen, Ästen oder Tieren auf den Schienen. Solche Ereignisse sind selten und gefährlich; für Trainingsdaten kann niemand ein Hindernis vor einen Zug legen.
Architektur-Ansatz
Auf echtem Führerstandsvideo wird der Gleisbereich pro Frame mit TEP-Net bestimmt. Mit SDXL + BiRefNet erzeugte Hindernisse werden in der Szene statt auf dem Bildschirm verankert und an der Spurweite skaliert. Labels entstehen aus dem sichtbaren Teil als YOLO-Seg-Polygone; kein Bild gelangt ohne menschliche Freigabe ins Training.
8 Klassen · Ego-Path · Polygon-LabelsTEP-Net · SDXL · YOLO-Seg
8 KlassenHindernisklassen657 Assets, automatische QS
0 %Frames auf dem Nachbargleis62,6 % mit klassischer CV
PolygonLabel-FormatMenschlich freigegeben
Operationale Auswirkung
Im Feld nicht erhebbare Hindernisszenarien entstehen auf echtem Video, mit Labels und nachvollziehbarer Freigabe. Synthetische Daten gehen nur ins Training; ihr Beitrag zur Erkennung im Feld wird an einem echten Testdatensatz gemessen. (F&E)
FALL 05 / webrtc-c2Industrielles Video-Streaming & Fernüberwachung
Latenzarme industrielle Videoübertragung
WebRTC · GStreamer · hardwarebeschleunigtes Encoding
Problemstellung
In der Fernüberwachung entscheidet der Bediener nach dem Bildschirm, doch in einer klassischen RTSP-Kette ist das Bild eine vergangene Szene. Entscheidend ist nicht die mittlere Verzögerung, sondern dass sie begrenzt und vorhersagbar bleibt.
Architektur-Ansatz
Die Transportschicht wechselt von RTSP/TCP zu WebRTC P2P (UDP/SRTP). Die GStreamer-Pipeline wird um hardwarebeschleunigtes H.264/H.265-Encoding neu aufgebaut. Die Pufferung wird für den Live-Betrieb neu eingestellt. Video, Sensorik und Telemetrie laufen in einer Sitzung auf gleichzeitigen Kanälen.
WebRTC · UDP/SRTP · HW encodeGStreamer · H.264/H.265
WebRTC P2PTransportServerpuffer und Neuübertragung entfallen
HW-EncodingKodierungVorhersagbare Zeit pro Frame
Eine SitzungMehrstromVideo + Sensorik + Telemetrie
Operationale Auswirkung
Entscheidungen stützen sich auf ein aktuelles Bild. Ein browser-nativer Empfänger beseitigt Installations- und Versionsabhängigkeiten an der Konsole, und ein neuer Sensor erfordert keine Architekturänderung.
FALL 06 / ethercat-motionIndustrieprotokolle. Prüfstandsmessung
Latenz, Jitter und Paketverlust auf einem EtherCAT-Bus messen
TI Sitara AM572x · TI-RTOS · Acontis EC-Master · TMS320F28388D
Problemstellung
Damit sich die Achsen einer Maschine gemeinsam bewegen, müssen die Daten in jedem Zyklus in derselben Zeit hin- und zurücklaufen. Standard-Ethernet garantiert das nicht: Ein Paket wartet in der Switch-Queue und auf den Scheduler des Betriebssystems, seine Ankunftszeit verschiebt sich mit der Last.
Architektur-Ansatz
Wir haben auf einem TI Sitara AM572x IDK über die PRU-ICSS-Schnittstelle einen EtherCAT-Bus aufgebaut, masterseitig TI-RTOS und Acontis EC-Master v3.2, slaveseitig TMS320F28388D mit Beckhoff SSC. Anschließend haben wir Zyklusfrequenz, Datengröße und Slave-Anzahl variiert und die Latenz gemessen.
19,2 µs ort. · jitter ≤1 µsAM572x · TI-RTOS · EC-Master
19,2 µsMittlerer Umlauf1 Slave · 64 B · 10 kHz
≤ 1 µsJitterSlave-Synchronisationsfehler
0 %Paketverlust100 Mb/s Link
Operationale Auswirkung
Ein vorhersagbares Zyklusbudget auf Standard-Ethernet-Hardware. Die Erhöhung des Zyklus von 1 kHz auf 10 kHz kostet keine Latenz, und ein zweiter Slave erhöht den Mittelwert um nur 0,1 µs.
* Aufbau und Methode jeder veröffentlichten Messung stehen auf der Fallstudienseite. Projektspezifische Details bleiben unter NDA vertraulich.
