Inhaltsverzeichnis
Sprache / Language
English Deutsch
Loading...
Sorry, this page is not yet
translated. Like to try
Google Translator?
English

Beruf, Technologien

Ich bin Dipl.Physiker, arbeite als Director in der Software-Entwicklung bei der Vector Informatik GmbH.
Mein besonderes Interesse dabei galt immer dem Standard CANopen, dort arbeitete ich knapp 20 Jahre bis 2012 aktiv mit.

Nach Entwicklung des ersten Produkts, des CANalyzer, kamen im Laufe der Zeit dann viele weitere Produkte dazu, hier ist vor allem CANoe.CANopen zu nennen, das den komplette Entwicklungsprozess, ab Kommunikationsdesign und dessen Verifizierung, über Modulentwicklung und Test und Validierung unterstützt, und dabei sehr stark auf automatisierte Verfahren und modellbasierte Entwicklung setzt.

CANopen war dabei nicht mal das erste Higher Layer Protocol HLP auf CAN. Das HLP mit dem höchsten Stellenwert wurde dann SAE J1939, das mittlerweile bei nahezu allen Truck-OEMs weltweit anzutreffen ist. Zu nennen sind dann noch NMEA2000 und ISOBUS, eine komplette Liste würde den Rahmen hier aber sprengen.

Relativ neu (2009) hinzugekommene Arbeitsgebiete waren dann Mess- und Testwerkzeuge für die Luftfahrt und Mess-und Testwerkzeuge für die Fahrzeug-Ad-hoc-Netze, auch als Car2x bezeichnet.
Seit einigen Jahren entwickeln einige der Fahrzeug-OEMs erweiterte Kommunikationskonzepte, die modernen Anforderungen wie zum Beispiel von Kamera-basierten Fahrerasistenzsystemen Rechnung tragen sollen. Dies brachte die Einführung von Ethernet im Kfz.

Nach den positiven Erfahrungen bei Car2x und IP entschloss sich Vector Anfang 2013, eine seperate Vorentwicklung aufzubauen. Für deren Aufbau wurde ich zuständig. Die Themengebiete sind derzeit

Vector Informatik GmbH

Vector entwickelt Softwarewerkzeuge und -komponenten für die Vernetzung in elektronischen Systemen, die auf den seriellen Bussystemen wie CAN, LIN, FlexRay, Ethernet etc. basieren sowie auf CAN-basierten Protokollen wie SAE J1939, CANopen, ARINC 825 und weiteren. Der Stammsitz des Unternehmens ist in Stuttgart. Zur Vector Informatik gehören neben den Niederlassungen in Braunschweig, Karlsruhe, München, Regensburg, Hamburg einige Auslandstöchter in USA, Japan, Frankreich, Schweden, England, Korea, China, Brasilien, Italien und Indien.

Car2x - die Automotive Technologie von morgen

Car2x ist ein Sammelbegriff für eine Vielzahl von Forschungs- und Entwicklungsaktivitäten. Diese haben das Ziel, die Sicherheit der Mobilität zu erhöhen, die Verkehrseffizienz zu steigern sowie dem Bedarf an Komfort gerecht zu werden. Hierbei werden Funktionen untersucht, die durch Kommunikation zwischen Fahrzeugen oder zwischen Fahrzeug und Infrastruktur besser umgesetzt werden können oder überhaupt erst ermöglicht werden. Beispiele für solche Funktionen sind Kreuzungsassistent und Stauendewarnung.

Car2x wird häufig unterteilt in Car2Car und Car2Infrastructure, wobei bei letzterem noch unterschieden wird zwischen Car2Roadside, Car2Service, Car2Home und weiteren. Übliche alternative Bezeichnungen für Car2x sind V2V (Vehicle to Vehicle), V2I (Vehicle to Infrastructure), IntelliDrive, ConnectedVehicle und auch im weiteren Sinne ITS (Intelligent Transport Systems).

