Umstieg von CAN auf Ethernet zur Visualisierung

06/03/2008 - 13:46 von eble35 | Report spam
Hallo allerseits,

ich erstelle gerade eine Prozess-Visualisierung für unsere Anlagen.
Ich muss zwei Steuerungen einbinden (über CANbus/CANopen), die
Anbindung an die eigentliche Visualisierung (WinXP-Rechner) erfolgt
über einen OPC-Server, den ich auch entwickelt habe.
Nun haben wir aber beschlossen, dass der CANbus zur Visualisierung
eine Zwischenlösung ist. Wenn wir die genug getestet haben (und nach
einem HW-Neudesign) werden wir auf Ethernet umsteigen (wir habe
immerhin ca. 1000 Variablen).

Ich möchte mich nun vorab schon informieren wie denn eine solche
Lösung allgemein aussieht.

Ich gehe mal davon aus, dass Ethernet in der Praxis immer TCP/IP
heisst, ist das richtig? Sonst wüsste ich nàmlich nicht, wie ich
Ethernet 'nackt' auf unter WinXP ansprechen sollte. Und UDP kommt m.E.
für diesen Fall nicht in Frage.

Mit TCP/IP-Programmierung unter Windows (MFC, .NET) kenne ich mich
schon etwas aus. Allerdings weiss ich nicht so recht, was 'über' TCP/
IP so üblich ist. Ich möchte halt möglichst schon was nutzen, statt
dass wir uns selbst ein Protokoll überlegen. (Ich kenne das nur von
einem Sensor-Projekt, und da waren es halt String-Befehle).

Im Google fielen mir 2 Begriffe auf: Modbus/TCP und Industrial
Ethernet. Mit beiden kann ich im Moment noch nicht viel anfangen,
Modbus kenne ich nicht.

Ich weiß allerdings auch nicht, ob es sich lohnt, den CANopen-Stack
auf dieses Protokoll zu portieren. CANopen ist auf die kleine Byte-
Zahl pro Frame beim CAN von 8 Bytes zugeschnitten. Bei TCP/IP sollten
es ja schon 1024 und mehr sein. D.h. ich müsste vermutlich das gesamte
CANopen-Objektverzeichnis anpassen, da jetzt die Objekte deutlich
lànger sein können.

Natürlich wàre es auch schön, wenn wir einen OPC-Server 'von der
Stange' nehmen könnten.

Vielleicht hat der eine oder andere von euch ja ein paar wertvolle
Erfahrungen auf diesem Gebiet.

Ach ja: Ich will eigentlich *nicht* von Siemens-Only-Gedöhns abhàngig
werden.

Wie sieht es mit der 'Sicherheit' bei der Ethernet-Lösung aus? (Die
CAN-Lösung ist passwortgeschützt)

Ein Kollege meinte, dass wir ein File-System implementieren sollten
und dann die Nachrichten wie bei Linux mit FTP rüberschaufeln. Das
scheint mir aber nicht notwendig, und es verlangsamt sicher wieder
alles (vom Verschleiß zu schweigen). Wobei Echtzeit nicht unbedingt
erforderlich ist.



Viele Grüße

Johannes
 

Lesen sie die antworten

#1 Oliver Rutsch
07/03/2008 - 09:19 | Warnen spam
Hallo Johannes,

Hallo allerseits,

ich erstelle gerade eine Prozess-Visualisierung für unsere Anlagen.
Ich muss zwei Steuerungen einbinden (über CANbus/CANopen), die
Anbindung an die eigentliche Visualisierung (WinXP-Rechner) erfolgt
über einen OPC-Server, den ich auch entwickelt habe.



[...]

Ich möchte mich nun vorab schon informieren wie denn eine solche
Lösung allgemein aussieht.

Ich gehe mal davon aus, dass Ethernet in der Praxis immer TCP/IP
heisst, ist das richtig? Sonst wüsste ich nàmlich nicht, wie ich
Ethernet 'nackt' auf unter WinXP ansprechen sollte. Und UDP kommt
m.E. für diesen Fall nicht in Frage.



