跃钢 周, Dongfeng Motor Corporation
Einbinden des J1939-Protokolls in den Entwurf der CAN-Bus-Kommunikationsplattform.
Mit Hilfe der NI-LabVIEW-Systementwurfssoftware und einem NI-PXI-CAN-Kommunikationsmodul wird eine Methode zum Filtern von J1939-Protokoll-IDs entwickelt, um mehrere Frames entsprechend dem Protokollformat zu empfangen und zu senden und eine CAN-Kommunikationsplattform zu erstellen. Wir haben auch eine Hardware-in-the-Loop (HIL)-Simulation der elektrischen Umgebung eines kompletten Fahrzeugs implementiert und eine Motorprüfplattform aufgebaut, die das Senden und Empfangen von CAN-Bus-Nachrichten, die Speicherung und die Echtzeitanzeige umfasst.
Alle Nutzfahrzeuge, die die chinesischen Emissionsnormen National III bis National IV erfüllen, verwenden den CAN-Bus zur Kommunikation zwischen elektronischen Steuereinheiten (ECU), einschließlich Fahrzeug-ECU (VECU), Motor-ECU (EECU), Automatikgetriebebox-ECU, Instrumenten-ECU und Antiblockiersystem Bremssystem ECU. Das Fahrzeugsteuerungsnetzwerk hat den Nutzfahrzeug-CAN-Bus basierend auf dem J1939-Protokoll implementiert, kombiniert mit der Multipoint Control Unit (MCU), dem CAN-Controller und dem MCU-Knoten CAN-Transceiver-Struktur. Bestehende Lösungen für Straßen- und Motorprüfstände sowie HIL-Simulationstests für die elektrische Umgebung von Fahrzeugen, die einen PC, ein CAN-Kommunikationsmodul und eine Software umfassen, sind extrem kostspielig.
Da es in den CAN 2.0 B-Spezifikationen keine gemeinsamen Definitionen für industrielle Bus-Nachrichtenkennungen und Datenrahmen gibt, sind die Parameter willkürlich. Die Spezifikationen für die CAN-Bus-Kommunikation von Nutzfahrzeugen folgen dem SAE J1939-Protokoll, basierend auf CAN 2.0 B. Derzeit gibt es keine CAN-Bus-Kommunikationsmethode basierend auf LabVIEW und dem J1939-Protokoll in einer PXI-Steuergeräteanwendung für die heimische Automobilindustrie, also haben wir uns angeschickt, die LabVIEW-Software mit dem komplexen J1939-Protokoll zu kombinieren, um Nachrichten zu filtern, zu empfangen, zu synthetisieren, neu zu kombinieren und zu senden.
Unter Berücksichtigung der Merkmale des Nutzfahrzeug-CAN-Bus-Netzwerks haben wir eine CAN-Bus-Plattform basierend auf LabVIEW und dem J1939-Protokoll erstellt und in ein modulares NI-PXI-Schnittstellengerät für HIL-Tests an Motorprüfständen und in der Fahrzeugelektrik eingebettet.
Das J1939-Protokoll basiert auf der CAN 2.0 B-Spezifikation. Die 29-Bit-ID im erweiterten CAN 2.0 B-Frame ist so definiert, dass sie ein J1939-Kodierungssystem bildet, das Priorität (P), reserviertes Bit (R), Datenseite (DP), Protokolldateneinheit (PF), erweiterte Einheit (PS), Quelladresse (SA) und Datenfeld enthält (vgl. Abbildung 1). Die Anwendungsschicht des Open System Interconnection (OSI)-Referenzmodells enthält sieben Teile, die in einem oder mehreren CAN-Datenrahmen durch eine Protokolldateneinheit (PDU) eingekapselt und durch die physikalische Schicht an andere Geräteknoten im Busnetzwerk übertragen werden.
Verschiedene CAN 2.0 B-Gerätefunktionen senden unterschiedliche Nachrichteninformationen mit derselben ID, sodass CAN-Geräte, die gemäß einem bestimmten Herstellerprotokoll ausgewählt wurden, während der Systemintegration zu nicht erkannten oder inkonsistenten IDs führen können. Jeder Nachrichtenframe im J1939-Protokoll hat eine eindeutige Kennung und PGN, die jedem Knoten eine eindeutige Quelladresse zuweist und die Quelladresse auf die CAN-Kennung abbildet, um zu vermeiden, dass mehrere Knoten dieselbe Kennung verwenden. Zum Beispiel steht die ID 0CF00400 für eine Motordrehzahl- und eine Drehmomentnachricht.
Die CAN 2.0 B-Spezifikation definiert die Sicherungsschicht in sieben Schichten des OSI-Referenzmodells, was bedeutet, dass es sich um einen Low-Level-Standard handelt, wie in Abbildung 2 dargestellt. CAN-Bus-Produkte weisen in der Regel schlechte Kompatibilität, Austauschbarkeit und Integration auf. Umgekehrt ist J1939 ein High-Level-Protokoll gemäß der Anwendungsschicht des OSI-Referenzmodells, das Fahrzeuganwendungssignale (Parameter) und Nachrichten (Parametergruppe) definiert. Das Signal wird durch Parameter beschrieben, und jedem Parameter wird eine verdächtige Parameternummer (SPN) zugewiesen. Diese Parameter definieren die physikalische Bedeutung von Daten-Bytes im PDU-Datenfeld; so steht etwa SPN190 für die Motordrehzahl.
Die CAN 2.0 B-Spezifikation kann nur Single-Frame-Nachrichten übertragen, während das J1939-Protokoll Single- und Multiple-Frame-Nachrichten einschließlich Dialog und Broadcast übertragen kann. J1939 kann Nachrichten entsprechend dem Datenübertragungsprotokoll mit mehreren Frames packen, senden, empfangen, synthetisieren und neu organisieren.
Die Modulschnittstelle besteht aus einem NI-PXI-CAN-Dual-Port-Transceiver, einem SJA1000T-CAN-Controller, einem TJA1041T-Highspeed-CAN-Transceiver und einem TJA1054AT-Lowspeed-CAN-Transceiver. Die Datenverbindungsschicht des J1939-Protokolls packt Nachrichten gemäß dem PDU-Format und führt CAN-Datenrahmensynchronisation, Ablaufsteuerung, Fehlersteuerung und Flusssteuerung durch.
Gemäß J1939-Protokoll für die Bitübertragungsschicht enthält jedes Netzwerksegment
Darüber hinaus wandelt der CAN-Bus-Transceiver den Spannungspegel zwischen dem CAN-Bus und der MCU um.
Wie in Abbildung 3 dargestellt, verwendet die CAN-Bus-Nachricht, die auf dem J1939-Protokoll-Multitasking-Verarbeitungsfluss basiert, eine Erzeuger- und Verbraucherschleifenstruktur. Die Erzeugerschleife verwendet die Funktion „Elemente in Queue einfügen“, um Daten in die Nachrichten-Cluster-Queue einzufügen, und die Verbraucherschleife verwendet die Funktion „Elemente aus Queue entfernen“, um Daten aus der Nachrichten-Cluster-Queue zu entfernen. Die Queue kommuniziert zwischen Schleifen, um Konflikte zwischen mehreren Tasks zu vermeiden. Wenn die Datenproduktion schneller als der Datenverbrauch ist, verhindern die Queue-Puffer den Verlust von Nachrichtendaten.
Wie in Abbildung 4 dargestellt, implementierten wir die CAN-Bus-Kommunikationsplattform basierend auf LabVIEW und dem J1939-Protokoll in einer HIL-Fahrzeugsimulation der elektrischen Umgebung für einen Nachrichtenempfangstest. Wir haben die Plattform gleichzeitig mit dem Vector-CANoe-Modul verglichen. Abbildung 7 zeigt die EECU-Nachricht, die von einem stetig laufenden Motor empfangen wird. Innerhalb einer Sekunde kann das System eine 526-Frame-Nachricht von der EECU empfangen, ohne dass eine Nachricht verloren geht.
Die Nachricht „Motor-Brennstoffverbrauch“ gibt die Kraftstoffeffizienz des Motors in Echtzeit an. Die VECU empfängt die Nachricht im CAN-Bus-Netzwerk gemäß dem Nfz-Protokoll J1939, um das Schalten des Automatikgetriebes des Fahrzeugs zu steuern. Das ECU des kombinierten Instruments empfängt diese Nachricht und zeigt sie in Echtzeit an, um den Fahrer an gute Fahrgewohnheiten zu erinnern und das Fahrzeug so zu manipulieren, dass es die beste Kraftstoffeffizienz erreicht. Für optimale Motorleistung, Effizienz und Emissionsstandards kalibrieren wir die EECU, um die besten Einspritzimpulsbreiten-Kalibrierparameter zu erhalten. Nach der Kalibrierung führen wir einen Vergleichstest durch, um die Auswirkungen der EECU-Kalibrierung zu überprüfen.
Ein stationärer Motortest kann die Fahrzeugleistung bei konstanter Geschwindigkeit zeigen. Ein transienter Motortest unter variablen Arbeitsbedingungen simuliert den Motorzustand unter tatsächlichen Straßenbedingungen. Durch Vergleichen der Echtzeit-Kraftstoffverbrauchsnachricht und der tatsächlichen momentanen Kraftstoffverbrauchsmessung bestimmen wir die Steuerungsleistung der EECU.
Abbildung 8 zeigt einen Vergleich, bei dem die Prüfstandskurve des transienten Kraftstoffverbrauchs des Motors unter zehn (10) Arbeitsbedingungen gemessen wurde. Die vom CAN-Bus gemäß dem J1939-Protokoll empfangenen und geparsten EECU-Kraftstoffverbrauchsnachrichtendaten unterscheiden sich im Vergleich mit dem Test- und Prüfstands-Kraftstoffverbrauchsmessgerät deutlich, wenn der Motor unter niedriger Last läuft. Daher ist die tatsächliche Kraftstoffzufuhr gering, wenn der Motor unter geringer Last läuft. Soll- und Ist-Kraftstoffeinspritzmenge variieren stark aufgrund von Schwankungen des Common-Rail-Drucks, wenn der Motor unter niedriger Last läuft, was Schwankungen der Kraftstoffmenge verursacht. Die beiden Kurven stimmen in der Regel überein: Die über den CAN-Bus empfangenen Zielwerte für die Kraftstoffeinspritzung des Motors ähneln sehr den tatsächlichen Messwerten, und Trend und Timing sind synchronisiert. Dies bedeutet, dass die EECU-Kalibrierung den besten Einspritzimpulsbreiten-Zielwert erzielt hat.
Die auf dem J1939-Protokoll basierende CAN-Bus-Kommunikationsplattform und die PXI-Plattform von NI bildeten eine Grundlage für die Implementierung eines NI-CAN-Moduls in einer CAN-Bus-Kommunikationsanwendung für Nutzfahrzeuge. Die Plattform ist vielversprechend für zukünftige Anwendungen wie Motor-Bench-Tests, HIL-Tests zur Simulation der elektrischen Umgebung von Fahrzeugen, Realisierung von Filtern, Erkennung, Synthese, Empfang, Verpacken, Übertragung, Speicherung, Parsing, Berechnung und Anzeige von Echtzeit-CAN-Bus-Nachrichten.
Mit leistungsstarker LabVIEW-Mathematik-Analyse und Queue-Verarbeitung, NI-PXI-Geräten und einem CAN-Schnittstellenmodul, das sich für eine raue Fahrzeugtestumgebung eignet, bietet dieses System Funktionen zur CAN-Bus-Nachrichten-Informationsanalyse, die für mehrere Testbedingungen erforderlich sind. Es demonstriert die Synchronisation der von NI-PXI-Geräten erfassten Nachrichtendaten. Die vergleichende Analyse beweist die Echtzeitleistung und Authentizität von Testdaten.
Edelstahlumfang
Dongfeng Motor Corporation
China
zhouyg@dfl.com.cn