Besondere Herausforderungen bei der Entwicklung von Car2x-Systemen ergeben sich durch: Vector bietet zur Entwicklungsunterstützung eine Werkzeugkette Car2x
Quelle: Vector(419)

Luftfahrt-Datenbusse für Avionik, Triebwerkssteuerung und Kabinenelektronik

In der Luftfahrtindustrie sind eine Reihe von Bussystemen etabliert. Vector bietet für diese Vernetzungen eine durchgängige Unterstützung mit bewährten Produkten und umfassenden Dienstleistungen:

Protokoll Beschreibung Produkte
CAN proprietär Bisher wird CAN in der Luftfahrt vorwiegend mit proprietären Protokollen eingesetzt. Eine Vereinheitlichung der Nutzung erfolgt derzeit über ARINC 825 (siehe unten). CANalyzer.CANaero
CANoe.CANaero
ARINC 810 / 812 ARINC 810 und 812 spezifizieren die Kommunikation zwischen Modulen der Bordküche (Galley Master, Galley Inserts). Der Schwerpunkt liegt hierbei auf dem Power Management. CANalyzer.CANaero
CANoe.CANaero
ARINC 825 ARINC 825 spezifiziert sowohl die grundlegende Kommunikation innerhalb von CAN-basierten Subsystemen als auch zwischen CAN-Subsystemen, die beispielsweise per AFDX verbunden sind. Es bietet Adressierungsmechanismen, Kommunikationsmechansimen, eine Servicestruktur, Profilbeschreibungen u.v.m. CANalyzer.CANaero
CANoe.CANaero
ARINC 826 ARINC 826 spezifiziert den Software Data Load über CAN. Hierzu wurden die Mechanismen der ARINC 615A auf CAN angepasst und optimiert. CANalyzer.CANaero
CANoe.CANaero
ARINC 664 / AFDX® AFDX® (Avionics Full DupleX Switched Ethernet) dient als Next Generation Aircraft Data Network. Es findet bereits seinen Einsatz in A380, A350, B787 und weiteren Programmen.
AFDX ist registriertes Trademark von Airbus
CANoe.AFDX
CANaerospace CANaerospace wurde von der Firma Stock Flight Systems entwickelt. Das Protokoll hat Einsatzschwerpunkte bei Engineering Simulatoren, Simulationscockpits und insbesondere im italienischen Bereich bei Drohnen (UAVs). CANalyzer.CANaero
CANoe.CANaero
Ethernet Zusätzlich zu AFDX® findet auch Standard-Ethernet Verwendung, beispielsweise bei Entertainment-Systemen. CANalyzer.IP
CANoe.IP
Quelle: Vector(420)

Ethernet im Automobil

[+] Aufgrund steigender Datenmengen im Pkw durch Assistenzssysteme, Kameras und andere neue Technologien untersuchen die OEMs den Einsatz von Ethernet. Die beteiligten Firmen arbeiten in der OPEN Alliance SIG zusammen. Dort wird der Physical Layer BroadR-Reach reif gemacht und zulünftige Weiterentwicklungen untersucht. Vector ist hier auch Mitglied.
Seit 2012 arbeitet insbesondere BMW mit seinen Zulieferern am Einsatz in der ersten Serie.

Gänzlich andere Anforderungen führen dabei zu einer Nutzung von Ethernet, die sich sehr vom üblichen Internet, Firmennetzwerk oder Heimnetzwerkansatz unterscheiden. Daher bringt auch der Einsatz bekannter Werkzeuge wie Wireshark nicht den geforderten Nutzen.

Das Entwicklungswerkzeug CANoe.IP trägt dem Rechnung durch: Quelle: Vector(421)

CANopen

[+] Grosse Teile dieses Abschnitts stammen von http://de.wikipedia.org/w/index.php?title=CANopen&oldid=86501082 (welches ich selbst in Teilen geschrieben habe).

