Strategie Datenaustausch Steuerung mit SQL-Datenbank

Drain

Level-2
Beiträge
224
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

welche Strategie/Techniken würdet ihr verwenden, um eine Produktionsanlage mit einer SQL-Datenbank zu verbinden.
Es sollen sowohl aktuelle Auftragsdaten (Auftragsnummer, Rezepte) aus der DB gelesen werden, wie auch produktspezifische Werte (Messwerte, ID-Kennzeichen, Stückzähler) in die DB zurückgeschrieben werden (Thema Rückverfolgbarkeit).

Stichworte: OPC-UA, übergeordnete Systeme (SCADA Prozessleitebene, MES, MDE und BDE) und sonstige Datenbankschnittstelle (z.B. SQL4Automation, bereits bei uns bei anderen Anlagen im Einsatz).

Danke für eure Gedanken zu dem Thema, mit dem ich mich gerade versuche theoretisch einzuarbeiten, da es zukünftig immer wichtiger für uns wird.

Drain
 
Wir machen sowas über OPC UA zusammen mit einer kommerziell erhältlichen Middleware, welche zwischen OPC UA und SQL-Queries "übersetzt". Die Middleware läuft dann auf irgendwelchen virtuellen Servern bei den IT-Leuten. Das funktioniert sehr gut. Außerdem reduzieren wir so die Zahl offener Kommunikationsports zu den SPSen in der Fertigungsebene.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde das alles über ein IPM/MES System regeln. Damit hatte ich als Integrator immer am wenigsten Stress. Auch Stichwort Prozessdaten/Datenerhebung.. wurde immer alles direkt ans MES zurückgesendet nach jedem Teilprozess / Ergebnis.. so muss die SPS keine Daten zwischenhalten und das Backend weiß alles.

Das gute daran ist auch, dass du Subsysteme (Schraubapplikationen etc.. alles was Zweit-Dritthersteller Geräte betrifft) auch direkt mit einbinden kannst und so auch die Kurven von Verschraubungen/Fügeprozessen auf dem Backend erhältst und diese auch gleichzeitig zur Seriennummer verlinkt sind.
 
Danke euch beiden schon mal :)

Ich würde das alles über ein IPM/MES System regeln
Wofür steht IPM?
Und wie wird ein MES-System an eine Steuerung angebunden, bzw. über welche Schnittelle werden die Daten ausgetauscht? OPC-UA?

Wir machen sowas über OPC UA zusammen mit einer kommerziell erhältlichen Middleware, welche zwischen OPC UA und SQL-Queries "übersetzt"
Diese Middleware ist dann ja sowas wie die Prozessleitebene, wenn ich das richtig verstehe.
Wie kann man sich so ein System programmiertechnisch vorstellen? Was läuft das drauf und wie wird das dann programmiert?
Das System muss ja dann aktiv werden und sich die Daten zur rechten Zeit von der Anlage/Steuerung holen und in die DB schreiben?
 
Diese Middleware ist dann ja sowas wie die Prozessleitebene, wenn ich das richtig verstehe.
Wie kann man sich so ein System programmiertechnisch vorstellen? Was läuft das drauf und wie wird das dann programmiert?
Das System muss ja dann aktiv werden und sich die Daten zur rechten Zeit von der Anlage/Steuerung holen und in die DB schreiben?
Die Middleware agiert selber als OPC UA Client bzw. Server und kommuniziert mit der Steuerung über entsprechende Trigger (bspw. Bitmeldung oder Wertänderung) bzw. ruft OPC UA Methoden auf. Die Verbindung zur Datenbank läuft dann über den jeweiligen Managementport der Datenbank.
In der Middleware kann man dann die gelesenen OPC UA Daten bspw. durch einfache Konfiguration an den Datenbanknode senden und vom Datenbanknode empfangene Daten per OPC UA wieder zur Steuerung senden. Die Programmierung erfolgt grafisch / mit Konfigurationsdialogen.

