Zusammenfassung: Dieser Artikel analysiert einige Eigenschaften des CAN-Busses und dessen Anwendungsstatus in China. Er schlägt die Einführung international anerkannter, höherer CAN-Bus-Anwendungsprotokolle vor, um das Anwendungsniveau von CAN-Systemen in China zu verbessern, und stellt kurz das höhere CAN-Protokoll CANopen vor. Abschließend werden einige fortschrittliche CAN-Produkte und Entwicklungsmethoden aus dem Ausland präsentiert. Schlüsselwörter: CAN-Bus-Protokoll; CANopen-Protokoll; Middleware für eingebettete Software. Bei der Entwicklung eingebetteter Systeme, insbesondere verteilter Systeme, ist die Gewährleistung einer zuverlässigen und effektiven Kommunikation zwischen den Systemeinheiten entscheidend für den Erfolg des Systemdesigns, insbesondere in Netzwerken mit hohen Echtzeit- und Sicherheitsanforderungen. Es gibt verschiedene Lösungsansätze für dieses Problem, wie beispielsweise serielle RS232/485-Busse, CAN, ProfitBus, FF, WorldFIP, LonWorks und andere Feldbusse sowie eingebettetes Ethernet. Obwohl das serielle RS485-Busprotokoll eine geringere Leistung aufweist, ist es aufgrund seiner erheblichen Vorteile hinsichtlich Hardwarekosten und Entwicklungsaufwand in China weiterhin weit verbreitet. Mit der Entwicklung eingebetteter Systeme traten die Leistungsschwächen von RS485 zunehmend zutage und genügen nicht mehr den Anforderungen an leistungsstarke Echtzeitsysteme. Obwohl noch praktische Erprobung erforderlich ist, halte ich den CAN-Bus aufgrund jahrelanger Beobachtung und Erfahrung für die vielversprechendste Lösung. Gründe für die Wahl des CAN-Busses: Der CAN-Bus zeichnet sich durch hohe Leistung aus; seine Übertragungsdistanz beträgt bis zu 10 Kilometer; seine Datenrate erreicht bis zu 1 Mbit/s; er verfügt über einen robusten Fehlererkennungsmechanismus; sein Frame-Übertragungsverfahren mit Konfliktlösung durch Mehrfachzugriffe gewährleistet Informationsverlust; jeder Frame kann bis zu 8 Byte Daten übertragen und bietet so hohe Echtzeitfähigkeit. Diese Leistungsvorteile ermöglichen den Einsatz von CAN in vielen Bereichen, darunter die Automobilindustrie, die Schifffahrt, die Maschinensteuerung, die Fabrikautomation und die Gebäudeautomation. CAN bietet zudem erhebliche Hardwarekostenvorteile . Neben der Leistungsfähigkeit bietet der CAN-Bus im Vergleich zu anderen Feldbussen auch einen deutlichen Kostenvorteil. Intelligente Knoten benötigen für den Informationsaustausch einen CAN-Controller und einen CAN-Transceiver. Nach über 20 Jahren Entwicklung genießt CAN breite Unterstützung von führenden internationalen Halbleiterherstellern. Laut Statistiken der CIA (Automation CAN), der wichtigsten Förderorganisation für CAN, sind derzeit über 20 verschiedene CAN-Controller und -Transceiver sowie über 100 Mikrocontroller mit integrierten CAN-Controllern verfügbar. Auch bei den Entwicklungskosten bietet CAN klare Vorteile. Von weit verbreiteten 8-Bit-/16-Bit-Mikrocontrollern über DSPs bis hin zu 32-Bit-PowerPC-, ARM- und anderen Embedded-Prozessoren – alle verfügen über CAN-Bus-Hardware-Schnittstellen. Daher zeichnet sich CAN aus Hardware-Sicht durch einen hohen Integrationsgrad und eine breite Marktbasis aus, die andere Feldbusse nicht erreichen. Die CAN-Entwicklungsplattform ist zudem vergleichsweise einfach. Wenn Anwender für die Entwicklung einen Allzweck-Mikrocontroller mit CAN-Controller wählen, ist die CAN-Entwicklungsplattform identisch mit der eines Allzweck-Mikrocontrollers. Bei einem Mikrocontroller mit integriertem CAN-Controller ist lediglich ein Emulator erforderlich, der diesen Mikrocontroller unterstützt; die übrige Entwicklungshardware bleibt unverändert. Für die CAN-Entwicklung werden außerdem entsprechende Treiber benötigt. Anwender können basierend auf ihrem gewählten CAN-Controller eigene Treiber entwickeln. [ALIGN=CENTER]Abbildung 1: CANopen-Protokoll-Kommunikationsmodell[/ALIGN] Erweiterung der CAN-Anwendungen durch Protokolle höherer Ebenen : Im Vergleich zu anderen Feldbussen definiert CAN lediglich die Spezifikationen der Bitübertragungsschicht und der Sicherungsschicht (gemäß OSI-Standard). Diese Struktur ist auf die damaligen Gegebenheiten bei der CAN-Spezifikation zurückzuführen und ermöglicht zwar eine breitere Anpassungsfähigkeit an unterschiedliche Anwendungsbedingungen, bringt aber auch Nachteile für Anwender mit sich. Anwender müssen daher eigene Protokolle höherer Ebenen definieren, wenn sie das CAN-Protokoll einsetzen. Wie lässt sich die Anwendung des CAN-Protokolls auf eine tiefere Ebene heben und gleichzeitig Produktkompatibilität und Interoperabilität gewährleisten? Der international anerkannte Ansatz besteht darin, auf CAN basierende Anwendungsprotokolle höherer Ebene zu entwickeln, die ausschließlich auf der Anwendungsschicht eingesetzt werden. Nur so erreichen Produkte verschiedener Hersteller Interoperabilität, und ein gutes Anwendungsschichtprotokoll kann die Systemleistung für die Anwender deutlich verbessern. In den 20 Jahren der rasanten Entwicklung des CAN-Busprotokolls haben zahlreiche Fachbereiche Spezifikationen für übergeordnete Protokolle für CAN-Anwendungen formuliert. Zu den bekanntesten zählt die von der Society of Automotive Engineers (SAE) entwickelte Spezifikation J1939 für die Fahrzeugkommunikation. Diese Protokolle und Spezifikationen trugen maßgeblich zur Verbreitung von CAN bei, ihre Modularität war jedoch insgesamt nicht optimal, was ihre Anwendung im Allgemeinen auf bestimmte Bereiche beschränkte. Um die Reichweite von CAN zu erweitern, führten einige europäische Unternehmen das CAL-Protokoll (Application Layer CAN) ein. Obwohl CAL theoretisch fundiert und industriell realisierbar war, musste jeder Anwender ein eigenes Subprotokoll entwickeln, da CAL ein echtes Anwendungsschichtprotokoll ist. CAL kann als notwendiger theoretischer Schritt für die Anwendung von CAN angesehen werden, fand aber in diesem Bereich keine breite Akzeptanz. Ab 1993 entwickelte eine von Bosch geleitete europäische Organisation einen Protokollprototyp, aus dem die CANopen-Spezifikation hervorging. CANopen ist ein auf CAL basierendes Subprotokoll, das objektorientiert konzipiert wurde, sich durch hervorragende Modularität und hohe Anpassungsfähigkeit auszeichnet und auf ein breites Anwendungsspektrum erweitert werden kann. Nach der weitgehenden Fertigstellung der CANopen-Spezifikation übergab Bosch diese zur Pflege und Weiterentwicklung an die CIA. 1995 veröffentlichte die CIA das vollständige CANopen-Kommunikationssubprotokoll; innerhalb von nur fünf Jahren avancierte es zum wichtigsten Standard für eingebettete Netzwerke in Europa. CANopen definiert nicht nur die Anwendungsschicht und Kommunikationssubprotokolle, sondern auch zahlreiche Industriestandards für programmierbare Systeme, verschiedene Geräte, Schnittstellen und Anwendungssubprotokolle. CANopen-Geräte, die gemäß diesen Standards entwickelt wurden, ermöglichen Interoperabilität zwischen Produkten verschiedener Hersteller. Darüber hinaus ist das CANopen-Protokoll lizenzfrei; jede Organisation und jede Einzelperson kann Geräte entwickeln, die das CANopen-Protokoll unterstützen, ohne Lizenzgebühren zu zahlen. Dies ist einer der Hauptgründe für die rasante Entwicklung von CANopen. CANopen findet breite Anwendung in industriellen Steuerungssystemen der Automobilindustrie, im öffentlichen Nahverkehr, in Medizingeräten, in der Schiffselektronik und in der Gebäudeautomation und ist daher ideal für die Weiterentwicklung von CAN-Anwendungen. Die Kommunikation erfolgt über das CANopen-Protokoll . Dieses umfasst Standardspezifikationen für die Anwendungsschicht und die Kommunikation. Das zugehörige Kommunikationsmodell ist in Abbildung 1 dargestellt. In der CANopen-Anwendungsschicht kommunizieren Geräte durch den Austausch von Kommunikationsobjekten. Ein gut strukturierter, schichtbasierter und objektorientierter Entwurf bietet Anwendern ein klares Kommunikationsmodell. CANopen-Gerätemodell: Ein CANopen-Gerätemodul lässt sich in drei Teile unterteilen (siehe Abbildung 2). Die Kommunikationsschnittstelle und die Protokollsoftware ermöglichen das Senden und Empfangen von Kommunikationsobjekten über den Bus. Die Kommunikation zwischen verschiedenen CANopen-Geräten erfolgt durch den Austausch von Kommunikationsobjekten. Dieser Teil interagiert direkt mit dem CAN-Controller. Das Objektwörterbuch beschreibt alle vom Gerät verwendeten Datentypen, Kommunikationsobjekte und Anwendungsobjekte. Es bildet den Kern eines CANopen-Geräts. Das Objektwörterbuch fungiert als Schnittstelle zwischen Kommunikationsprogramm und Anwendungsprogramm. Das Anwendungsprogramm nutzt das Objektwörterbuch, um die CANopen-Kommunikation zu realisieren. Das Verständnis des Objektwörterbuchs ist entscheidend für das Verständnis des CANopen-Modells. Das Anwendungsprogramm wird vom Benutzer geschrieben und umfasst funktionale und Kommunikationskomponenten. Die Kommunikationskomponente implementiert die CANopen-Kommunikation durch Manipulation des Objektwörterbuchs, während die funktionale Komponente vom Benutzer gemäß den Anwendungsanforderungen implementiert wird. Kommunikation und Management des CANopen-Netzwerks erfolgen über verschiedene Kommunikationsobjekte. Um Funktionen wie Kommunikation, Netzwerkmanagement und Notfallbehandlung zu realisieren, definiert die CANopen-Spezifikation vier Standard-Kommunikationsobjekte: • Prozessdatenobjekte (PDOs). Der erste Typ von Kommunikationsobjekt ist das Prozessdatenobjekt. PDOs werden einem einzelnen CAN-Frame zugeordnet, wobei alle 8 Byte der Datenfelder zur Übertragung des Anwendungsobjekts verwendet werden. Jedes PDO hat eine eindeutige Kennung und kann nur von einem Knoten gesendet, aber von mehreren Knoten empfangen werden; dieser Modus wird als Produzent/Konsument-Kommunikationsmodus bezeichnet. PDOs können auf verschiedene Arten übertragen werden: Interne Ereignisse, externe Takte, Remote-Frame-Anforderungen und der Empfang von Synchronisationsnachrichten von bestimmten Knoten können die PDO-Übertragung initiieren. • Service Data Objects (SDOs): Der zweite Typ von Kommunikationsobjekten sind Service Data Objects (SDOs), die Konfigurationsinformationen mit mehr als 8 Byte übertragen können. Das SDO-Übertragungsprotokoll ermöglicht also die Übertragung von Objekten beliebiger Länge. Der Empfänger bestätigt jedes empfangene Segment und stellt so eine Punkt-zu-Punkt-Kommunikation zwischen Sender und Empfänger her (Client-Server-Modus). Zukünftig wird CANopen eine schnelle SDO-Übertragung ermöglichen, wodurch die Bestätigung jedes einzelnen Segments entfällt. Die Bestätigung ist dann erst erforderlich, nachdem das gesamte Objekt übertragen wurde. • Network Management Objects (NMTs): Der dritte Typ von Kommunikationsobjekten sind Network Management Objects (NMTs), zu denen Node Watch Objects (NW-Objekte) und NMT-Objekte gehören. NW-Objekte sind CAN-Frames mit einem Byte an Daten, die vom NMT-Masterknoten angefordert und gesendet werden. Dieses Byte enthält ein Triggerbit und sieben Datenbits, die den Status des Knotens angeben. Der NMT-Masterknoten sendet NW-Objekte periodisch. Die Länge des Übertragungszeitraums (Überwachungszeit) ist im Objektwörterbuch festgelegt und kann über SDOs konfiguriert werden. Darüber hinaus definiert das System eine Alarmperiode, nach deren Ablauf der NMT-Masterknoten eine Remote-Anfrage an den NMT-Slave-Knoten senden muss. Dieser Mechanismus stellt sicher, dass andere Knoten im System auch dann benutzerdefinierte Reaktionen ausführen können, wenn der NMT-Masterknoten nicht verfügbar ist. CANopen definiert außerdem drei spezifische Objekte für die Synchronisierung, die Darstellung des Notfallstatus und die Übertragung eines Zeitstempels. Das Synchronisierungsobjekt wird vom Synchronisierungshersteller periodisch im Netzwerk gesendet und dient als grundlegende Netzwerkuhr. Tritt in einem Gerät ein schwerwiegender interner Fehler auf, sendet ein Client für den Notfallstatus ein entsprechendes Objekt. Das Zeitstempelobjekt bietet einen gemeinsamen Zeitrahmen für Anwendungsgeräte. Um die CANopen-Spezifikation zu verstehen, ist es unerlässlich, das CANopen-Gerätemodell und die verschiedenen Arten von Kommunikationsobjekten zu kennen. Sobald diese beherrscht werden, können CANopen-Geräte, die internationalen Standards entsprechen, mithilfe verschiedener Standard-Gerätebeschreibungen entwickelt werden. Ausblick : In China ist die Zahl der Entwickler und Anwender von CAN-Systemen in letzter Zeit stetig gestiegen, und die Forschung zum CAN-Protokoll wird intensiviert. In vielen Bereichen, wie beispielsweise im Großprojekt 863 zur Entwicklung von Elektro- und Hybridfahrzeugen, hat sich CAN als Standardprotokoll für die Fahrzeugkommunikation etabliert. Auch die Energie- und Luftfahrtindustrie haben beachtliche Erfolge mit CAN-Anwendungen erzielt. Trotz des Booms von CAN-Anwendungen ist zu beachten, dass die meisten chinesischen Anwendungssysteme, obwohl das CAN-Protokoll in Europa und Amerika seit 20 Jahren und das zugehörige Anwendungsschichtprotokoll seit etwa 10 Jahren entwickelt werden, immer noch auf der CAN-2.0B-Spezifikation basieren und die Anwendungsschicht noch nicht ausreichend berücksichtigen. Dies ist bedauerlich. Darüber hinaus gibt es in China zu wenige Organisationen und Fachkräfte, die das CAN-Protokoll, insbesondere das höherwertige CAN-Protokoll, erforschen und weiterentwickeln, was der Verbreitung von CAN in China sehr schadet. Der Autor hofft daher, dass sich weitere engagierte Personen diesem Anliegen anschließen. Referenzen: 1. „CiA Draft Standard 301 (Version 4.02)“ 2. Prof. Dr.-Ing. K. Etschberger, „CAN-basierte Protokolle und Profile höherer Schichten“