Umstieg von CAN auf Ethernet zur Visualisierung

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

Hallo Johannes,
  Quoted Text Here  
[...]
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.
  Quoted Text Here  
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.
  Quoted Text Here  
Auf Anwendungsebene brauchst Du Dich nicht um Paketgrößen zu kümmern. Übertrage Deine Daten und gut iss.
  Quoted Text Here  
Du weißt aber schon wieviel es jährlich kostet um bei OPC mitspielen zu dürfen?
  Quoted Text Here  
löblich ;-)
  Quoted Text Here  
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.
  Quoted Text Here  
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

Hallo Oliver,
erstmal danke für deine Antwort.
Siehe unten:
...
  Quoted Text Here  
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 für 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 Lektüre.
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.
  Quoted Text Here  
Genau.
Für alles andere außer Streaming untauglich m.E. Und das mit dem "weniger Overhead" wird meist überschätzt, insbesonderen, wenn man selber doch wieder verbindungsorientierte Übertragung haben will.
...
  Quoted Text Here  
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 läuft aber gewissermaßen 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.
  Quoted Text Here  
Das ist m.E. zur Zeit nur interessant, wenn du kein Windows hast. Und für Nicht-Windows-Systeme sieht's da noch spärlicher aus. Wir haben uns ein OPC-Server-Toolkit gekauft, das unter .NET läuft. Insofern bin ich von COM schon verschohnt. ;)
  Quoted Text Here  
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 möchte ich mich vorab über Lösungsalternativen informieren. Im Idealfall kann ich die Kommunikationsschicht im OPC-Server austauschen und fertig. Austauschen heißt nun wiederum, ich muss sie komplett neu machen und muss mir ein Zwischenprotokoll überlegen, oder ich muss sie neu machen und sollte aber ein für diesen Fall bewährtes Zwischenprotokoll implementieren, oder für dieses Zwischenprotokoll gibt es eine API, oder... Eventuell gibt es für Ethernet 'eher' OPC-Server von der Stange, die müsste ich dann halt 'nur' noch konfigurieren. Die Visu steht ja eh schon, abgesehen von ein paar Variablen vielleicht.
...
  Quoted Text Here  
Ich meinte wieder das o.g. Zwischenprotokoll, und das ist noch unter der Anwendungsebene. (Außerdem ist es ein weitverbreiteter Irrtum, dass TCP ein Paket nie fragmentieren wird. Wenn du über TCP einen Paket von 1024 Byte Länge schickst, können auf einmal 1024 Byte ankommen. Es können 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 würde unter TCP/IP ziemlich ineffizient. Da werde ich eher 'Indexe' für 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. für Lesewerte. Die Setpoints werden ja selten übertragen, zumindest von der Visualisierung.
  Quoted Text Here  
Nein, kläre mich auf. Bei Softing habe ich mal den Preis für ein Toolkit gesehen, der war glaub' 5-stellig. Aber Softing ist ja High- End. Wir haben ein deutlich günstigeres, aber auch sicher lausigeres ; (
..
  Quoted Text Here  
Ja, aber in unserer Branche hat nicht jeder Depp einen Netzwerk- Sniffer ;) Aber das mit SSL ist sicher ein Gedanke wert.
Johannes

Hallo Johannes,
  Quoted Text Here  
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.
  Quoted Text Here  
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 ;-)
  Quoted Text Here  
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.
  Quoted Text Here  
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.
  Quoted Text Here  
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 ;-)
  Quoted Text Here  
Ja, aber glücklicherweise verbirgt dies das API und im Regelfall braucht man sich auch nicht weiter darum zu kümmern. (ABER: s.u.)
  Quoted Text Here  
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.
  Quoted Text Here  
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.
  Quoted Text Here  
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