Prinzipiell ist die Middleware in der Lage nicht nur eine Kommunikation zwischen OPC UA und Datenbank sondern auch anderen Datensenken und -quellen herzustellen.

Wie gesagt, wir verwenden hier ein kommerzielles Produkt, welches man bei Google schnell findet. Andere Systeme, die du auch bei Suche nach "OPC UA Middleware" findest, haben bestimmt einen ähnlichen Funktionsumfang. Prinzipiell müsste das auch mit NodeRed funktionieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke euch beiden schon mal :)


Wofür steht IPM?
Und wie wird ein MES-System an eine Steuerung angebunden, bzw. über welche Schnittelle werden die Daten ausgetauscht? OPC-UA?
Das kommt ganz auf dein MES System an.. aber generell TCP ist immer möglich.

IPM = Integrierte Prozessdatenmanagement.

Da ich aber immer nur Integrator für die Sondermaschine war, weiß ich nicht welche Software im Hintergrund in der Leittechnik agiert hat.

Von Kistler das Prozessüberwachungssystem maXYmos TL bietet zB eine direkte IPM Schnittstelle an:
 
Ich kann @roboticBeet nur zustimmen.
Der Vorteil dabei ist, daß man das Thema Steuerung und IT an der Stelle trennen kann.
Denn die Datenbank wird in der Regel im Zuständigkeitsbereich der IT liegen. Wenn Du da mit irgendwas von der SPS-Ebene direkt drauf schreibst, dann geht der Ping-Pong los, wenns nicht funktioniert.
Auf die "Middleware" können beide Seiten draufschauen, weil sie die IT nicht überfordert und eben auch Software ist. So kann man schnell klären, welche Seite das Problem macht.
Ich würde es auch immer wieder so lösen. Zumal man da mit OPC UA die beste Zugriffskontrolle auf die SPS hat.
 
1) Mit dem Datenbank-Connector von SQL4Automation gibt es auch eine klare Schnittstelle OT (Steuerung)-IT und wir haben bisher gute Erfahrungen damit gemacht. Nur am Rande erwähnt.

2) Middleware-Datenbank
Die Programmierung erfolgt grafisch / mit Konfigurationsdialogen
Wie flexible kann ich da Daten aus der Datenbank auslesen? Ich möchte z.B. aus einer Datenbank den Fertigungsauftrag für diese Anlage auslesen und anschließend davon abhängig Fertigungsdaten zurückschreiben, sieht aktuell als SQL-Kommandos so aus:
SELECT FA, Grösse FROM ERP_Data WHERE Maschinennummer = 1234
INSERT INTO Maschine (Maschinennummer, Typ, Menge, Lagerplatz, Fertigungsauftrag, ..) VALUES (1234, '01', 2300, '1234-01', FA1234-567')


3) Middleware-Steuerung
Um die Daten synchron zu halten, stelle ich mir folgendes Konstrukt vor:
Middleware erkennt Flanke "Zyklus Ende" und verarbeitet anschließende die per OPC-UA bereitgestellten Daten der Anlage und setzt anschließend das Bit "Daten erfasst" an der Anlage, so dass dort der nächste Bearbeitungszyklus starten kann und z.B. die Messwerte in der Steuerung überschrieben werden können.
Sobald die Middleware die Daten erfolgreich in die DB geschrieben hat, wird wieder auf die Flanke "Zyklus Ende" der Anlage gewartet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
welche Strategie/Techniken würdet ihr verwenden, um eine Produktionsanlage mit einer SQL-Datenbank zu verbinden.
Ich würde da noch unterscheiden ob
  • die Datenbank Maschinenintern ist
  • die Datenbank Kundenseitig ist
Für Maschinenintern habe ich bisher gute Erfahrung mit "SQL4Automation" gemacht und bei kleinen Projekte einen eigenen SQL Kommunikationsbaustein genutzt.

