# Welcher OPC - Server?



## GFI (20 Januar 2010)

Hallo Forum Mitglieder,

wir möchten folgende Anwendung erstellen:

In einer Produktionshalle soll von ca. 30 Anlagen, jede Minute ca. 300 - 500 Messwerte

erfasst werden und in einer SQL Datenbank abgespeichert werden.
Die Anlagen verfügen über S7-SPS oder Mitsubishi mit Ethernet Schnittstelle.

Als Konzept, haben wir uns überlegt einen OPC-Server zu installieren, zu allen
Anlagen eine Verbindung auf zubauen und mit einer zweiten Software OPC to Database die Daten in eine SQL Datenbank zuschreiben. 

Meine Fragen:
1.) Welcher OPC Server sollte eingesetzt werden, gibt es unterschiede bei den angebotenen Produkten?

2.) Sollte die zweite Software OPC to database vom gleichen Anbieter kommen, was glaube ich nicht notwendig sein muß?

3.) Sind die Programme OPC to database (z.Bsp. Softing) flexibel genug um die
Abspeicherung in die Datenbank individuell zu gestallten, z.Bsp best. Werte
nur nach überschreiten von Grenzwerten oder nach Änderung, oder sollte
man die Abspeicherung der Werte mittels VB oder ähnlichen selbst übernehmen.

Gruß GFI


----------



## TCP/IP (20 Januar 2010)

Hallo,

es gibt ein paar Hersteller, deren OPC-Server viele verschiedene Steuerungen unterstützten. Eventuell müssen die einzelnen Treiber separat gekauft werden, aber Du musst Dich nur in ein System einarbeiten.

Siemens und Mutsibishi gibt es bei

http://www.inat.de/index.php?54&backPID=54&tt_products=512

http://www.matrikonopc.com/opc-drivers/plcs.aspx

OPC-Client-Lösung laufen normalerweise mit jedem OPC-Server, das ist ja der Sinn der Sache. 

TCP


----------



## joergel (20 Januar 2010)

Hallo,

wir benutzen seit ca. 8 Wochen den OPC Server TCPIPH1
von INAT und sind wirklich sehr zufrieden mit der Anwendung.
Der OPC Server sammelt z.Z. aus 7 SPS´en S5/S7 Daten die auf einen Zentralen BDE Datenserver geschaufelt werden.
Anlegen einer neuen Verbindung ist kein Hexenwerk ebenso das Zufügen neuer Variablen.

Allerdings sind die Lizenzkosten von ca. 1400 EUR nicht ganz unerheblich.

Grüße,


----------



## Dr. OPC (21 Januar 2010)

Jeder der OPC Server einsetzen will, sollte folgendermaßen vorgehen:

1) schauen ob der Original-Hersteller der SPS einen OPC Server anbietet
>> Hintergrund ist der: a) der Hersteller kennt das Protokoll und den Treiber (zur Kommunikation zur seiner SPS) am besten. b) er kann die Projektierung/Konfiguration der OPC Servers am Besten in seine Engineering-Tools integrieren.

2) schauen ob der Server getestet wurde, die OPC Foundation vergibt zwei Logos, die eine gewisse Grundfunktionalität und auch Kompatibilität sicherstellen: "self-tested" und "certified".
>> Hintergrund: dann ist zumindest davon auszugehen, dass dieser Server schon mal mit den "großen" Produkten zusammen getestet wurde und sich "spezifikationskonform" verhält. Das "certified" Logo haben bisher nur sehr wenige Produkte geschafft und gilt als "Qualitäts-Siegel".

In deinem Fall bedeutet das: SimaticNET-OPC Server für Siemens Steuerungen und einen weiteren MX OPC Server für die Mitsubishi Steuerungen.

Es gibt natürlich auch die beschriebenen Drittanbieter, die z.T. hervoragende Produkte anbieten: Kepware, Matrikon, Softing/Inat, etc. aber auch hier würde ich immer zu "getesteten" oder noch besser "zertifizierten" Produkten raten.

Auf der Webseite der OPC Fopundation gibt es den "Produktkatalog" hier sind die Testergebnisse "gelistet", da kann jeder nachschauen was er sich kauft  z.B. 

http://www.opcfoundation.org/Products/ProductDetails.aspx?CM=1&RI=412&CU=17

http://www.opcfoundation.org/Products/ProductDetails.aspx?CM=1&RI=839&CU=12

Zum Wegschreiben in eine Datenbank gibt es auch verschiedene OPC Client Produkte am Markt. z.B. DataLogger von SoftwareToolbox 
http://www.opcdatalogger.com/html/opccertification.html


----------



## derwestermann (21 Januar 2010)

