Umstieg von CAN auf Ethernet zur Visualisierung

Hallo allerseits,
ich erstelle gerade eine Prozess-Visualisierung fr 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 Zwischenlsung ist. Wenn wir die genug getestet haben (und nach einem HW-Neudesign) werden wir auf Ethernet umsteigen (wir habe immerhin ca. 1000 Variablen).
Ich mchte mich nun vorab schon informieren wie denn eine solche Lsung allgemein aussieht.
Ich gehe mal davon aus, dass Ethernet in der Praxis immer TCP/IP heisst, ist das richtig? Sonst wsste ich nmlich nicht, wie ich Ethernet 'nackt' auf unter WinXP ansprechen sollte. Und UDP kommt m.E. fr 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 mchte halt mglichst 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 msste vermutlich das gesamte CANopen-Objektverzeichnis anpassen, da jetzt die Objekte deutlich lnger sein knnen.
Natrlich wre es auch schn, wenn wir einen OPC-Server 'von der Stange' nehmen knnten.
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-Gedhns abhngig werden.
Wie sieht es mit der 'Sicherheit' bei der Ethernet-Lsung aus? (Die CAN-Lsung ist passwortgeschtzt)
Ein Kollege meinte, dass wir ein File-System implementieren sollten und dann die Nachrichten wie bei Linux mit FTP rberschaufeln. Das scheint mir aber nicht notwendig, und es verlangsamt sicher wieder alles (vom Verschlei zu schweigen). Wobei Echtzeit nicht unbedingt erforderlich ist.
Viele Gre
Johannes
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hallo Johannes,

[...]
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.

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.

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

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

löblich ;-)

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 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hallo Oliver,
erstmal danke fr deine Antwort.
Siehe unten:
...

Ist mir bekannt. Ethernet: Layer2, IP:Layer3, UDP/IP:Layer4
OSI ist mir jetzt aber zu fern von der Praxis ;) Entschuldige, aber OSI ist m.E. was fr Theoretiker. Wurden die 7 Layer jemals alle gebraucht? Hat irgendjemand in der Praxis schon den OSI-Protokoll-Stack (ja, den gibt's!)eingesetzt? Lies' mal dazu "Open Systems Networking TCP/IP and OSI " von Piscitello/Chapin". Ist zwar schon alt (1993), aber m.E. auch eine teilweise durchaus humorvolle Lektre.
Die Frage ist, ob jemand wirklich schon ernsthaft einen anderen L3 ber Ethernet implementiert hat als IP. Oder ob unter Windows Ethernet nackt berhaupt Sinn macht.

Genau.
Fr alles andere auer Streaming untauglich m.E. Und das mit dem "weniger Overhead" wird meist berschtzt, insbesonderen, wenn man selber doch wieder verbindungsorientierte bertragung haben will.
...

Das OPC-Protokoll definiert nur den Datenaustausch auf dem PC selber (OLE for Process Control), es gibt da also ein paar VB-Datentypen und ein paar OLE/COM- Interfaces. Das luft aber gewissermaen weit ber der Netzwerkschicht. Ich dachte nur, dass es Sinn macht, zwischen der Netzwerkschicht (TCP/IP) und dem OPC-Server-Protokoll (also im OPC- Server selbst, im Folgenden Zwischenprotokoll genannt) etwas zu nehmen, was schon vorhanden ist und nicht einfach Strings zu nehmen oder allgemeiner: nicht das Rad neu erfinden. Ich stelle es mir auch aufwendig vor mit Strings, da ich schon 1000 Variablen habe. Wenn die jetzt alle einen Namen bekommen und decodiert werden sollen. Bei dem Sensor-Projekt war das kein Problem, da gab es nur ca. 6 Befehle. Andererseits ist es wohl auch nicht gut, wenn ich die Variablen in einem Block austausche. Wenn sich deren Reihenfolge ndert? Oder ich bilde halt doch das jetzige CANopen-Objekt-Verzeichnis auf TCP/IP-Strings ab. Es gibt also zwei String-Befehle GET, SET und der Index/Subindex und bei SET der Wert als Parameter. Kurz: Wenn ich an der Stelle ein neues Protokoll definieren und implementieren muss, wird's wohl aufwendig.

Das ist m.E. zur Zeit nur interessant, wenn du kein Windows hast. Und fr Nicht-Windows-Systeme sieht's da noch sprlicher aus. Wir haben uns ein OPC-Server-Toolkit gekauft, das unter .NET luft. Insofern bin ich von COM schon verschohnt. ;)

Nein, ich habe bereits einen OPC-Server (mit dem obigen Toolkit) und eine Visualisierung mit OPC-Client programmiert, wobei der OPC-Server aber intern auf CANopen beruht. Irgendwann soll die CANopen- Kommunikation durch Ethernet ersetzt werden. Und da mchte ich mich vorab ber Lsungsalternativen informieren. Im Idealfall kann ich die Kommunikationsschicht im OPC-Server austauschen und fertig. Austauschen heit nun wiederum, ich muss sie komplett neu machen und muss mir ein Zwischenprotokoll berlegen, oder ich muss sie neu machen und sollte aber ein fr diesen Fall bewhrtes Zwischenprotokoll implementieren, oder fr dieses Zwischenprotokoll gibt es eine API, oder... Eventuell gibt es fr Ethernet 'eher' OPC-Server von der Stange, die msste ich dann halt 'nur' noch konfigurieren. Die Visu steht ja eh schon, abgesehen von ein paar Variablen vielleicht.
...

Ich meinte wieder das o.g. Zwischenprotokoll, und das ist noch unter der Anwendungsebene. (Auerdem ist es ein weitverbreiteter Irrtum, dass TCP ein Paket nie fragmentieren wird. Wenn du ber TCP einen Paket von 1024 Byte Lnge schickst, knnen auf einmal 1024 Byte ankommen. Es knnen aber auch nur 512 oder nur 1 Byte auf einen Schlag ankommen.) In CANopen wird meist pro Variable ein Index im Objektverzeichnis angelegt. Der Client fordert jetzt einen Index an und bekommt die entsprechende Variable. Die Variable hat aber meist nur bis zu 4 Bytes. Das wrde unter TCP/IP ziemlich ineffizient. Da werde ich eher 'Indexe' fr meinen gesamten Variablenraum anlegen und dann alle auf einmal anfordern und bertragen. Hast du wohl auch gemeint mit "gut iss", oder? Das gilt v.a. fr Lesewerte. Die Setpoints werden ja selten bertragen, zumindest von der Visualisierung.

Nein, klre mich auf. Bei Softing habe ich mal den Preis fr ein Toolkit gesehen, der war glaub' 5-stellig. Aber Softing ist ja High- End. Wir haben ein deutlich gnstigeres, aber auch sicher lausigeres ; (
..

Ja, aber in unserer Branche hat nicht jeder Depp einen Netzwerk- Sniffer ;) Aber das mit SSL ist sicher ein Gedanke wert.
Johannes
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hallo Johannes,

