Sidebar Menu

Kommunikation und SPS

Viele Geräte, insbesondere ältere, verfügen über eine serielle Schnittstelle. Diese Schnittstellen sind oft leistungsfähiger als gedacht und ermöglichen den Komponenten einen Zugang zu vernetzten Firmenstrukturen. Diese Geräte brauchen nur einen Vermittler, der ihre Kommunikationsfähigkeiten auf das Intranet oder das Internet ausweitet. Wir haben das in den letzten Jahren oft realisiert. Als Vermittler haben wir hier Windows PCs mit bis zu 12 RS232 Schnittstellen oder aber Klein-SPSen , z.B. von Beckhoff oder Wago eingesetzt. Ein Beispiel ist z.B. die Vernetzung der Wilett Kodiergeräte

RaspberryPi4ModelB kleinViel kostengünstiger sind aber aktuell die vielen Einplatinen - Computer wie der Raspberry Pi. Als intelligente Schnittstelle zum Internet kann dieses Gerät die Weiterverwendung vieler teurer Altgeräte gewährleisten. Auf den stromsparenden Geräten laufen inzwischen fast alle Betriebssysteme - und natürlich ist eine serielle Schnittstelle mit an Bord, die für eine gewöhnliche RS232 Verbindung allerdings etwas modifiziert werden muß (MAX3225E).

So richtig Sinn macht der tolle OPC UA Stack eigentlich nur, wenn die Kommunikation in alle Richtungen ereignisgesteuert läuft.

In den 90ern war die große Kunst ein gutes PLS aufzubauen in erster Linie eine logische Gruppierung der Tags zu sinnvollen und bedarfsgerechten Blöcken. So konnte man selbst mit der gängigen S5 Schnittstelle R3964 eine ordentliche Performance aus so einer seriellen Schnittstelle holen, selbst bei 4000 Prozesspunkten. Aber natürlich haben die Clients, in dem Fall die Treiber des SCADA Systems die Blöcke gepollt. In Portionen mit unterschiedlichen Raten. Manche auch gar nicht, wenn es sich um Sollwerte oder Rezepte handelte.. Auch der H1 oder der FMS Treiber waren einfache Client Server Verbindungen, allerdings mit entsprechender Performance.

Als dann die ersten OPC DA Server an den Start gingen, hatte ich eigentlich mehr erwartet, aber eigentlich blieb von der Kommunikationsseite alles beim alten, nur das der OPC Server nun dazwischen hing und man kaum noch einen Einfluss auf die Blockbildung hatte.  Ehrlich gesagt war mir das anfänglich nicht bewusst und ich habe anfänglich viel Mühe in die Strukturierung der OPC Gruppen gesteckt. Es dauerte einige Zeit, bis ich erkannte, wie schlecht viele Server programmiert waren und dass sie sich um meine optimierten Gruppen überhaupt nicht scherten. Die haben einfach alles in einem von der SPS  gepollt. Natürlich gab es auch Ausnahmen, die durchaus an der Optimierung arbeiteten. Leider schien das niemanden zu kümmern, denn immer wenn ich den Servern etwas mehr als den Standard abverlangte, tauchten massenhaft Bugs auf. Ich hatte manchmal das Gefühl ich bin der erste, der diese Toolkits verwendet.

Beim UA Standard kann jetzt vieles Besser werden, aber nur wenn die Kommunikationsstruktur verändert wird. Ein Pollen über Netzinfrastruktur sollte jetzt endlich ein Relikt der Vergangenheit sein. Dazu ist es aber unumgänglich, den OPC Server in der SPS zu positionieren. ER kann dann direkt auf die Speicherveränderungen der SPS reagieren und Daten an seine Clients senden, wenn diese sich geändert haben.

Ja, es gibt auch UA Server, die weiter auf einem PC laufen und Daten zyklisch  von SPSen einlesen - da kann man aber auch gleich bei der klassischen DA Variante bleiben. Als Übergangslösung kann man das machen, wenn die SPS noch ein bisschen arbeiten soll, die SCADA Software aber schon erneuert wird. Dann kann die SPS später getauscht werden, ohne dass die SCADA Software noch großartig geändert werden müsste.

Zu meinem Entsetzen habe ich aber neulich festgestellt, das es noch sehr wenige SPSen mit eigenem OPC UA Server gibt. Viele bauen auf Hutschienen PCs mit einem OPC Server. Als dann sollte es zumindest eine  Soft - SPS werden. Ich werde hier demnächst mal eine Liste der verfügbaren SPSen veröffentlichen.

 

OP UA, eigentlich eine Weiterentwicklung des OPC XML Standards (2003), wurde erstmalig in 2006 released. Diese eigentlich logische Weiterentwicklung, die auf Websevices basiert und ein modernes und ausgeklügeltes Sicherheitskonzept verfolgt, ist lange nicht wirklich wahrgenommen worden. Erst der Begriff Industrie 4.0 der auf der Hannovermesse 2011 auftauchte, ließ den inzwischen 5 Jahre alten Standard wirklich in den Fokus rücken.

Was heißt das also nun, müssen jetzt alle Anlagen auf den neuen Standard umgestellt werden? Nach meiner Erfahrung mit der Geschwindigkeit mit der sich neue Technologien im produktiven Umfeld durchsetzten, wird es sicherlich noch 20 Jahre dauern, bis die letzten ihre alten Anlagen abgebaut oder modernisiert haben.

Das bedeutet für den OPC Standard: neue und alte System werden noch Jahrzehnte parallel betrieben werden. Neue Anlagenteile werden mit OPC UA verbunden, alte bleiben wie sie sind.

Andererseits haben die Hersteller schon vor längerer Zeit aufgehört ihre Classic Server zu pflegen und Fehler zu beheben. So gibt es auch immer wieder neue Probleme, z.B. durch Windows Updates. Die Angst ist nicht unberechtigt, das irgendwann die alten Kisten nicht mehr laufen.

opc logo 600x166Seit Jahrzehnten hilft der OPC Standard und die große Anzahl an verfügbaren OPC Server dabei, für PC Anwendungen in der Produktion, einheitliche Schnittstellen zur Feldebene zu schaffen. Vorher waren oft die individuellen Schnittstellen, z.B. in den sogenannten SCADA Systemen, ein erheblicher Kostenfaktor. Ich selbst habe mal einen Windows Device Driver entwickelt, der die Kommunikation zwischen iFix auf Windows XP und einer PCI Kommunikationskarte steuerte. Das war eine Investition von etwa 7-8T€. Hersteller von vernetzbaren Komponenten, lieferten die Schnittstelle von OT zu IT in Form von spezifischen OPC Servern meist gegen Aufpreis von etwa 500€.

Seit OPC gestaltet sich dieser Teil eines Softwareprojekts dann relativ einfach: passenden OPC Server kaufen und installieren, OPC Client Klasse schreiben oder anpassen und schon war die Verbindung zum Prozess hergestellt.