Habe vor 2 Jahren mal in einer Firma, für die ich mal gearbeitet habe, nachgefragt welchen OPC-Server die noch mal nehmen.
Die Antwort war: "Wer nimmt heute noch einen OPC-Server?"
Da wird wohl lieber mit Prodave oder so gearbeitet.


----------



## GFI (21 Januar 2010)

*SPS direkt to SQL Database*



> 1) schauen ob der Original-Hersteller der SPS einen OPC Server anbietet
> >> Hintergrund ist der: a) der Hersteller kennt das Protokoll und den Treiber (zur Kommunikation zur seiner SPS) am besten. b) er kann die Projektierung/Konfiguration der OPC Servers am Besten in seine Engineering-Tools integrieren.


 
Die Erfahrung mit dem Orginal Hersteller, kann ich bestätigen, da ich gestern einige OPC Server getestet habe und diese bei neueren SPS (Q03UDE) die Protokolle noch nicht können.

Nun habe ich für die Lösung der Anwendung noch eine andere Idee, dies ganz ohne OPC - Server zu machen und direkt mittels 'MES-Tools' (zusätzliche Hardware für die Steuerungen), direkt in eine SQL - Datenbank zu schreiben, wird z.Bsp von Mitusbishi angeboten. D.h. die
SPS schreibt über Ihre Ethernet Schnittstelle direkt in eine SQL - Datenbank. 
Soviel mir bekannt ist können das auch einige SPS, welche mit Codesys programmiert werden und dafür werden Bibliotheken gestellt.

Hat jemand mit solchen Anwendungen schon Erfahrungen gemacht?

Oder hat die Lösung über OPC Vorteile die ich jetzt nicht sehe?

Gruß GFI


----------



## rudl (26 Januar 2010)

Wir setzen für die Verbindung zwischen SPSen und SQL Datenbanken SQL4Automation ein. Damit brauchst du keinen OPC-Server, sondern hast direkten Zugriff auf die SQL-Datenbank. Du kannst also direkt SQLStrings absetzen und erhälts die Antwort in ein zweidimensionales Array. Zur Zeit existiert erst eine Library für CoDeSys SPSen, die Siemens Library wird jedoch Anfangs März verfügbar sein.  Unterstützt wersen auch Stäubli, Kuka und Bosch Rexroth Roboter. Eine Erweiterung auf Mitsubishi könnte relativ schnell realisiert werden. Natürlich kannst du deine Libraries auch selber schreiben (Siemens und Mitsubish).


----------



## Dr. OPC (1 Februar 2010)

Eine proprietäre Lösung hat keine Nachteile ausser die Tatsache dass sie proprietär ist.

1) wenn etwas nicht geht, muss man auf die Lösung Lieferanten warten
2) bei Änderungen an HW und SW muss man seine Applikation anpassen
3) wenn der Lieferant pleite geht, kann man seinen Kunden nicht mehr bedienen
4) wenn man die Sourcen der proprietären Lösung hat, kann man sich mit viel Aufwand einarbeiten und die Probleme selber fixen

OPC-Lösungen haben auch nicht nur Vorteile, aber viele.


----------



## rudl (3 Februar 2010)

Dr. OPC schrieb:


> Eine proprietäre Lösung hat keine Nachteile aus die Tatsache dass sie proprietär ist.



[FONT=&quot]Der SQL4Automation Connector bietet lediglich die Möglichkeit eine Verbindung von einer SPS auf eine SQL Datenbank herzustellen. Enthält keine eigene Intelligenz. Fall also eine SPS eine Ethernetverbindung herstellen kann, kann mit der Datenbank kommuniziert werden. Somit wird der komplette Code in der SPS, die Daten in der Datenbank programmiert. Der SQL4Automation Connector ist eine abgeschlossene Software. Wenn neue Variablen angelegt werden, müssen nur Änderungen in der SQL-Datenbank und im SPS Code gemacht werden, Änderungen am Connector sind nicht nötig.
Im Gegensatz zum OPC Server gibt es nur einen Connector, egal welche Steuerung. Beim OPC Server empfiehlst du ja schon bei zwei Steuerungen, zwei verschiedene OPC Server einzusetzen. Wenn ich daran denke wieviele Abstürze ich mit schon nur einem OPC Server hatt.... :-s Für die bekanntesten Hersteller sind sogar schon Bibliotheken und Programmbeispiele vorhanden und werden laufend erweitert. Der Connector kann kostenlos getestet werden und muss erst gekauft werden, wenn er zu 100% seinen Vorstellungen entspricht.

[/FONT]





Dr. OPC schrieb:


