Ein Fahrzeugcomputer mit CAN-Bus leistet mehr, als nur zwei CAN-Anschlüsse bereitzustellen. Er muss die richtigen Nachrichten zum richtigen Zeitpunkt empfangen, ausgewählte Daten an eine Anwendung weiterleiten, mit seriellen Geräten und drahtlosen Verbindungen kompatibel sein und unter den verschiedenen elektrischen und Umgebungsbedingungen des Fahrzeugs zuverlässig funktionieren.
Für OEMs beginnt die eigentliche Herausforderung nach der Auswahl der Displaygröße. Integrationsteams müssen sich auf die Busarchitektur, Nachrichtendefinitionen, die Schnittstelle zum Betriebssystem, das Serviceverhalten und die Abnahmetests einigen. Dieser Leitfaden bietet eine praktische Checkliste für die Umwandlung eines CAN-Bus-Terminals in ein wiederverwendbares Produktionssubsystem.
Illustration zur PDS-Integration. Verkabelung, Protokolle und Softwareverhalten müssen am Zielfahrzeug validiert werden.
Definieren Sie die CAN-Bus-Fahrzeugrechnerarchitektur, bevor Sie die Hardware auswählen.
Ein CAN-Bus ist ein gemeinsam genutzter Differenzialbus. Mehrere elektronische Steuergeräte tauschen Datenpakete aus, und jeder empfangende Knoten entscheidet, ob ein Paket relevant ist. Die physikalische Schicht, die Bitrate, die Terminierung, die Steckverbinderrichtlinie und das Nachrichtenprotokoll müssen mit der Fahrzeugkonstruktion übereinstimmen. CSS Electronics bietet eine hilfreiche Einführung in den CAN-Bus für Teams, die eine gemeinsame Terminologie benötigen.
Die erste Entscheidung des Fahrzeugherstellers betrifft die zulässigen Funktionen des CAN-Bus-Fahrzeugcomputers. Er kann lediglich Daten überwachen, eine begrenzte Anzahl von Aktionen anfordern, als Gateway fungieren oder an einem privaten Netzwerk teilnehmen. Diese Rolle ist im Schnittstellensteuerungsdokument festzuhalten. Ein Überwachungsterminal und ein befehlsfähiger Controller erfordern unterschiedliche Test- und Cybersicherheitsmaßnahmen.
Identifizieren Sie außerdem jeden Bus, der mit dem Terminal verbunden ist. Nutzfahrzeuge trennen häufig Antriebsstrang, Karosserie, Anbauteile, Diagnosesysteme und private CAN-Netzwerke. Eine Vermischung dieser Systeme ohne Isolations- oder Gateway-Strategie kann zu unerwünschtem Datenverkehr, unerwünschtem Aufweckverhalten oder Fehlerfortpflanzung führen.
| Integrationsschicht | Designentscheidung | Erforderliche Nachweise |
|---|---|---|
| Physisch | Bitrate, Topologie, Terminierung, Kabel, Stecker und Isolation | Kabelbaumzeichnung, Oszilloskop- oder Analysatoraufzeichnung und EMV-Plan |
| Protokoll | Raw CAN, J1939, CANopen, ISO-TP, UDS oder proprietäres Format | Nachrichtendatenbank, Kennungen, Zeit- und Zustandsdiagramme |
| Betriebssystem | Treiber, API, Berechtigungen, Prozesspriorität und Wiederherstellung | SDK-Dokumentation, Beispielcode und Ergebnisse der Fehlereinspeisung |
| Anwendung | Dekodierung, Filterung, Protokollierung, Anzeige und Geschäftslogik | End-to-End-Testfälle mit aufgezeichneten Fahrzeugdaten |
| Lebenszyklus | Versionskontrolle, Updates, Diagnose und Außendienst | Konfigurationsgrundlage, Freigabeprozess und Wiederherstellungsverfahren |
Checkliste für CAN-Bus-RS232-RS485-Fahrzeugcomputer
OEM-Projekte kombinieren häufig CAN mit älteren seriellen Schnittstellen. Eine Checkliste für Fahrzeugcomputer mit CAN-Bus, RS232 und RS485 sollte jede Schnittstelle separat dokumentieren und anschließend den gesamten Datenpfad testen.
CAN-Bus
Bestätigen Sie die Anzahl der unabhängigen Kanäle, die CAN-FD-Unterstützung, die Bitraten, das Terminierungsverfahren, die Isolation, das Aufwachverhalten und die Steckerbelegung. Prüfen Sie, ob das Endgerät nur bestimmte Frames empfangen oder auch Nachrichten senden soll. Erfassen Sie die Buslast und die maximale Latenz mit dem kompletten Fahrzeugkabelbaum.
RS232 und RS485
Für einen Fahrzeugcomputer mit RS232-Schnittstelle müssen Spannungspegel, Baudrate, Flusssteuerung, Stecker, Kabellänge und Protokoll angegeben werden. RS232 wird üblicherweise als Punkt-zu-Punkt-Verbindung realisiert. RS485 kann im Halb- oder Vollduplex-Modus mit mehreren Knoten betrieben werden, daher müssen die Anforderungen an Terminierung und Vorspannung definiert werden. Gehen Sie nicht davon aus, dass identische Baudrateneinstellungen Protokollkompatibilität gewährleisten.
Führen Sie vor dem Einbau ins Fahrzeug einen Loopback- oder Gerätetest durch. Testen Sie anschließend den gleichzeitigen Datenverkehr über CAN, beide seriellen Kanäle, USB und die drahtlose Verbindung. Die gemeinsame Prozessorlast und die Interruptbehandlung können Probleme aufdecken, die bei Demonstrationen mit nur einer Schnittstelle nicht auftreten.
Illustration zur PDS-OEM-Integration. Das Schnittstellenverhalten muss anhand der angegebenen Produktkonfiguration bestätigt werden.
Steuern Sie die Nachrichtendatenbank und das Datenmodell
Die Anwendung sollte keine rohen Hexadezimal-Frames im gesamten Quellcode dekodieren. Definieren Sie eine Nachrichtendatenbank oder einen DBC, ordnen Sie physikalische Werte und Einheiten zu und generieren Sie eine getestete Dekodierungsschicht. Berücksichtigen Sie Aktualisierungsraten, Timeout-Verhalten, Behandlung ungültiger Werte, Byte-Reihenfolge, Skalierung und Signalbereiche.
Versionieren Sie die Datenbank mit der Fahrzeugsoftware, nicht nur mit der Terminalanwendung. Wenn ein Steuergerät eine Nachricht hinzufügt oder ein Signal ändert, muss das Integrationsteam wissen, welche Terminals, Cloud-Modelle und Testfälle betroffen sind. Speichern Sie repräsentative CAN-Protokolle, damit Dekodierungsänderungen ohne Fahrzeug nachvollzogen werden können.
Verwendet das Projekt SAE J1939 , dokumentieren Sie die Quelladressen, Parametergruppen, das Anfrageverhalten und die Diagnosebehandlung. Für CANopen oder ein proprietäres Protokoll stellen Sie entsprechende Zustandsautomaten und Fehlerdefinitionen bereit.
Wählen Sie das Betriebssystem und die CAN-API aus.
Ein CAN-Bus-Fahrzeugcomputer unter Linux kann seine Schnittstellen über das SocketCAN- Subsystem des Kernels bereitstellen. Das Softwareteam kann Standard-Socket-Operationen, Filter und Netzwerktools verwenden. Überprüfen Sie die Kernel-Version, den CAN-Treiber, die Empfangspufferkonfiguration und die Berechtigungen im Auslieferungs-Image und nicht nur auf einem Entwicklungsboard.
Unter Android kann der Anbieter eine Java-, Kotlin-, native oder JNI-API bereitstellen. Klären Sie, wie Anwendungen Frames empfangen, wie der Sendezugriff gesteuert wird und was bei einem Neustart des Dienstes geschieht. Der Integrationsplan sollte eine Überwachungs- oder Integritätsprüfung beinhalten, die bei einem gestoppten Prozess, einer unterbrochenen Schnittstelle oder einem Fehlerzustand des Busses die Wiederherstellung ermöglicht.
OpenHarmony-Projekte sollten eine ebenso spezifische Schnittstellendefinition erhalten. Eine allgemeine Aussage zur CAN-Unterstützung sollte vermieden werden. Der OEM benötigt die konkrete API-Oberfläche, ein Beispielprojekt, Berechtigungen, Informationen zum Lebenszyklusverhalten und Debugging-Möglichkeiten.
GNSS und 4G LTE hinzufügen, ohne die Fahrzeugschnittstelle zu schwächen
Ein GNSS-Fahrzeugterminal mit CAN-Bus kann Positions-, Bewegungs- und Fahrzeugzustandsdaten kombinieren. Definieren Sie die erforderliche Genauigkeit, Aktualisierungsrate, das Koordinatenformat, die Zeitquelle und den Korrekturdienst. Testen Sie die Antennenplatzierung mit dem realen Dach, der Fahrerkabine, der Ladung und nahegelegenen Funkgeräten. Behandeln Sie GNSS-Verlust und CAN-Timeout als unabhängige Zustände, damit eine nicht verfügbare Quelle die andere nicht beeinträchtigt.
Ein fahrzeugmontierter 4G-LTE-Computer erweitert diese Datenströme auf eine Flottenplattform, die Uplink-Verbindung sollte jedoch nicht als permanent verfügbar betrachtet werden. Legen Sie unterstützte Frequenzbänder, Carrier-Profile, Roaming-Verhalten, Antennenisolation, Datenlimits und Wiederverbindungszeiten fest. Nutzen Sie lokale Pufferung für wichtige Datensätze und definieren Sie, welche Felder sofort, periodisch oder erst nach einem Ereignis gesendet werden.
Datenbesitz und -zugriff müssen klar definiert werden. Fahrzeughalter benötigen möglicherweise Kontrolle über Standort-, Diagnose-, Fahrer- und Betriebsdaten. Terminal und Cloud-Plattform benötigen eindeutige Richtlinien für Authentifizierung, Autorisierung, Datenspeicherung und Fernsteuerung.
Schutz von Stromversorgung, Signalen und der Softwaregrenze
Die Fahrzeugstromversorgung umfasst Anlassspannungsspitzen, Lastabwurf, Starthilfe und das Schalten von Zubehör. Der CAN-Bus-Fahrzeugcomputer muss hinsichtlich Eingangsspannungsbereich, Transientenstandard, Sicherung, Erdung und Zündverhalten für die jeweilige Fahrzeugklasse spezifiziert werden. CAN- und serielle Schnittstellen benötigen unter Umständen auch eine galvanische Trennung oder einen Schutz, wenn sie mit externen Geräten verbunden werden.
CAN sollte erst dann als vertrauenswürdige Schnittstelle behandelt werden, wenn der OEM dies ausdrücklich definiert hat. Sendekennungen sollten eingeschränkt, empfangene Längen und Bereiche validiert, die Befehlsrate begrenzt und der Zugriff von Anwendungen auf nicht zugehörige Buskanäle verhindert werden. Sicherheitsrelevante Konfigurationsänderungen sollten protokolliert und signierte oder verifizierte Software-Updates unterstützt werden.
Der Kabelbaum muss wartungsfreundlich sein. Beschriften Sie die Steckverbinder, dokumentieren Sie die Pinbelegung, schützen Sie ungenutzte Ports und geben Sie gegebenenfalls das Anzugsmoment an. Selbst ein Anschluss, der auf dem Prüfstand einwandfrei funktioniert, kann ausfallen, wenn ein schwerer Kabelbaum an einem Steckverbinder zieht oder einen Verbindungssteg bildet, der den Bus stört.
Verwenden Sie eine Akzeptanzmatrix für die Produktionsfreigabe.
| Testbereich | Beispiel für ein Akzeptanzkriterium |
|---|---|
| Busgesundheit | Keine unbeabsichtigten Fehlerframes während normaler, Start-, Aufwach- und Herunterfahrvorgänge. |
| Datengenauigkeit | Die dekodierten Signale stimmen über den gesamten Betriebsbereich mit den Referenzmessungen überein. |
| Latenz | Kritische Daten erreichen die Anwendung innerhalb des vorgegebenen Zeitrahmens |
| Erholung | CAN-, serielle, GNSS- und Mobilfunkdienste werden nach Kabel-, Strom- und Netzwerkfehlern wiederhergestellt. |
| Energiezyklen | Konfigurations- und Pufferdaten überstehen die erforderlichen Zünd- und Batterieszenarien. |
| Aktualisierung und Rollback | Ein fehlgeschlagenes Update kann das Gerät auf eine bekannte, funktionsfähige Version zurücksetzen. |
Vor der Serienproduktion muss ein CAN-Bus-Fahrzeugcomputer eine genehmigte Matrix von Bus-, Latenz-, Wiederherstellungs- und Aktualisierungstests bestehen. PDS bietet OEM/ODM-Integrationsunterstützung für robuste Fahrzeugterminals und kann Schnittstellen mit dem Softwareplan des Projekts abstimmen. Der OEM bleibt weiterhin Eigentümer der fahrzeugspezifischen Schnittstellenspezifikation und muss den finalen Validierungsplan genehmigen.
Abbildung zur PDS-Validierung. Akzeptanzkriterien und Testausrüstung müssen vor der Produktionsfreigabe vereinbart werden.
Häufig gestellte Fragen
Was benötigt ein CAN-Bus-Fahrzeugcomputer, um Fahrzeugdaten zu empfangen?
Es benötigt eine kompatible CAN-Schnittstelle, die korrekte Bitrate und Terminierung, Zugriff auf den relevanten Bus, eine Nachrichtendatenbank und Software zur Dekodierung der erforderlichen Signale. Das Terminal muss außerdem Timeouts, ungültige Werte und Busfehler behandeln können.
Kann ein Fahrzeugcomputer CAN, RS232 und RS485 gleichzeitig nutzen?
Viele robuste Fahrzeugcomputer unterstützen diese Schnittstellen gleichzeitig, die genaue Kanalanzahl und -isolation hängen jedoch vom jeweiligen Modell ab. Testen Sie den gesamten erforderlichen Datenverkehr gleichzeitig und vergewissern Sie sich, dass das Betriebssystem jede Schnittstelle zuverlässig bereitstellt.
Ist J1939 dasselbe wie CAN-Bus?
J1939 ist ein Protokoll höherer Schicht, das in CAN-Netzwerken, hauptsächlich in Nutzfahrzeugen, verwendet wird. Ein Endgerät kann CAN physisch unterstützen, ohne die spezifischen J1939-Nachrichten oder das für das Projekt erforderliche Diagnoseverhalten zu unterstützen.
Sollen CAN-Daten auf dem Endgerät oder in der Cloud verarbeitet werden?
Nutzen Sie das Terminal für zeitkritische Filterung, Anzeige, Benachrichtigungen und Zwischenspeicherung. Senden Sie zusammengefasste oder ereignisgesteuerte Datensätze in die Cloud, sobald Netzwerkverfügbarkeit und Datenrichtlinien dies zulassen. Die Aufteilung sollte Latenz-, Datenschutz-, Kosten- und Offline-Anforderungen berücksichtigen.
Kontaktieren Sie uns
📧E-Mail: [email protected]
📞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.