CANopen ist ein auf CAN (Controller Area Network) basierendes Kommunikationsprotokoll, welches hauptsächlich in der Automatisierungstechnik und zur Vernetzung innerhalb komplexer Geräte verwendet wird. Das Hauptverbreitungsgebiet von CANopen ist Europa. Jedoch steigen sowohl in Nordamerika als auch in Asien die Nutzerzahlen. Es wurde vorwiegend von deutschen mittelständischen Unternehmen initiiert und im Rahmen des ESPRIT-Projekts ASPIC unter Leitung von Bosch als Prototyp von 1993 bis 1995 erarbeitet. Seit 1995 wird es von der Organisation CAN in Automation '''(CiA)''' gepflegt und ist als Europäische Norm EN 50325-4 standardisiert.

Grunddienste von CANopen

In CANopen sind mehrere Grunddienste (Dienstprimitive) definiert. Diese Grunddienste sind: In CANopen werden neben diesen Client-Server-Diensten auch weitere Kommunikationskonzepte wie das Producer-Consumer-Konzept genutzt. Darin zeigt sich, dass CANopen kein klassisches Master-Slave-System ist. Ursprünglich deckt CANopen im OSI-Modell die Anwendungschicht (Schicht 7) ab und nutzt CAN als Schicht-2-Transportmedium. Seit 2006 sind jedoch auch vermaschte Netzwerke mit Routing-Möglichkeiten standardisiert.

Kommunikationsobjekte

Kommunikationsobjekte können folgendermaßen gegliedert werden in

Objektverzeichnis