> 1) wenn etwas nicht geht, muss man auf die Lösung Lieferanten warten
> 2) bei Änderungen an HW und SW muss man seine Applikation anpassen
> 3) wenn der Lieferant pleite geht, kann man seinen Kunden nicht mehr bedienen
> 4) wenn man die Sourcen der proprietären Lösung hat, kann man sich mit viel Aufwand einarbeiten und die Probleme selber fixen



Diese Punkte hat man wohl mit jedem Produkt. Schlussendlich ist man immer abhängig von Herstellern der Produkte die man einsetzt. Sei es Siemens, Microsoft, MySQL, einem Entwickler von einem OPC Server oder eben einer Firma die ein anderes Produkt (Hard- oder Software) entwickelt.
Wird das Produkt von einer grossen Firma entwickelt, sind zudem Änderungen nur sehr schwer, oder überhaupt nicht möglich. Dass Siemens eine Wunschliste in einem Forum liest und das Produkt dementsprechend anpasst ist leider Wunschdenken. Vor Konkursen sind wie die neusten Beispiele zeigen auch grosse Firmen nicht sicher....
Schlussendlich sollte man sich Zeit nehmen mehrere Möglichkeiten auszuprobieren und sich dann für die für einen beste Möglichkeit entscheiden.


----------



## Dr. OPC (3 Februar 2010)

Na dann sag ich es mal so:

alleine für die Siemens S7 fallen mir spontan ca. 8 OPC Server von verschiedenen Herstellern ein, von denen übrigens keiner "abstürzt" plus ungefähr 20 (weder "self-tested" noch "certified") die mitunter auch abstürzen können. (wie man den richtigen Server findet habe ich ja weiter oben schon beschrieben)

Aber ich kann mich natürlich auch (nacheinander) vor 30 SPSen setzen und bei jeder einzelnen die Programmierung ändern nur um ein anderes Feld aus der Datenbank zu lesen. Das ist eine Frage des Geschäftsmodels und der angebotenen Dienstleistung (ich persönlich würde versuchen meine Kunden auf eine andere Weise an mich zu binden, aber das mag jeder selbst entscheiden)

Ich gehe mal davon aus das dieser [FONT=&quot]SQL4Automation Connector gleichtzeitige Zugriffe auf die selbe Datenbank verwalten kann und sich nicht 29 SPSen verschlucken wenn mal ein Datenbankaufruf nicht vollständig beendet wurde.
[/FONT]


----------



## rudl (4 Februar 2010)

28 OPC Server, scheint als backe jeder so sein eigenes Küchlein, anstatt Synergien zu nutzen.

Die Frage ist halt immer, was man genau braucht. Benötigt man ein einfaches, eingeschränktes System und muss nur ein paar einfache Variablen mit einer Taballe austauschen oder benötige ich ein offenes, leistungsfähiges System, wo ich Abfragen über mehrere Tabellen mache, vollen Zugriff auf eine relationale Datenbank benötige, Stored Procedures auslösen kann usw usw...
Ich glaube dass dies die Zukunft ist und im zuge dessen dass auch objektorientierte Programmiersprachen mehr und mehr Einzug in die Automation erhalten, die Nachfrage nach leistungsfähigen Datenbankabfragen wächst. Denn wenn OPC wirklich so leistungsfähig und offen wäre, würde es wohl auch in der Informatik allgemein eingesetzt, ich bin jedoch froh, dass meine Bankdaten nicht über einen OPC-Server laufen. ;-)
Wenn du einen OPC Server für 30 SPSen einsetzt musst du in deinem OPC-Server die Variablen auch für jede SPS definieren.
Wenn du jedoch direkten Zugriff auf die Datenbank hast, kannst du mit einer intelligenten Datenbankstruktur und einer Variable, die die SPS identifiziert alles erschlagen...
Mit Kundenbindung hat dies nichts zu tun, zudem der Kunde alle Anpassungen selber machen kann.

Natürlich sind mit SQL4Automation mehrere Verbindungen parallel möglich.

Am Besten lädst du dir SQL4Automation mal selber runter und machst dir ein Bild davon. 

So und jetzt helfen wir doch einfach GFI bei seinem Problem, denn ich denke dazu ist dieser Thread bestimmt!!


----------



## Kadnezar (9 Februar 2010)

Ich verfolge das Thema schon seit einer Weile mit, da ich ein ähnliches System realisieren möchte (zwar nur leider nur 2 S7 SPS, aber trotzdem)

Ich finde die OPC Lösung besser. Habe selber zwar einige Erfahrungen im Bereich Programmierung, traue es mir aber nicht zu einen funktionsfähigen, und vor allem zuverlässigen OPC Server / Treiber für die Datenbank zu schreiben.

