Linux wird häufig für Fahrzeugcomputer gewählt, wenn das Terminal Teil eines dedizierten Rechners und nicht Teil einer allgemeinen mobilen App-Plattform ist. Das Softwareteam benötigt möglicherweise eine kontrollierte Bootsequenz, eine benutzerdefinierte QT-Oberfläche, direkten Zugriff auf CAN- oder serielle Geräte, Hintergrunddienste, lokale Protokollierung und ein Systemabbild, das nur im Rahmen eines genehmigten Entwicklungsprozesses geändert wird.
Ein fahrzeugmontierter Computer mit Linux-Betriebssystem eignet sich für eingebettete HMIs, Maschinensteuerung, Navigationssysteme, industrielle Datenerfassung und langfristige OEM-Projekte. Linux allein garantiert jedoch weder Echtzeitverhalten noch Sicherheitszertifizierungen. Die Reaktionszeit hängt vom Kernel, den Treibern, der Anwendungsarchitektur, der Arbeitslast und der Validierung ab. Käufer sollten die erforderliche Reaktionszeit definieren und diese auf der finalen Hardware testen.
Warum Embedded-Teams Linux in Fahrzeugen wählen
Mit Linux kann das Embedded-Team das Terminal auf eine einzige Aufgabe konzentrieren. Ingenieure können ungenutzte Dienste deaktivieren, die HMI direkt nach dem Systemstart starten, Protokolle so ablegen, dass Techniker sie leicht finden können, und festlegen, wie der Speicher nach einem Stromausfall wiederhergestellt werden soll. Diese Kontrolle ist zwar wertvoll, erzeugt aber auch Aufgaben, für die jeweils ein Verantwortlicher benannt werden muss.
QT wird häufig für eine dedizierte grafische Benutzeroberfläche verwendet. Eine QT-Anwendung kann Maschinenstatus, Führungslinien, Alarme, Kamerabilder oder Bedienelemente darstellen, ohne eine Desktop-Umgebung anzuzeigen. Die Benutzeroberfläche kann nach dem Systemstart automatisch starten und den Zugriff auf technische Einstellungen einschränken.
Langfristige Kontrolle ist ein weiterer Grund. Ein Projekt, das über mehrere Jahre läuft, bevorzugt möglicherweise ein stabiles Image, dokumentierte Abhängigkeiten und geplante Wartungsupdates gegenüber häufigen Plattformänderungen im Verbraucherstil. Dieser Vorteil zeigt sich jedoch nur, wenn Kunde und Lieferant sich über Quellcode-Verantwortlichkeiten, Build-Tools, Bibliotheken, Update-Richtlinien und Support-Verantwortlichkeiten einigen.
Linux ist nicht automatisch Echtzeit-fähig.
Der Begriff „Echtzeit“ benötigt eine konkrete Zahl. Die Aussage, dass sich ein Bildschirm schnell anfühlt, ist nicht dasselbe wie der Nachweis, dass ein Ereignis innerhalb von 20 ms, 50 ms oder einer anderen festgelegten Frist verarbeitet wird. Notieren Sie das Ereignis, dessen Frist, die während des Tests vorhandene Last und die Systemreaktion, falls die Frist überschritten wird.
Abhängig von dieser Antwort kann das Design einen Echtzeitkernel, Prioritätsplanung, isolierte Prozessorkerne, einen Mikrocontroller oder einen separaten Sicherheitscontroller verwenden. In vielen Fahrzeugen dient das Linux-Terminal lediglich der Bedienung der Mensch-Maschine-Schnittstelle und der Datenaufzeichnung, während ein dediziertes Steuergerät den Regelkreis weiterführt. Dies sind zwei sehr unterschiedliche Designs.
Bevor Sie ein System in Echtzeitbetrieb nehmen, führen Sie Timing-Tests mit aktiven Kameras, CAN-Datenverkehr mit der Zielrate, aktivierter Protokollierung, laufender Netzwerkkommunikation und unter Last laufender grafischer Benutzeroberfläche durch. Der Test sollte Temperatur, wiederholte Systemstarts, Speichernutzung und die erwarteten Peripheriegeräte umfassen.
Typische Linux-Fahrzeugcomputer-Anwendungen
Dedizierte Maschinen-HMI
Eine Baumaschine, eine Landwirtschaftsmaschine oder eine Bergbaumaschine benötigt möglicherweise einen zugelassenen Bildschirm für Betriebsmodi, Alarme, Sensordaten, Kamerabilder und Serviceinformationen. Linux und QT ermöglichen es dem Softwareteam, eine kontrollierte Benutzeroberfläche zu erstellen, ohne dabei nicht benötigte Benutzerfunktionen preiszugeben.
CAN- und serielles Datengateway
Als Gateway kann das Terminal CAN-Bus-Daten empfangen, RS232- oder RS485-Geräte auslesen, GNSS-Daten verarbeiten, ein Ereignisprotokoll führen und ausgewählte Datensätze über Ethernet oder 4G senden. Die Anzahl der Ports allein reicht nicht aus. Das Datenblatt sollte außerdem Bitrate, elektrische Isolation, Terminierung, Pinbelegung, die Zuständigkeit für jede Nachricht und die Verfügbarkeit des benötigten Treibers im Linux-System dokumentieren.
Führungs- und Positionierungsterminal
Linux kann eine spezielle Führungsschnittstelle unterstützen, die GNSS- oder optional RTK-Positionierung mit Maschinendaten kombiniert. Die Gesamtlösung erfordert weiterhin die Antennenplatzierung, Korrekturdaten, Koordinatenverarbeitung, Positionsstatus, Controller-Kommunikation und ein definiertes Verhalten bei Korrekturverlust.
Lokale Kantenverarbeitung
Manche Projekte verarbeiten Kamera- oder Sensordaten lokal, bevor die Ergebnisse in die Cloud übertragen werden. Die benötigten Prozessoren, Arbeitsspeicher, Speicherkapazität, GPUs und Beschleuniger hängen vom jeweiligen Algorithmus ab. Führen Sie die tatsächliche Arbeitslast auf der Zielhardware aus, anstatt die Leistung anhand des Prozessornamens abzuschätzen.
PDS Linux-Hardware-Einstiegspunkte
PDS bietet aktuell Linux-Optionen für den T7 und den T12 an. Je nach Kabinenlayout und Anwendungslast kann somit ein kompakter oder großflächiger Linux-Fahrzeugcomputer ausgewählt werden.
| Auswahlpunkt | PDS T7 | PDS T12 |
|---|---|---|
| Anzeige | 7 Zoll, 1024 x 600, mindestens 750 cd/m² | 12,1 Zoll, 1280 x 800, mindestens 750 cd/m² |
| Linux-Option | Linux 4.9 + QT5 | Linux-Kernel 5.15 + QT 5.15 |
| Veröffentlichter Prozessor | Quad-Core Cortex-A53 mit bis zu 1,5 GHz | 8-Kern Cortex-A55 mit bis zu 1,8 GHz |
| Veröffentlichter Speicher / Speicherplatz | 2 GB / 16 GB | 4 GB / 64 GB, optional 256 GB Speicher |
| Bedienerlayout | Kompaktes Display mit vier Funktionstasten an der Vorderseite | Großer Touchscreen für Multi-Panel-HMI |
| Veröffentlichte Fahrzeugschnittstellen | Erweiterungsanschluss, Kamera, GNSS/LTE-Antennenoptionen | Zwei CAN-, zwei RS232-, RS485-, Ethernet-, GPIO- und vier Kameraanschlüsse |
| Stromversorgung und Schutz | 9-36 V DC, IP66 | 9-36 V DC, IP66 |
Für eine kompakte Benutzeroberfläche ist das PDS T7 das erste Modell in unserem Test. Dank seines kleineren Gehäuses und der vier Tasten an der Vorderseite eignet es sich ideal für die Bildschirme in Taxis, leichten Lkw und kleineren Landmaschinen. Das PDS T12 hingegen bietet mehr Platz für ein großes HMI und die notwendigen Anschlüsse für Kameras und Daten von Baumaschinen.
Notieren Sie, wer die einzelnen Softwareschichten liefert und wartet.
Ein Linux-Prototyp kann zwar einwandfrei laufen, aber dennoch vor der Serienproduktion scheitern, weil keine Einigung darüber erzielt wurde, wem das Software-Image gehört. Der Gerätehersteller erwartet möglicherweise, dass der Kunde es selbst kompiliert; der Kunde erwartet hingegen einen gepflegten Kernel, Treiber und ein Wiederherstellungs-Image. Diese Abgrenzung sollte schriftlich festgehalten werden, bevor die ersten Prototypen bestellt werden.
- Exakte Linux-Kernel- und QT-Versionen.
- Board-Supportpaket, Toolchain, SDK und Build-Anweisungen.
- Treiberzugriff für CAN, serielle Schnittstellen, Kamera, GNSS, 4G, Wi-Fi, Bluetooth, Ethernet, USB und Speicher.
- Bootloader, Startbildschirm, automatischer Anwendungsstart und Dienstabhängigkeiten.
- Root-Zugriff, Benutzerberechtigungen, Secure-Shell-Richtlinie und Produktionsanmeldeinformationen.
- Protokollierungsort, Protokollrotation, Absturzprotokolle und Ferndiagnose.
- Image-Aktualisierungsmethode, Rollback, Wiederherstellungsmedien und Vor-Ort-Serviceverfahren.
- Eigentumsrechte am Quellcode und Supportzeitraum für die ausgewählte Konfiguration.
Plan für Fahrzeugstromunterbrechung
Ein Linux-Dateisystem kann beschädigt werden, wenn die Stromzufuhr während eines Schreibvorgangs unterbrochen wird. Terminal und Anwendung benötigen eine Strategie zum Herunterfahren und Wiederherstellen, die dem Zündverhalten des Fahrzeugs entspricht. Klären Sie, wie die Zündung erkannt wird, ob das Herunterfahren verzögert werden kann, welche Daten gelöscht werden müssen und wie sich das Gerät bei wiederholten Kurzstarts verhält.
Testen Sie die Speicherkonfiguration für den Produktiveinsatz mit der tatsächlichen Protokollierungsrate. Ein System, das Kameradateien, Datenbanken und Diagnoseprotokolle schreibt, erfordert eine andere Strategie als eine einfache HMI. Erwägen Sie je nach Projektrisiko schreibgeschützte Partitionen, journalisierte Dateisysteme, begrenzte Protokolle, Anwendungs-Checkpoints und einen Wiederherstellungsmodus.
Treiber und Schnittstellen als ein System validieren
Schließen Sie während des Pilotprojekts alle geplanten Peripheriegeräte an. Falls beide CAN-Netzwerke parallel funktionieren, testen Sie sie gemeinsam. Notieren Sie für jedes serielle Gerät, ob es RS232 oder RS485 verwendet, und überprüfen Sie anschließend Baudrate, Pinbelegung, Kabellänge und Terminierung. Die Kameras sollten während des Tests ab- und wieder angeschlossen werden, damit das Team die Auswirkungen auf Startreihenfolge, Vorschauverzögerung, Auflösung und Aufzeichnung beobachten kann.
Prüfen Sie bei 4G und GNSS die Antennenposition, die Frequenzbänder des Zielmarktes, das Verhalten der SIM-Karte, die Zeitsynchronisation, die Positionsbestimmung und die Wiederherstellung nach Signalverlust. Ein Treiber, der in einem kurzen Funktionstest funktioniert, kann nach wiederholten Zündzyklen oder längerem Betrieb ein anderes Verhalten zeigen.
Sicherheit und Updates benötigen einen praxisorientierten Verantwortlichen.
Standardpasswörter entfernen, Dienste einschränken, Produktionsschlüssel schützen und Fernzugriffe dokumentieren. Festlegen, wer Software-Schwachstellen überwacht und Updates freigibt. Ein stabiles Image sollte nicht vernachlässigt werden.
Setzen Sie auf eine stufenweise Bereitstellung. Aktualisieren Sie zunächst eine kleine Gruppe von Fahrzeugen, überwachen Sie Startvorgang, Anwendung, Schnittstellen, Daten und das Feedback der Bediener und erweitern Sie die Bereitstellung anschließend. Halten Sie ein Wiederherstellungsabbild bereit und stellen Sie sicher, dass ein Fahrzeug im Falle eines Update-Fehlers wieder in Betrieb genommen werden kann.
Linux oder Android: Welches Betriebssystem sollte das Projekt verwenden?
Wählen Sie Linux, wenn es sich beim Terminal um ein dediziertes Embedded-System handelt, das von einem Embedded-Team betreut wird, insbesondere wenn das Projekt eine benutzerdefinierte QT-HMI, kontrollierte Dienste, direkte Hardwareintegration und ein stabiles Produktimage erfordert. Wählen Sie Android, wenn das Projekt primär auf Touch-Bedienung und Apps ausgerichtet ist und von einem Mobile-Development-Team betreut wird.
Beide Plattformen eignen sich für Fahrzeuganwendungen. Die sicherere Wahl ist die Plattform, die mit vorhandener Software, Entwicklerkenntnissen, Peripheriegeräten, Update-Prozessen und Supportzeitraum kompatibel ist. Wählen Sie ein Betriebssystem nicht nur deshalb, weil es in einer anderen Branche üblich ist.
Häufig gestellte Fragen
Ist Linux besser für die Echtzeit-Fahrzeugsteuerung geeignet?
Nicht automatisch. Das System benötigt definierte Timing-Anforderungen und eine getestete Architektur. Kritische Steuerungsfunktionen können in einem dedizierten Steuergerät oder Mikrocontroller verbleiben, während Linux die Mensch-Maschine-Schnittstelle (HMI), die Protokollierung und die Kommunikation übernimmt.
Kann das PDS T12 sowohl Android als auch Linux nutzen?
Die aktuelle T12-Seite listet Android 13 und eine optionale Linux-Kernel-5.15- + QT5.15-Konfiguration auf. Bitte prüfen Sie vor der Entwicklung das genaue Produktionsimage, die Treiber, Schnittstellen und Supportleistungen.
Welches Modell eignet sich besser für ein kompaktes Linux-HMI?
Das T7 ist das kleinere Einstiegsmodell und verfügt über physische Funktionstasten. Das T12 eignet sich besser für eine große Multi-Panel-Oberfläche, mehrere Kameraansichten und eine umfassendere Fahrzeugvernetzung.
Schließen Sie die Systemskizze ab, bevor Sie den Bildschirm auswählen.
Bevor Sie sich für einen Linux-basierten Bordcomputer entscheiden, erstellen Sie eine einseitige Systemskizze. Diese sollte die Terminalausgabe, die im Steuergerät gespeicherten Daten, alle angeschlossenen Schnittstellen, den Zünd- und Abschaltvorgang, die Softwareverwaltung und die Wiederherstellungsmethode darstellen. Ist diese Skizze vollständig, lassen sich die benötigte Bildschirmgröße und Hardwarekonfiguration in der Regel deutlich besser festlegen.
Kontaktieren Sie PDS Technology mit Ihren Anforderungen an HMI-Layout, Linux und QT, Boot-Voraussetzungen, Schnittstellenliste, Kameraanzahl, Positionierungsanforderungen, Fahrzeugstromversorgung, Zielmarkt und Produktionsmenge. Unser Team unterstützt Sie bei der Auswahl einer geeigneten T7- oder T12-Konfiguration für die technische Bewertung.
Kontaktieren Sie uns
📧E-Mail: market@szpds.com
📞Tel: +86 13421822024
🌐Website: www.szpds.com
Haftungsausschluss
Die Informationen in diesem Artikel dienen lediglich als Referenz. PDS Technology Co., Ltd. übernimmt keine Haftung für Fehler, Auslassungen oder die Eignung des Inhalts für bestimmte Anwendungen. Produktspezifikationen können sich ohne vorherige Ankündigung ändern. Käufer sollten alle technischen Details vor der Verwendung mit unserem Team abklären.
Über PDS Technology
PDS Technology ist ein führender OEM/ODM-Hersteller von hochpräzisen RTK-GNSS-Terminals und Fahrzeugcomputern und beliefert seit 2011 die Branchen Landwirtschaft, Bauwesen, Bergbau, Taxi und Logistik.
Mit über 15 Jahren Erfahrung in der Forschung und Entwicklung für die Automobilindustrie bieten wir robuste, plattformübergreifende Geräte (Android/Linux/OpenHarmony) mit zentimetergenauer RTK-Positionierung, Schutzart IP66 und KI-Unterstützung. Unsere IATF16949-zertifizierten Werke haben weltweit über 100.000 Einheiten produziert und decken über 30 % des chinesischen Marktes für automatische Lenksysteme in der Landwirtschaft ab. Wir exportieren nach Japan, in die USA, nach Großbritannien, in die Türkei, nach Russland und in weitere Länder.