Es ist immer etwas schwer den Kenntnisstand des anderen einzuschätzen, von daher sollte das nur die Unterschiede der Ebenen verdeutlichen. Ich halte das Modell aber auch nicht für sehr praxistauglich.

Naja, früher war zumindest IPX über Ethernet recht populär und NetBEUI war auch lange das Microsoftsche Hausprotokoll. Ich würde aber auch nicht auf die Idee kommen, heutzutage etwas anderes anderes als IP über Ethernet zu verwenden. Ohne Hacks kommt man, glaube ich, auch nicht ohne weiteres an Ebene 2 ran. Und wenn man's doch kann schlägt der Virenscanner Alarm ;-)

O.K., das habe ich jetzt mit OPC UA verwechselt, welches ja auch ein standardisiertes Protokoll über Rechnergrenzen hinaus implementiert. Wenn ich das jetzt richtig sehe, dann geht's also nicht um OPC an sich sondern um die Anbindung des OPC-Servers an die Hardware über's Netz.

Das ist genau das leidige Problem mit Binärprotokollen. Änderungen im Protokoll sind oft nicht mehr möglich (vor allem, wenn die Hardware schon 'draußen' ist) oder nur aufwendig in der Software umzusetzen. Aber eigentlich bietet sich dafür doch XML an? Keine Ahnung wie oft Du die Daten empfängst und wie schnell das vonstatten gehen muss, aber die größte Flexibilität hat man sicher damit. Ich weiss aber auch nicht, ob Deine Hardware in der Lage ist, XML zu schreiben, oder ob Du das entstehende XML noch zippen kannst. Mischformen wären auch denkbar, z.B. Protokoll textbasiert aber mit der Möglichkeit auch Binärdaten zu versenden (so wie HTTP). So nach dem Motto "Sende gezippte XML-Datei mit 4567 bytes" Oder Du schaust die doch noch einmal OPC-UA an, denn das definiert gerade auch für Embedded-Geräte ein Binärprotokoll.

Wenn diese sich soweit anpassen lassen, das sich die Hardware damit gut ansprechen läßt, dann wäre man fertig. Aber oft macht die Hardware Vorgaben, die sich mit Standard-OPC-Servern nicht erfüllen lassen. Ich kenne allerdings auch nicht alle Toolkits und kann nur sagen, dass unsere Hardware sich dafür nicht eignet ;-)

Ja, aber glücklicherweise verbirgt dies das API und im Regelfall braucht man sich auch nicht weiter darum zu kümmern. (ABER: s.u.)

Ja. Du hast aber insofern recht, falls ich jetzt alle 1000 Variablen einzeln anfordere und übertrage, werde ich durch die sich addierenden Latenzen ein ziemlich mieses Antwortverhalten bekommen. Nur mal als Beispiel: Wenn ich mit meiner Embedded-Hardware (Linux 2.6) mit einem textbasierten TCP/IP-Protokoll Anfrage-Anwort spiele, komme ich bei Fast-Ethernet so auf 300 Kommandos/s. Da würde ich dann auch alle Variablen auf einmal übertragen, das ist auf jeden Fall effizienter.

Die große Frage ist halt, ob die vorhandenen Toolkits ausreichen oder nicht. An die OPC-Spezifikationen kommt man jedenfalls nur als Mitglied ran und der "Corporate Member" kostet dann so 3KEuro im Jahr. Es gibt allerdings auch günstigere Mitgliedsformen (mit der einen oder anderen Einschränkung), dazu kenne ich allerdings nicht die Kosten.

Ich denke, das mitsniffen ist nicht so das Problem sondern meistens die Manipulationsmöglichkeiten durch Geräte, die sich ohne Authentifizierung ansprechen lassen.
Gruß, Oliver
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.