Die OPC Server der oben genannten Hersteller waren als Download auf der Webseite, habe etwas probiert/konfiguriert und konnte Daten Abfragen (mit OPC Client Testtool)

Was mir jetzt noch fehlt ist der Datentransfer OPC nach Datenbank. Hat da jemand Erfahrung, oder schon getestet (OPC Client for ODBC von MatrikonOPC vs OPCtoDatabase von Softing?)


----------



## Dr. OPC (10 Februar 2010)

Die Produkte auf deinem Einkaufszettel sind schon mal nicht schlecht. Ich würde noch "DataLogger" von Softwaretoolbox und "IndustrialDataBridge" von Siemens mit hinzufügen, wenn Du ohnehin am evaluieren bist. Von diesen Tools gibt es wirklich viele. Letzteres gab es mal im WinCC-Umfeld, bin mir aber nicht sicher ob es das noch gibt.

Bei den Features dieser Produkte solltest du darauf achten das sie "flexibel" genug konfigurierbar sind. 

1) bei Datenänderung in die DB schreiben
das ist für mich der standard Anwendungsfall "Kennlinienschreiber" jede Datenänderung (DataChange) bewirkt einen Schreibauftrag (inklusive Zeitstempel) an die Datenbank.
Vorteil: geringe Kommunikationslast
Nachteil: wenn sich der Wert nicht ändert, steht auch nichts in der DB (die Abstände zwischen den Zeitstempeln sind nicht konstant), dies muss bei der späteren "Interpretation" der Daten berücksichtigt werden. Eine "Lücke" in der Datenaufzeichnung bedeutet "in diesem Zeitraum hatte die Variable den Wert vom letzten Aufzeichnungszeitpunkt", also eine wagerechte Linie im Kennlinienschreiber. Einfach durch die Werte interpolieren geht nicht!

2) zyklisch in die Datenbank schreiben
das ist der klassische Kennlinienschreiber. 
Vorteil: "zeitgleiche" und "taktsynchrone" Aufzeichnung
Nachteil: erhöhte Kommunikationslast (bis runter zur SPS) und erhöhter Speicherverbrauch in der DB, denn es wird IMMER alles gelesen und auch alles in die DB geschrieben, egal ob es sich geändert hat oder nicht, nicht besonders intelligent und auch nicht besonders effektiv, aber der Klassiker.

3) bei Änderung eines Wertes werden alle anderen Daten (zeitgleich) gelesen
das ist für mich der "getriggert archivieren" Anwendungsfall bei den viele verschiedene Daten zusammengehören und "gleichzeitig" gelesen und zur Datenbank geschrieben werden müssen. Wenn der Vorgang angeschlossen ist wird der Trigger zurückgesetzt (Quittiermechanismus oder Handshake)

4) bei Änderung eines Wertes werden Daten aus der DB geholt 
das ist für mich der "Rezept holen" Anwendungsfall (Gegenrichtung von 2). Die SPS kippt ein Bit das dann als "trigger" dient um Daten aus der DB zu holen und mit einem Schreibauftrag an den OPC Server geschickt wird. Die SPS fordert ein Rezept an und bekommt es aus der Datenbank geliefert. Wenn der Vorgang angeschlossen ist wird der Trigger zurückgesetzt (Quittiermechanismus oder Handshake)

5) auslösen von StoredProcedures
schon eher was für "Advanced Users" aber durchaus sinnvoll. Es werden Prozeduren vordefiniert, also im Tool vorkonfiguriert und dann über "Trigger" nur noch ausgelöst

6) absetzen von StoredProcedures
aufwendige Programmierung in der SPS aber machmal geht es nicht anders, ist sicher nicht der Standard-UseCase. Komplette Prozeduren oder auch SQL-Statements werden als "Strings" in der SPS zusammengebaut und über Triggervariablen ausgelöst. Als Reaktion auf den Trigger wird die entsprechende Stringvariable über OPC gelesen und in Richtung Datenbank geschickt.

Und mal abgesehen von der Funtion sollte natürlich auf der Datenbankseite ODBC oder ADO gesprochen werden. Einige Tool bringen ihre "eigene" Datenbank mit (meist MS SQL) und können nicht ohne weiteres auf z.B. Oracle oder MySQL "umgestellt" werden. Zusätzlich sollte es auf Seite der Datenbank eine konfigurierbare "Langzeit-Archivierung" geben mit "Ringpuffer" und "Auslagerungs-Funktion" (Zeit- und/oder Volumenbegrenzt). Denn irgendwann ist jede Datenbank mal vollgeschrieben.


----------