Alle Kommunikationsobjekte und alle Anwenderobjekte werden im Objektverzeichnis (OV) (engl. Object Dictionary (OD)) zusammengefasst. Das OV ist im CANopen-Gerätemodell das Bindeglied zwischen der Anwendung und der CANopen-Kommunikationseinheit. Jeder Eintrag im Objektverzeichnis steht für ein Objekt und wird durch einen 16-Bit-Index gekennzeichnet. Ein Index kann wiederum bis zu 256 Subindizes enthalten. Dadurch können unabhängig von den "11-Bit-Identifiern" bis zu 65536 * 254 Elemente unterschieden werden. (Die Subindizes 0 und 255 können nicht frei verwendet werden.)In Profilen ist die Zuordnung von Kommunikations- und Geräteprofilobjekten zu einem jeweiligen Index genau definiert; somit wird mit dem Objektverzeichnis eine eindeutige Schnittstelle zwischen der Anwendung und der Kommunikation nach außen definiert.So ist beispielsweise jedem CANopen-Knoten im Netz bekannt, dass auf Index 1017h das Heartbeat-Intervall zu finden ist, und jeder Knoten oder jedes Konfigurationsprogramm kann lesend oder schreibend darauf zugreifen.
Indexbereich Verwendung
0000 nicht genutzt
0001-009F Datentypen (Sonderfall)
00A0-0FFF reserviert
1000-1FFF Kommunikationsprofil
2000-5FFF herstellerspezifischer Bereich
6000-9FFF bis zu 8 standardisierte Geräteprofile
A000-AFFF Prozessabbilder von IEC61131-Geräten
B000-BFFF Prozessabbilder von CANopen-Gateways nach CiA 302-7
C000-FFFF reserviert
Für jedes Kommunikationsobjekt existiert eine eindeutige COB-ID (Communication Object Identifier) im Netzwerk. Die COB-ID besteht aus 32-Bit-Werten, wobei die ersten beiden Bits jeweils eine objektspezifische Bedeutung haben. In einem 11-Bit-CAN-Netz haben die folgenden 19 Bits (29 bis 11) den Wert 0 und die letzten Bits (10 bis 0) entsprechen dem CAN-Identifier.Servicedatenobjekte stellen einen Dienst zum Zugriff auf das Objektverzeichnis bereit.Jedes CANopen-Gerät benötigt mindestens einen SDO-Server, welcher SDO-Anforderungen von anderen Geräten entgegen nimmt und bearbeitet.Per Default-Einstellung nutzen Nachrichten zum SDO-Server eines Geräts die Knotennummer des Empfängers + 1536 als COB-ID bzw. als "Identifier" für die CAN-Nachricht.Für die Antwort des SDO-Servers wird als "Identifier" die Knotennummer des Senders + 1408 verwendet.Mit diesen relativ hohen und somit niederpriorisierten IDs werden Einträge im OV übertragen.Für diesen SDO-Transfer existiert ein Protokoll, welches 4 Byte benötigt um die Senderichtung, den Index und den Subindex zu kodieren.Somit bleiben nur noch 4 Byte von den 8 Byte eines CAN-Datenfeldes für den Dateninhalt übrig.Für Objekte, deren Dateninhalt größer als 4 Byte ist, gibt es noch zwei weitere Protokolle zum fragmentierten SDO-Transfer.Im Gegensatz zu dem niederpriorisierten und mit Protokolldaten überladenen SDO-Transfer stellen die Prozessdatenobjekte eine schnellere Möglichkeit zum Transport von Prozessdaten zur Verfügung.Die zum PDO-Transfer genutzten "Identifier" liegen bei Defaulteinstellungen im COB-ID-Bereich von 385 bis 1407 und sind somit höherpriorisiert als die SDO-Nachrichten. Weiterhin enthalten sie nur Nutzdaten, und somit stehen 8 Byte zur Verfügung.Der Inhalt der Nutzdaten wird über PDO-Mapping-Einträge bestimmt.Dies sind Objekte im OV, die wie eine Zuordnungstabelle festlegen, welche Daten über ein PDO übertragen werden.Diese Daten sind wiederum Inhalte anderer Objekte des OV.In einem PDO können auch die Werte mehrerer Objekte übertragen werden, und die Empfänger des PDOs können entsprechend ihrer PDO-Mapping-Einträge nur Teile der Daten nutzen.Beim Empfang eines PDOs werden wiederum die Daten entsprechend den Mapping-Einträgen in jeweils andere Objekte des OV, z. B. in ein digitales Ausgangsobjekt, geschrieben.Die Übertragung von PDOs kann zyklisch, ereignisorientiert, abgefragt oder synchronisiert geschehen.Netzwerkverwaltungsobjekte dienen der Verwaltung des Netzes. So gibt es u.a. Nachrichten, welche eine Zustandsänderung in einem Gerät veranlassen oder globale Fehlermeldungen verbreiten.Das Sync-Objekt sendet oder empfängt beispielsweise die hochpriorisierte SYNC-Nachricht, welche der Synchronisation der Knoten im Netz dient und mit dem Zeitstempel-Objekt eine einheitliche Zeit im Netz sicherstellt.Daneben gibt es im Kommunikationsprofil und insbesondere in den Geräte-Profilen noch eine Vielzahl anderer Objekte.

Geräteprofile

Für eine Reihe von Geräteklassen wurden CANopen-Geräteprofile definiert.Diese Geräteprofile definieren die Funktionalität und den Aufbau des Objektverzeichnisses für die jeweiligen Geräte.Durch die Nutzung von CANopen-Geräten, welche einem bestimmten Profil entsprechen, wird eine höhere Unabhängigkeit von Geräteherstellern erreicht.Einige der Geräteprofile sind:
Standard Geräteklasse
CiA 401 IO-Module
CiA 402 elektrische Antriebe
CiA 404 Sensoren und Regler
CiA 405 Programmierbare Geräte (SPS) nach IEC 61131-3
CiA 406 Geber
CiA 408 hydraulische Antriebe
CiA 445 RFID-Schreib-Lesegeräte

Anwendungsprofile