Wenn die Datenbank in Kundenhand liegt, ist das wie schon von JSEngineering gesagt:
Denn die Datenbank wird in der Regel im Zuständigkeitsbereich der IT liegen. Wenn Du da mit irgendwas von der SPS-Ebene direkt drauf schreibst, dann geht der Ping-Pong los, wenns nicht funktioniert.
Da würde ich etwas möglichst einfach anzupassendes bzw. beobachtbares nutzen, wo man Fehler usw. schnell nachvollziehen kann.
 
1) Mit dem Datenbank-Connector von SQL4Automation gibt es auch eine klare Schnittstelle OT (Steuerung)-IT und wir haben bisher gute Erfahrungen damit gemacht. Nur am Rande erwähnt.
Ich kenne die Software im Detail nicht, habe mir aber gerade mal ein Video dazu angeschaut. Korrigiert mich daher bitte, sollte meine Aussage falsch sein. Ich möchte die Software nicht schlecht reden. Scheinbar (?) erfolgt die Kommunikation zwischen SPS und dem SQL4Automation Connector jedoch ohne Transportverschlüsselung und Authentifizierung, richtig? Das wäre bei uns ein absolutes No-Go und Showstopper und in unserer Sichtweise alles andere als eine klare IT-OT Schnittstelle. Aber nun gut. Für einen maschineninternen SQL Server, der auch maschinenintern auf einem IPC o. ä. läuft, wäre das vielleicht auch bei uns denkbar.

Wie flexible kann ich da Daten aus der Datenbank auslesen? Ich möchte z.B. aus einer Datenbank den Fertigungsauftrag für diese Anlage auslesen und anschließend davon abhängig Fertigungsdaten zurückschreiben, sieht aktuell als SQL-Kommandos so aus:
SELECT FA, Grösse FROM ERP_Data WHERE Maschinennummer = 1234
INSERT INTO Maschine (Maschinennummer, Typ, Menge, Lagerplatz, Fertigungsauftrag, ..) VALUES (1234, '01', 2300, '1234-01', FA1234-567')
Das ist ja eine sehr simple SQL Query. Die kannst du im grafischen Bereich dir zusammen klicken. Kein Problem. Für komplexere Sachen (Joins, temporäre Tabellen für serverseitige Berechnungen während der Abfrage, konditionelles Insert usw.) direkt auf dem Server, kann man sog. Stored Procedures nutzen. Damit kannst du deine SQL Queries direkt in SQL schreiben, auf dem Datenbankserver speichern und als "Methode" aufrufen.

Um die Daten synchron zu halten, stelle ich mir folgendes Konstrukt vor:
Middleware erkennt Flanke "Zyklus Ende" und verarbeitet anschließende die per OPC-UA bereitgestellten Daten der Anlage und setzt anschließend das Bit "Daten erfasst" an der Anlage, so dass dort der nächste Bearbeitungszyklus starten kann und z.B. die Messwerte in der Steuerung überschrieben werden können.
Sobald die Middleware die Daten erfolgreich in die DB geschrieben hat, wird wieder auf die Flanke "Zyklus Ende" der Anlage gewartet.
das geht.
 
Auf Datenbankebene könnte man triggern arbeiten. Jedesmal mal wenn du einen Datensatz aktualisiert, wird der definierte trigger ausgelöst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen

ich spiele gerade mit OPC UA und 2x CPU 1512C-1PN rum.
funktioniert soweit auch alles.
was mir noch nicht ganz klar ist, ist der Vorteil einer Methode.
wann macht es Sinn eine Funktion als Methode zu triggern anstatt über normale READ/WRITE -Aufträge und eigens vorgesehene Variablen in der Schnittstelle ?
 
Eine OPC UA Methode vereinfacht die Sicherstellung der Datenkonsistenz. Außerdem hast du eine "automatische" Basis-Dokumentation, da klar ist, welche Eingangswerte und welche Ausgabewerte für die Methode verfügbar und benötigt sind. In einer Nodestruktur ist das nicht zwangsläufig ersichtlich.
 
Zurück
Oben