Re: Umstieg von CAN auf Ethernet zur Visualisierung
- From: Oliver Rutsch <orutsch@xxxxxxxxxxxx>
- Date: Fri, 07 Mar 2008 09:19:12 +0100
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.
Ich kenne ja Eure Anforderungen nicht, aber FTP heißt File Transfer
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.
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
.
- Follow-Ups:
- Re: Umstieg von CAN auf Ethernet zur Visualisierung
- From: eble35
- Re: Umstieg von CAN auf Ethernet zur Visualisierung
- References:
- Umstieg von CAN auf Ethernet zur Visualisierung
- From: eble35
- Umstieg von CAN auf Ethernet zur Visualisierung
- Prev by Date: Re: HGÜ statt Drehstromfernleitungen
- Next by Date: Re: Freileitung 230V
- Previous by thread: Umstieg von CAN auf Ethernet zur Visualisierung
- Next by thread: Re: Umstieg von CAN auf Ethernet zur Visualisierung
- Index(es):
Relevant Pages
|