Also, erstmal hat Ethernet nichts mit TCP/IP, UDP oder auch nur IP zu
tun, denn das sind alles Protokolle, die lediglich ziemlich oft in
Ethernet-Netzwerken benutzt werden. Schau Dir mal in Wikipedia das
OSI-Modell an, dann verstehst Du was ich meine.
TCP/IP ist an sich schon recht màchtig und stellt sicher, dass Deine
Daten immer korrekt ankommen (wenn sie denn ankommen).
Aber auch für UDP gibt es einen breiten Anwendungsbereich. Falls auch
mal ein verlorenes Datenpaket tolerabel ist (Audio/Video-Übertragung,
aber vielleicht auch Visualisierung), dann ist UDP schneller (vor allem
im Latenzverhalten) und auch einfacher, da nicht verbindungsorientiert.
UDP kann man ein wenig mit den Daten auf einer seriellen Schnittstelle
vergleichen. Man schickt Daten hin und her und muss sich um alles andere
selbst kümmern (Fehler, doppelte Pakete, Handshake, Flusskontrolle usw.)
TCP/IP ist verbindungsorientiert und nimmt einen schon eine Menge Arbeit
ab, trotzdem ist die Behandlung im Fehlerfall keineswegs trivial. Dazu
gehören z.B. die Behandlung nicht reagierender Clients vom Server, der
erneute Verbindungsaufbau nach unerwarteten Verbindungsabbrüchen usw.
Trotzdem solltest Du mit TCP/IP bei Deiner Anwendung gut bedient sein.


Mit TCP/IP-Programmierung unter Windows (MFC, .NET) kenne ich mich
schon etwas aus. Allerdings weiss ich nicht so recht, was 'über' TCP/
IP so üblich ist. Ich möchte halt möglichst schon was nutzen, statt
dass wir uns selbst ein Protokoll überlegen. (Ich kenne das nur von
einem Sensor-Projekt, und da waren es halt String-Befehle).



Hmm, wenn Du mit einem OPC-Server kommunizierst, dann ist das Protokoll
doch eh schon definiert. Bei OPC würde ich mir aber schon überlegen, ob
man nicht gleich OPC UA (seit Herbst 2006) verwenden sollte.
So ganz habe ich es noch nicht verstanden, sollst Du jetzt 'nen
OPC-Server programmierren oder nur 'irgendwas' zur Visualisierung? Genau
dieser Punkt dürfte Deine Entscheidung beeinflussen.
Ansonsten ist ein einfaches Textprotokoll (mit Zeilenenden) nicht das
schlechteste. Einfach zu debuggen und gut zu erweitern. Wenn Du was
eigenes schreibst würde ich damit anfangen.


Ich weiß allerdings auch nicht, ob es sich lohnt, den CANopen-Stack
auf dieses Protokoll zu portieren. CANopen ist auf die kleine Byte-
Zahl pro Frame beim CAN von 8 Bytes zugeschnitten. Bei TCP/IP sollten
es ja schon 1024 und mehr sein. D.h. ich müsste vermutlich das
gesamte CANopen-Objektverzeichnis anpassen, da jetzt die Objekte
deutlich lànger sein können.



Auf Anwendungsebene brauchst Du Dich nicht um Paketgrößen zu kümmern.
Übertrage Deine Daten und gut iss.


Natürlich wàre es auch schön, wenn wir einen OPC-Server 'von der
Stange' nehmen könnten.



Du weißt aber schon wieviel es jàhrlich kostet um bei OPC mitspielen zu
dürfen?


Vielleicht hat der eine oder andere von euch ja ein paar wertvolle
Erfahrungen auf diesem Gebiet.

Ach ja: Ich will eigentlich *nicht* von Siemens-Only-Gedöhns abhàngig
werden.



löblich ;-)


Wie sieht es mit der 'Sicherheit' bei der Ethernet-Lösung aus? (Die
CAN-Lösung ist passwortgeschützt)



Im OPC-Standard gibt es auch dafür Lösungen (habe mir aber keine davon
nàher angesehen).
Falls Du einen eigenen Server schreibst, dann könnte ein wechselseitiges
Challenge/Response-Verfahren in Frage kommen, so wie das Smartcards
machen. Ist halt immer die Frage, WIE sicher Deine Applikation werden
soll und ob Du nur Authentifizierung brauchst oder gleich den ganzen
Datenverkehr verschlüsseln musst (dafür kàme dann z.B. SSL in Frage).
Eine Passwortabfrage, womöglich noch unverschlüsselt, kann jeder Depp im
Ethernet mitlesen (shared medium), das sollte man nicht vergessen.


Ein Kollege meinte, dass wir ein File-System implementieren sollten
und dann die Nachrichten wie bei Linux mit FTP rüberschaufeln. Das
scheint mir aber nicht notwendig, und es verlangsamt sicher wieder
alles (vom Verschleiß zu schweigen). Wobei Echtzeit nicht unbedingt
erforderlich ist.



Ich kenne ja Eure Anforderungen nicht, aber FTP heißt File Transfer
Protocol, dient also zur Übertragung von Dateien. Zum Austausch von
Nachrichten ganz sicher nicht das Richtige. Dafür reicht TCP/IP völlig aus.

Gruß,

Oliver

Ähnliche fragen