OPC im OSI Referenzmodell und Alternativen

T

TheMachinist

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich bin relativ neu in der Automatisierungstechnik und habe die Aufgabe zu recherchieren, wie eine bestehende Fertigung autonomisiert werden kann.

Ein Stichwort das fiel war OPC, nun habe ich mich etwas eingelesen . Habe ich es richtig verstanden, dass

-OPC DA nach dem ISO OSI Referenzmodell auf der Anwenderschicht (Schicht 7) angesiedelt ist, basierend auf SOAP (6), HTTP (5), TCP IP (4, 3) und Ethernet (2,1).
wohingegen OPC UA sogar die Schichten 7,6 und 5 abdeckt?

- Feldbusse wie Profibus oder Profinet decken doch auch diese Schichten ab und "Profibus ermöglicht die Kommunikation von Geräten verschiedener Hersteller ohne besondere Schnittstellenanpassungen." Wo ist dann der Vorteil von OPC? Bzw. gibt es Alternativen?

- ich habe gelesen man kann OPC auch drahtlos übertragen, wäre aber nicht so verbreitet. - Was ist denn das Problem, wenn es auf Ethernet bzw. TCP/ IP basiert?


Vielen Dank, wenn ihr das idiotensicher erklären könnt, oder noch einfach zu verstehende Grundlagen zum Lesen habt!
 
OPC-DA ist DCOM. Dazu findest du bestimmt etwas wie das in OSI Modell einzuordnen ist. Das nutzt jedoch nicht http o.Ä. auf den unteren Schichten (das ist OPC-UA). OPC-DA geht zwar auch übers Netzwerk, aber in dein meisten Fällen wird es nur rechnerintern verwendet. Es ist außerdem Windows-only.

OPC-DA mit DCOM über Rechnergrenzen hinweg, wie auch oder gerade OPC-UA kannst du natürlich drahtlos übertragen, da gibt es nichts zeitkritisches was das stören könnte. Bei Profibus sieht das aufgrund der genauen Timings schon anders aus, aber da gibt es auch drahtlose Lösungen, wenn auch es da nicht sonderlich verbreitet ist.

Zum Unterschied zwischen Profibus und OPC:
OPC kann Profibus als unterlagerten Protokollstapel verwenden, oder TCP/IP, nur IP, oder etwas ganz anderes. Der Vorteil oder der eigentliche Grund für OPC ist, dass du eine Client-Anwendung erstellen kannst die als OPC-Client fungiert. Damit kann deine Anwendung theoretisch mit jeder Steuerung über ein beliebiges Medium kommunizieren, solange der Hersteller dafür einen OPC-Server zur Verfügung stellt.

Beispiel:
Du schreibst eine Anwendung die Daten aus einer SPS visualisieren Soll.

Weg a)
DeineAnwendung-als-OPC-Client <-> OPC-Server <-> Profibus <-> Steuerung

Weg b)
DeineAnwendung-als-OPC-Client <-> OPC-Server <-> Ethernet TCP/IP <-> Steuerung

Weg c)
DeineAnwendung-als-OPC-Client <-> OPC-Server <-> RS232 <-> Steuerung

Die Strecke zwischen OPC-Client <-> OPC-Server kann jetzt z.B. rechnerintern oder rechnerübergreifend sein. Ein aktueller Ansatz ist es, einen OPC-UA-Server direkt auf der Steuerung laufen zu lassen.
 
Zurück
Oben