Umstieg von CAN auf Ethernet zur Visualisierung

Hallo allerseits,

ich erstelle gerade eine Prozess-Visualisierung f=FCr unsere Anlagen. Ich muss zwei Steuerungen einbinden (=FCber CANbus/CANopen), die Anbindung an die eigentliche Visualisierung (WinXP-Rechner) erfolgt =FCber einen OPC-Server, den ich auch entwickelt habe. Nun haben wir aber beschlossen, dass der CANbus zur Visualisierung eine Zwischenl=F6sung 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=F6chte mich nun vorab schon informieren wie denn eine solche L=F6sung allgemein aussieht.

Ich gehe mal davon aus, dass Ethernet in der Praxis immer TCP/IP heisst, ist das richtig? Sonst w=FCsste ich n=E4mlich nicht, wie ich Ethernet 'nackt' auf unter WinXP ansprechen sollte. Und UDP kommt m.E. f=FCr 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 '=FCber' TCP/ IP so =FCblich ist. Ich m=F6chte halt m=F6glichst schon was nutzen, statt dass wir uns selbst ein Protokoll =FCberlegen. (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=DF 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=FCsste vermutlich das gesamte CANopen-Objektverzeichnis anpassen, da jetzt die Objekte deutlich l=E4nger sein k=F6nnen.

Nat=FCrlich w=E4re es auch sch=F6n, wenn wir einen OPC-Server 'von der Stange' nehmen k=F6nnten.

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=F6hns abh=E4ngig werden.

Wie sieht es mit der 'Sicherheit' bei der Ethernet-L=F6sung aus? (Die CAN-L=F6sung ist passwortgesch=FCtzt)

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

Viele Gr=FC=DFe

Johannes

Reply to
eble35
Loading thread data ...

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

Reply to
Oliver Rutsch

Hallo Oliver,

erstmal danke f=FCr deine Antwort.

Siehe unten:

On 7 Mrz., 09:19, Oliver Rutsch wrote: =2E..

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=FCr 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=FCre.

Die Frage ist, ob jemand wirklich schon ernsthaft einen anderen L3 =FCber Ethernet implementiert hat als IP. Oder ob unter Windows Ethernet nackt =FCberhaupt Sinn macht.

Genau.

F=FCr alles andere au=DFer Streaming untauglich m.E. Und das mit dem "weniger Overhead" wird meist =FCbersch=E4tzt, insbesonderen, wenn man selber doch wieder verbindungsorientierte =DCbertragung haben will.

=2E..

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=E4uft aber gewisserma=DFen weit =FCber 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 =E4ndert? 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 f=FCr Nicht-Windows-Systeme sieht's da noch sp=E4rlicher aus. Wir haben uns ein OPC-Server-Toolkit gekauft, das unter .NET l=E4uft. 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 m=F6chte ich mich vorab =FCber L=F6sungsalternativen informieren. Im Idealfall kann ich die Kommunikationsschicht im OPC-Server austauschen und fertig. Austauschen hei=DFt nun wiederum, ich muss sie komplett neu machen und muss mir ein Zwischenprotokoll =FCberlegen, oder ich muss sie neu machen und sollte aber ein f=FCr diesen Fall bew=E4hrtes Zwischenprotokoll implementieren, oder f=FCr dieses Zwischenprotokoll gibt es eine API, oder... Eventuell gibt es f=FCr Ethernet 'eher' OPC-Server von der Stange, die m=FCsste ich dann halt 'nur' noch konfigurieren. Die Visu steht ja eh schon, abgesehen von ein paar Variablen vielleicht.

=2E..

Ich meinte wieder das o.g. Zwischenprotokoll, und das ist noch unter der Anwendungsebene. (Au=DFerdem ist es ein weitverbreiteter Irrtum, dass TCP ein Paket nie fragmentieren wird. Wenn du =FCber TCP einen Paket von 1024 Byte L=E4nge schickst, k=F6nnen auf einmal 1024 Byte ankommen. Es k=F6nnen 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=FCrde unter TCP/IP ziemlich ineffizient. Da werde ich eher 'Indexe' f=FCr meinen gesamten Variablenraum anlegen und dann alle auf einmal anfordern und =FCbertragen. Hast du wohl auch gemeint mit "gut iss", oder? Das gilt v.a. f=FCr Lesewerte. Die Setpoints werden ja selten =FCbertragen, zumindest von der Visualisierung.

Nein, kl=E4re mich auf. Bei Softing habe ich mal den Preis f=FCr ein Toolkit gesehen, der war glaub' 5-stellig. Aber Softing ist ja High- End. Wir haben ein deutlich g=FCnstigeres, aber auch sicher lausigeres ; (

=2E.

Ja, aber in unserer Branche hat nicht jeder Depp einen Netzwerk- Sniffer ;) Aber das mit SSL ist sicher ein Gedanke wert.

Johannes

Reply to
eble35

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

Reply to
Oliver Rutsch

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.