Im Gegensatz zu den Geräteprofilen wird bei den Anwendungsprofilen nicht die Funktionalität einer Gruppe von Geräten (Antriebe, Encoder, Ein-/Ausgänge) beschrieben, sondern die Funktionen einer Anwendung. So gibt es z. B. Anwendungsprofile für Aufzugsanlagen (CiA 417), Schienenfahrzeuge (CiA 421) oder Müllfahrzeuge (CiA 422). Einige Anwendungsprofile sind:
Standard Anwendung
CiA 410 Neigungsmesser
CiA 412 Medizinische Geräte
CiA 413 Gateways zu LKW-Aufbauten
CiA 415 Sensoren für Straßenbaumaschinen
CiA 416 Türsteuerungen
CiA 417 Aufzugssteuerungen
CiA 418/9 Batterien und Ladegeräte
CiA 420 Extruder-Nachfolgegeräte
CiA 444 Kran/Spreader

Electronic Datasheets

Für die Nutzung von CANopen-Geräten sind weiterhin elektronische Datenblätter, sogenannte EDS-Dateien, nötig. Diese Dateien in einem standardisierten Textformat beschreiben sowohl die wichtigsten Parameter der Objekte der Objektverzeichnisse eines Gerätes als auch physikalische Parameter wie z. B. die unterstützten Baudraten. Konfigurationstools können EDS-Dateien einlesen und mit ihrer Hilfe mit dem jeweiligen Gerät kommunizieren und es ggf. parametrisieren.

Seit Anfang 2007 ist ein auf XML-basierendes Beschreibungsformat XDD standardisiert. Dieses Format basiert auf dem ISO-Standard 15745 und erlaubt eine detaillierte Beschreibung der Gerätefunktionalität. Dabei wird die Applikation unabhängig von CANopen beschrieben und die Parameter der Applikation den CANopen-Objekten zugeordnet.

Werkzeuge

Es gibt zeitsparende und qualitätssteigernde Werkzeuge für eine Vielzahl von typischen Aufgaben. Diese sind finden sich in Die komplette Lösung für die CANopen-Vernetzung.

SAE J1939

[+] Charakteristisch für J1939 ist die Verwendung der CAN-Technologie zur Vernetzung und Kommunikation sowie eine herstellerübergreifende Interoperabilität. Das Protokoll J1939 stammt von der internationalen Society of Automotive Engineers (SAE) und arbeitet auf dem Physical Layer mit CAN-Highspeed nach ISO11898.

Typische Einsatzgebiete des J1939-Protokolls sind: Es gibt eine Reihe von zeitsparenden und qualitätssteigernden Werkzeuge für eine Vielzahl von typischen Aufgaben. Diese sind finden sich in Lösungen für die J1939-Vernetzung.

ISO11783 - ISOBUS

Der J1939-basierte ISO-Standard 11783 beschreibt die CAN-basierte Kommunikation in offenen Netzwerken für den mobilen Einsatz im landwirtschaftlichen Bereich. ISO11783 ist ein Multi-Master-Netzwerk auf der Basis von CAN, dessen Protokoll mit J1939 harmonisiert ist. Wichtige Merkmale für den Anwender sind: Der Begriff ISOBUS beschreibt einen praktischen Mindestumfang an Funktionalität für Software und Hardware, den Steuergeräte bzw. Netze bereitstellen müssen. Dies ist notwendig, um die Interoperabilität zwischen verschiedenen Herstellern von Steuergeräten zu jedem Zeitpunkt gewährleisten zu können. Da dieser Standard aus der ISO11783-Norm zwischenzeitlich 13 Dokumente umfasst, die sich in einem unterschiedlichen Reifegrad befinden, erlaubt dies eine frühzeitige Implementierung von Komponenten.

Hierfindet sich die Vector-Werkzeugkette ISOBUS / ISO11783.

References

References(419) Vector-Website zu Car2x
(420) Vector-Website zur Luftfahrt
(421) Vector-Website zu CANoe.IP


Legend:
lime: Excellent source, hardly any errors
green: Very good source, only very few errors
black or blue: Quality of this source is not yet mentioned
orange: Good source, some errors
red: Source contains some true facts. All facts need to be checked.

A list of used references is in More topics/Literature