LIN, CAN, FlexRay
Restbussimulation und
HIL mit NI-XNET
Durch steigende Vernetzung und leistungsfähige Bussysteme entstehen neue Herausforderungen bei Modul- und Integrationstests immer komplexer und vernetzter werdender Embedded-Systeme. Bisher dominieren die Bussysteme LIN (Local Interconnect Network) und CAN (Controller Area Network) die Kommunikation im automobilen Umfeld. Immer leistungsfähigere Steuer-, Regel- und Sicherheitssysteme verlangen nach einer schnelleren, deterministischen und sicheren Kommunikation, die der neue Standard FlexRay erfüllt. Erstmals im BMW X5 zur Steuerung der ‚Adaptive Drive‘-Technologie eingesetzt, ermöglicht der fehlersichere Bus in Zukunft auch Drive-by-Wire-Anwendungen.
Auch in der Medizintechnik, der Automatisierungstechnik und der Luft- und Raumfahrt spielen Embedded-Bussysteme wie CAN, CANopen und FlexRay eine immer wichtigere Rolle. National Instruments bietet mit NI-XNET eine neue Hard- und Softwareplattform, die den gestiegenen Anforderungen gerecht wird. Leistungsfähige Hardware und eine einheitliche Software-API (Application Programming Interface) ermöglichen es, schnell Prüf- und Simulationssysteme für LIN-, CAN- und FlexRay-Netzwerke zu entwickeln. Neben einer konventionellen C/C++-API kann ebenso die komfortable grafische LabView-API verwendet werden. Auch ohne Programmierkenntnisse lässt sich der komplette Funktionsumfang mit der konfigurationsbasierten Software NI VeriStand zum Erstellen komplexer Hardware-in-the-Loop-(HIL)-Anwendungen nutzen.
Übersicht über die Produktreihe NI-Xnet
Die Produktreihe NI-XNET vereint leistungsstarke LIN-, CAN- und FlexRay-Schnittstellen mit einem optimierten Treiber, einer schnittstellenunabhängigen API und mitgelieferten Konfigurations- und Diagnoseprogrammen. Anwendungsgebiete sind die schnelle und einfache Prototypenerstellung, Simulation und Prüfung für Embedded-Netzwerke mit NI LabView, NI LabView Real-Time und C/C++. Die Produktreihe wurde von Anfang an auf Leistung und Bedienbarkeit in anspruchsvollen Anwendungen entwickelt und ist bestens gerüstet für einen Einsatz in Umgebungen mit niedriger Latenz und hoher Signaldichte.
Leistung und Bedienbarkeit in anspruchsvollen Anwendungen
Zentraler Baustein der NI-Xnet-Hardware ist die NI-Xnet-DMA-Engine, ein von NI entwickelter ASIC-Baustein. Er ermöglicht Datenübertragung zwischen dem Onboard-Controller auf der Hardware und der Software per Direct Memory Access (DMA) ohne CPU-Beanspruchung (Interrupt). Zusätzlich verringert sich die Latenz, ein häufiges Problem bei PC-basierten Systemen, von Milli- auf Mikrosekunden. Die große Performance der DMA-Engine ermöglicht auch das Streaming von 100 % Buslast auf beiden Bus-Schnittstellen der jeweiligen Karte. Somit ist sichergestellt, dass kein Frame verloren geht. Auf Echtzeitsystemen ist eine Lese-Schreib-Latenzzeit von weniger als 200 Mikrosekunden möglich. So können auch anspruchsvolle Hardware-in-the-Loop-Simulationen umgesetzt werden.
Auch für anspruchsvolle Hardware-in-the-Loop-Simulationen
Speziell bei Systemen mit mehreren Schnittstellen, gleichzeitiger Datenerfassung von Analog- und Digitalsignalen oder der Verwendung von Bilderfassungs- und Motorsteuersystemen ist der Synchronisationsbaustein RTSI (Real-Time System Integration) von Bedeutung. Da jedes System und jede Schnittstellenkarte über einen lokalen Taktgeber verfügen, entstehen Abweichungen der Zeitstempel der einzelnen Komponenten durch Drift der einzelnen Taktgeber – die einzelnen Zeitstempel werden unpräzise und sind nicht mehr synchron. Abhilfe schafft der RTSI-Baustein, über den sich ein gemeinsamer Master-Takt verwenden lässt. Zusätzlich kann die Messung über alle Messsysteme gleichzeitig mit Hilfe von Hardwaretriggern gestartet werden. Somit ist die Messung von Anfang an synchron und die einzelnen Systeme driften nicht mit der Dauer der Messung auseinander. Die Zeitstempel der Plattform NI-Xnet haben eine Auflösung von einer Mikrosekunde. Im Innenleben der NI-Xnet-Hardware befindet sich ein FPGA-Chip, auf dem jeweils eine „Soft“-CPU („Soft“ für „Software“) pro Schnittstelle implementiert ist. Die Soft-CPUs übernehmen die Aufgabe des Buscontrollers und kommunizieren über busspezifischen FPGA-Code mit den Bus-Transceivern, die die physikalischen Bussignale erzeugen und empfangen. Pro Schnittstelle sind 128 hardwarebeschleunigte zyklische Nachrichten möglich. Dadurch lassen sich Restbussimulationen ohne CPU-Belastung realisieren. Einmal gestartet, schreibt die Karte selbstständig die zyklischen Nachrichten mit den vordefinierten Zykluszeiten auf den Bus. Per Software werden nur neue Werte an die Karte gesendet, die diese dann bis zum Eintreffen aktuellerer Werte wiederholt. So kümmert sich der XNET-Treiber bei FlexRay automatisch um den Kaltstart des Busses und als LIN-Master um eine automatische Abarbeitung des LIN-Schedules.
Nachträgliche Anpassungen der Hardware sind möglich
Durch Verwendung des FPGAs sind auch nachträgliche Anpassungen der Hardware an beispielsweise neue Spezifikationen per Firmware-Update möglich. Letzter Hardware-Baustein ist der Bus-Transceiver. Als LIN-Transceiver wird der Atmel ATA6620 verwendet, als FlexRay-Transceiver der NXP TJA1080. Für CAN gibt es verschiedene Spezifikationen für Low-Speed, High-Speed und Single-Wire CAN. Hier wird speziell eine Karte mit per Software umschaltbaren Transceivern angeboten. Zusätzlich kann hier auch ein externer Transceiver verwendet werden, um Konsistenz mit anderen im Embedded-Netzwerk eingesetzten Transceivern sicherzustellen. Alle Transceiver sind vom Bus isoliert und verfügen über per Software zuschaltbare Terminierungswiderstände. Insgesamt sind momentan für die Plattform NI-Xnet 16 LIN-, CAN- und FlexRay-Varianten für PCI und PXI (PCI eXtensions for Instrumentation) verfügbar. Für die nahe Zukunft ist auch eine USB-Variante für den portablen Einsatz angekündigt. Neben der Hardwarepalette werden auch Software-Werkzeuge mitgeliefert. Im Lieferumfang jeder NI-Xnet-Hardware enthalten sind der Treiber für Windows und LabView Real-Time, die LabView- und C/C++-API inklusive zahlreicher Beispiele, ein Datenbankeditor und ein Busmonitor. Mit dem Busmonitor kann sofort überprüft werden, welche Nachrichten auf dem Bus unterwegs sind. Der komplette Busverkehr bis zu 100% Buslast kann in Dateien zur späteren Analyse mitgeloggt werden. Zu Testzwecken lassen sich einzelne Botschaften sowohl zyklisch als auch eventbasiert auf den Bus schreiben. Der Datenbankeditor dient zum Importieren, Bearbeiten und Speichern von CAN- und FlexRay-(Fibex)Datenbanken. In diesen Datenbanken werden die Zuordnung zwischen Signalen und Nachrichten sowie busspezifische Informationen wie beispielsweise Baudrate hinterlegt. Der Datenbankeditor und das dahinterliegende Konzept von Signalen und Nachrichten dient dazu, eine busunabhängige Abstraktionsschicht zu schaffen, die später die Programmierung deutlich vereinfacht. Alle Busdaten werden unabhängig von der Schnittstelle in das Asam-Fibex-Format (Fibex = Field Bus Exchange) importiert und gespeichert.
Sowohl zyklisch als auch eventbasiert
Bei der späteren Programmierung kann dann direkt auf die in den verschiedenen Nachrichten verpackten Signale zugegriffen werden, ohne dass der Anwender sich darüber Gedanken machen muss, in welcher Nachricht sich das jeweilige Signal an welcher Position befindet. Sind spezielle Anforderungen umzusetzen, bieten der NI-Xnet-Treiber und die API neben der abstrakten Signalebene auch kompletten Zugriff auf die fortgeschrittenen schnittstellenspezifischen Einstellungen und auf die Rohdaten der Nachrichten. Natürlich sind Mischanwendungen, bestehend aus Schreiben und Lesen, Signalen und Nachrichten, zyklischen und eventbasierten Komponenten, gleichzeitig auf einer einzigen Schnittstelle möglich. Bestehende Anwendungen auf der älteren NI-CAN-Produktreihe können auch mit der neuen NI-Xnet-Hardware verwendet werden. Zu diesem Zweck wurde eine Kompatibilitätsschicht implementiert, die es erlaubt, alte Anwendungen mit neuer Hardware auszuführen. Dabei schlägt sich die DMA-Engine in deutlich kürzeren Latenzzeiten sowie einer erheblich niedrigeren CPU-Auslastung nieder.
NI-Xnet-API im Detail.
Die LabView- und C/C++-API ähneln sich sehr stark, da beide ein benutzerfreundliches, schnittstellenunabhängiges Programmiermodell verwenden. Alle Operationen werden in sogenannten Sessions zusammengefasst. Die Session stellt eine Verbindung zwischen der NI-Xnet-Hardware und dem externen Netzwerk dar. Sessions werden entweder im LabView-Projekt statisch oder zur Laufzeit über die API dynamisch erstellt. Jede Session beinhaltet die verwendete physikalische Schnittstelle, Datenbankobjekte und den Kommunikationsmodus. Datenbankobjekte beschreiben dabei, welche Signale und Nachrichten verwendet werden und alle busspezifischen Kommunikationsdetails wie z. B. Zykluszeiten, Nachrichten- oder Slot-IDs und Nutzdatenlängen, sowie Informationen, ob die jeweilige Nachricht zyklisch oder eventbasiert abzusetzen ist. Der Kommunikationsmodus beschreibt die Richtung der Kommunikation, ob Signale oder Rohframes verwendet werden und wie Daten vom Treiber an die Hardware übergeben werden. Für Signale stehen als Schreib- und Leseoperationen die Modi „Single-Point“ (aktueller Wert), „Waveform“ (Resampling von/zu einem Signalverlauf mit festgelegter Samplerate) und „XY“ (Wert-Zeitstempel- Paar) zur Verfügung. Unabhängig vom Modus werden in den Datenbankobjekten festgelegte Zykluszeiten für gesendete Objekte von der Hardware selbst eingehalten. Beispielsweise wird bei einem zyklischen Objekt in einer Single-Point-Schreib-Session der letzte über die API geschriebene Wert so lange mit festem Hardwarezyklus wiederholt bis ein neuer Wert geschrieben wird. Bei Nachrichten können zum Schreiben und Lesen die Modi „Stream“ (Schreiben und Lesen von beliebigen Rohnachrichten unbeschränkt von einer Datenbank), „Single-Point“ (aktueller Wert) und „Queued“ (Übertragung der Nachrichten mittels FIFO) verwendet werden. Bei den beiden letzteren wird bei schreibendem Zugriff der Sessions die definierte Zykluszeit beachtet, falls die Nachricht als zyklisch definiert ist. Die verschiedenen Modi können auf jeder Schnittstelle bunt gemischt werden. Die einzige Beschränkung ist, dass jedes Frame nur in einer schreibenden Session pro Schnittstelle verwendet wird, da sonst inkonsistente Daten auf dem Bus entstehen können. Zu beachten sind hierbei vor allem Signal-Sessions, da es nicht möglich ist, die Nachrichten, welche die verwendeten Signale enthalten, in anderen schreibenden Sessions auf derselben Schnittstelle zu verwenden. Bei Lesezugriff können Nachrichten und die enthaltenen Signale auch in mehreren verschiedenen Sessions gleichzeitig auf derselben Schnittstelle verwendet werden. Durch dieses einfache, busunabhängige Abstraktionsmodell lassen sich also sowohl kurze Testapplikationen als auch komplexere, dafür hochdynamische Restbussimulations- und HIL-Applikationen erstellen.
Erweiterungen für NI-Xnet
In der Automatisierungstechnik wird häufig das Protokoll CANopen verwendet, wobei der CAN-Bus als Kommunikationsmedium eingesetzt wird. Es gibt aber fest definierte Zuteilungen für Nachrichten-IDs und Sendezeitpunkte. CANopen ist also ein High-Level-Protokoll, das auf CAN basiert, vergleichbar HTTP auf TCP/IP. Für CANopen ist eine LabView-Bibliothek verfügbar, mit der sich schnell und einfach ein CAN-open Master implementieren und damit beispielsweise Motoren steuern oder Sensoren einlesen lassen. Speziell bei Automobil-Steuergeräten (ECUs) werden die auch auf CAN-basierten Protokolle CCP (CAN Calibration Protocol) und XCP (eXtended Calibration Protocol) verwendet, die das Lesen und Schreiben von Kennlinien und Parametern der Steuergeräte erlauben. Außerdem können Messungen an den Ein- und Ausgängen der Steuergeräte vorgenommen und die Daten dann mit LabView oder C/C++ ausgewertet werden. Die genauen Kommunikationsparameter sind in ASAM-Datenbanken (.A2L-Datenbanken) hinterlegt, die sich importieren lassen. Die Protokolle KWP2000 (ISO 14230-3), Diagnostics on CAN (ISO 15765-3) und On-Board Diagnostics (OBD-II) werden eingesetzt, um Steuergeräte zu flashen, Diagnosesitzungen durchzuführen und Fehlercodes auszulesen. Dafür stellt National Instruments das Automotive Diagnostic Command Set für LabView und C/C++ zur Verfügung. Alle genannten Erweiterungen sind auch unter LabView Real-Time auf Echtzeitsystemen einsetzbar und gestatten die Entwicklung robuster, leistungsstarker Prüfstände.
Hardware-in-the-Loop mit NI VeriStand.
Ist der Aufwand einer Eigenentwicklung zu groß, lässt sich NI VeriStand mit der Produktreihe NI-Xnet für die Erstellung von Applikationen und Testständen zum Überwachen der verschiedenen Busse, für Restbussimulationen mit frei definierbaren Signalen und komplexen Hardware-in-the-Loop-Anwendungen einsetzen – ohne Programmieraufwand. Bei NI VeriStand handelt es sich um eine konfigurationsbasierte Entwicklungsumgebung zur Konfiguration von Echtzeittestabläufen. Sie ist in der Lage, ein Multicore-fähiges Echtzeitsystem zu konfigurieren, das analoge, digitale, FPGA- und Embedded-Bus-Schnittstellen verwendet. Außerdem gestattet sie das getriggerte Loggen in Dateien, die Erzeugung von Echtzeit-Stimulusprofilen und das Hinterlegen von Alarmen und Fehlerbehebungsroutinen. Zentraler Gesichtspunkt ist die Einbindung von Modellen, die einem Steuergerät beispielsweise den zugehörigen Motor simulieren. Der Vorteil ist hierbei die offene Architektur von NI VeriStand, mit der sich Modelle aus beinahe beliebigen Simulationsumgebungen einbinden lassen. Auch beliebige Hardware kann mittels sogenannter „Custom Devices“ integriert werden, falls sie nicht nativ unterstützt wird. Wegen der geringen Latenzzeiten ist die Produktreihe NI-XNET prädestiniert für diese Art von Anwendungen. Mittels weniger Klicks können in VeriStand CAN-, LIN- und FlexRay-Datenbanken, Protokollierungsfunktionalität, die für eine Restbussimulation benötigten Kanäle sowie Stimulusprofile und Modelle integriert werden. Zur Laufzeit lässt sich die Benutzeroberfläche dynamisch verändern, so dass es möglich ist, die gewünschten Informationen darzustellen. Auch der Busmonitor ist gleichzeitig verfügbar. Bereits fertige Funktionen ermöglichen die temporäre Unterbrechung von zyklischen Botschaften zum Test von Ausfallverhalten sowie die Verwendung von Checksummen (CRC) und Zählern (Countern). Wird die Integration von NI VeriStand in eine bestehende Prüfstandssoftware gewünscht, können über die VeriStand-.NET-API alle Aufgaben von der Konfiguration über die Implementierung der Benutzeroberfläche bis zum vollständigen Test eines Systems automatisiert werden. Die Kombination aus einfacher, konfigurationsbasierter Umgebung, Multicore-fähiger Echtzeit-Engine und nach außen offener Architektur für Erweiterungen ermöglicht das schnelle und kostengünstige Erstellen von einfachen Restbussimulationen synchronisiert mit analoger und digitaler Datenerfassung bis zu hochkomplexen HIL-Testsystemen mit mehreren Modellen.
Autor: Dipl.-Ing. Andreas Stark, Applications Engineer bei National Instruments
Kasten: Zusammenfassung
Die Produktreihe NI-Xnet für CAN, LIN und FlexRay wurde unter folgenden Gesichtspunkten entwickelt:
–
Einfach: Fundamentale Konzepte bekannt aus anderen LabView- und C/C++-APIs ermöglichen
einen leichten Einstieg.
–
Konsistent: Das verwendete busunabhängige Abstraktionskonzept schafft mehr Zeit für die
eigentlich zu implementierende Funktionalität.
–
Abgeschlossenheit: Neben dem einfach zu verwendenden Signalkonzept besteht die Möglichkeit,
alle busspezifischen Funktionen zu nutzen und auf Rohnachrichten zuzugreifen.
–
Leistung: Lese- und Schreiboperationen werden mit geringer Latenz und ohne Datenverlust bei
100 % Buslast durchgeführt, daher ist die Produktreihe für Echtzeit- und HIL-Anwendungen
geeignet.
Neben den Embedded-Bussystemen LIN, CAN und FlexRay werden auch die darüberliegenden Protokolle CANopen, CCP, XCP, KWP2000, Diagnostics on CAN und OBD-II unterstützt. Die FPGA-basierte Architektur ermöglicht Firmware-Updates bei nachträglichen Anpassungen der Busspezifikationen und zum Erweitern des Funktionsumfangs. Somit können mit der NI-XNET-Produktreihe schnell und einfach Anwendungen von simplen Busmonitoren über Restbussimulationen bis zu Hardware-in-the-Loop-Systemen realisiert werden.
