[Konzept-Frage]Datenstrom verarbeiten und in DB schreiben

[Dennis89]

Hallo zusammen,

ich habe eine neue Aufgabe und bitte um eure Ratschläge.
Es gibt eine Maschine, an der werden zwei Mikrokontroller Stellmotoren steuern, die Einfluss auf das Maschinenverhalten haben. Ich habe einen Linux-Server, auf diesem läuft InfluxDB, Grafana und ein weiteres webbasiertes Programm, dass aber unabhängig von diesen Daten hier ist. Stand jetzt lade ich die Maschinendaten manuell auf den Server, die werden verarbeitet, in die DB geschrieben und mit Grafana dargestellt.

In Zukunft bekomme ich einen Datenstrom via OPC UA an den Server. Jede Sekunde kommen von unterschiedlichen Sensoren Werte an. Anhand einiger Werte will ich, je nach dem, wie die zueinander stehen, den Mikrokontroller via HTTP Befehle senden. Weiters sollen alle Werte in die DB geschrieben werden.

Ich stelle mir jetzt die Frage, was ist sinnvoller. Die Daten in die DB zu schreiben und separat eine DB-Abfrage des letzten Eintrags zu machen und dann die Stellmotoren zu steuern. Erst steuern und dann in die DB? Da die Werte eh nur jede Sekunde kommen und das System träge ist, muss ich nicht innerhalb einer 1/10 Sekunde reagieren.

Mir geht es auch darum, schreibe ich ein Programm und arbeite mit '`threading` und/oder `async` oder schreibe ich zwei separate Programme? Wie geht man da vor?
Kann ich irgendwie im Vorfeld herausfinden, ob mein Server das alles verarbeiten kann, von der Leistung? Gibt es mit zu vielen Lesezugriff auf die DB Probleme? (Ich glaube in diesem Bereich, ist meist viel mehr möglich, als ich immer denke. Mir fehlt da allerdings die Erfahrung und das soll stabil laufen)

Wenn es ganz andere Ansätze gibt, bin ich offen für alles. Letztendlich müssen meine zwei Stellmotoren geregelt werden, die Daten sollen in die Datenbank und ein Live-Dashboard mit Grafana wäre super.

Vielen Dank schon mal!

Grüße
Dennis

[grubenfox]

Ich stelle mir jetzt die Frage, was ist sinnvoller. Die Daten in die DB zu schreiben und separat eine DB-Abfrage des letzten Eintrags zu machen und dann die Stellmotoren zu steuern. Erst steuern und dann in die DB? Da die Werte eh nur jede Sekunde kommen und das System träge ist, muss ich nicht innerhalb einer 1/10 Sekunde reagieren.

Also das "separat eine DB-Abfrage des letzten Eintrags zu machen" erscheint mir jedenfalls sehr sinnlos zu sein. Die Daten gehen ja weder beim schreiben in die DB, noch beim ansteuern der Motoren irgendwie verloren.
Für alles weitere fehlt mir nun auch die Erfahrung. Wenn es nur eine Handvoll Daten sind, die da sekündlich kommen und verarbeitet werden müssen, dann würde ich denken "das passt schon irgendwie".

Auch wenn ich hier bei manchen Servern so 2-3mal pro Minute Daten abhole bzw. versende, dann sind auf der anderen Seite nur Menschen dran die mit den Daten arbeiten und keine Stellmotoren. Da ist eine Minute mehr oder weniger nicht systemkritisch.

[Dennis89]

Danke für deine Antwort.
Ich verstehe nicht, wieso das aus deiner Sicht sinnlos ist? Also ja, wenn alles ein Programm macht, dann ist es sinnlos, weil die Daten schon da sind. Wenn ich aber, so war es gemeint, ein separates Programm ausführe, dass die Motoren steuert, dann bekommt das die Werte über die DB-Abfrage. Der Teil greift schon etwas auf den nächsten Absatz vor. War eventuell nicht ganz ordentlich formuliert.

Grüße
Dennis

[grubenfox]

Ah, ja... ich war komplett bei "alles ein Programm". Wenn es das nicht ist bzw. wird, dann war meine Antwort hier der sinnlose Teil.

[sparrow]

@Dennis89: Ich mag es, Probleme immer aus der realen Welt heraus zu betrachten. Meistens ergibt sich dann schon eine Lösung und die Prioritäten fallen in eine "natürliche" Reihenfolge.

Wie kritisch ist der Prozess? Und wie kritisch sind die einzelnen Teile davon?
Ist es ok, dass nichts mehr gesteuert wird, wenn die Datenbank ausfällt?
Ist es wichtig, dass auf keinen Fall gesteuert wird, wenn es nicht auch in der Datenbank gelogt wird?

Den Weg über die Datenbank in die Steuerung würde ich vermeiden. Wenn du die Daten eingehend schon in der Verarbeitung hast, solltest du die auch gleich verteilen und nicht die Datenbank pollen. Auch wenn ich nicht weiß, ob InfluxDB da auch Trigger aussenden kann.

[noisefloor]

Hallo,

ich denke auch, dass der Ansatz bzw. die Fragen von @sparrow relevant für das Vorgehen sind: wer soll von wem abhängen bzw. gibt es überhaupt Abhängigkeiten? Wenn es keine gibt, kann man das ganze parallel machen, also man empfängt die Daten und schiebt diese in zwei Queues, aus der sich DB und Steuerung bedienen.

Gruß, noisefloor

[Dennis89]

Danke für die Antworten.

Der Ausfall der Datenbank sollte die Steuerung nicht beeinflußen. Okay damit hat sich das schon erledigt. Ich empfange die Daten und arbeite mit Qeues.
Es wäre natürlich schön, dass die Steuerung mit den Daten der Datenbank nachvollziehbar ist. Allerdings die Steuerung auszuschalten, weil die Datenbank nicht funktioniert, würde zur Folge haben, dass im besten Fall ein Mechaniker von Hand steuert und im schlechtesten Fall läuft sie in eine Störung und fährt herunter. Das ist nicht schön und kostet Geld (und Nerven).

Dann arbeite ich mit `threading`, es sei denn es gibt einen Grund, warum ich `async` oder `processing` verwenden sollte. Da müsste ich mich erst einarbeiten, daher bevorzuge ich das, was ich schon mal gemacht habe.


Danke und Grüße
Dennis

[imonbln]

Wenn es ganz andere Ansätze gibt, bin ich offen für alles. Letztendlich müssen meine zwei Stellmotoren geregelt werden, die Daten sollen in die Datenbank und ein Live-Dashboard mit Grafana wäre super.

Ich würde die Daten in einem Programm empfangen und dort ein Observer-Pattern (auch bekannt als Publisher/Subscriber) implementieren.
Die Subscriber könnten anschließend in einzelnen Workern laufen, wodurch du direkt ein Design erhältst, das offen für Erweiterungen ist.

[noisefloor]

Hallo,

...es sei denn es gibt einen Grund, warum ich `async` ...

`async` würde ja nur gehen, wenn die HTTP-Request und Datenbankanbindung async... await untersützen würden. Bei Request kein Problem, bei der Datenbank müsstest du mal in der Doku des Datenbankmoduls deiner Wahl nachschauen. Wobei ich hier auch nicht so wirklich einen Grund sehe, warum man `async` nehmen sollte.

Gruß, noisefloor

[Dennis89]

Dankeschön!

Die Beschreibung von @imonbln hört sich gut an. Ich werde mal schauen was ich zu den Schlagwörtern im Netz finde.

@noisefloor Ich bin froh, dass du keinen wirklichen Grund siehst. Wenn das mit den einzelnen `Worker` klappt, dann hat sich die Frage geklärt.


Grüße
Dennis

[noisefloor]

Hallo,

Es wäre natürlich schön, dass die Steuerung mit den Daten der Datenbank nachvollziehbar ist

Du könntest bei Bedarf ja schon auch in der Datenbank loggen, wenn welche Daten per HTTP Request an die Steuerung gesendet worden sind. Wobei du dann halt auch "nur" siehst, wann die ein 200 OK Response (oder sonst einen Response) bekommen hast und nicht, wann die Steuerung die Daten wirklich verarbeitet hat.+

Gruß, noisefloor

[Dennis89]

Danke, das wäre schon mal nicht schlecht. Es ist so, dass im besten Fall die Steuerung nicht eingreifen muss. Wenn sie eingreift, dann verändern sich ein paar Sensorwerte. Bei der Auswertung dieser Werte ist es von großem Vorteil zu wissen, ob sich die Werte „von alleine“ oder durch einen Eingriff von außerhalb verändert haben. Da das System recht träge ist, würde mir der Zeitpunkt des Response reichen.

Grüße
Dennis

[DeaD_EyE]

Aus der Sicht eines Automatisierers:
- SPS steuert die Anlage (besser keine Mikrocontroller, da empfindlich)
- Sensor-Werte kommen über Analog-Eingänge (0-10V, 0/4-20mA), Bussysteme wie z.B. Profinet oder über PTP-Verbindungen z.B. IO-Link.
- SPS stellt OPCUA-Server bereit (alle modernen Steuerungen können das)

InfluxDB kann Werte von dem OPCUA-Server abholen.
Die typischen Siemens-Steuerungen (S7-1500) haben 100ms Update-Intervall für OPCUA.
Steuerungen von anderen Herstellern sind ähnlich.

Dann natürlich so gestalten, dass die komplette Anlage ohne Linux-Server funktioniert.
D.h. die Logik der Anlage darf nicht von dem Linux-Server/InfluxDB abhängig sein.



PS: OPCUA ist anstrengend, wenn man selbst entwickeln will.

[Dennis89]

Danke für die Antwort.

Die Anlage wird grundsätzlich von der SPS gesteuert. Wenn die Mikrokontroller ausfallen oder der Linux-Server, dann läuft die Anlage weiter und wird im dümmsten Fall kontrolliert abgestellt, weil in der Nach niemand manuell eingreifen kann/will. Der OPC UA Server wird auch von der S7 bereitgestellt.

Durch unterschiedliche interne Probleme, ist es uns Zurzeit nicht möglich die Servomotoren in die SPS einzubinden. Zumindest nicht in dem gewünschten Zeitraum. Ich habe mir mal etwas mit TIA beschäftigt, finde mich da aber noch nicht so zurecht um das strukturiert zu implementieren. KOP und FUP ist für meinen Geschmack unübersichtlich (kann natürlich an fehlendem Wissen/Erfahrung liegen) und rein mit SCL wird das vermutlich auch nicht gehen. Ich hatte die Idee auch schon, fühle mich aber nicht in der Lage das ordentlich umzusetzen.

In wie fern findest du Mikrocontroller in diesem Zusammenhang empfindlich? Und wieso ist OPC UA anstrengend? Bis jetzt habe ich nur mal ein paar Sensorwerte abgefragt, mehr noch nicht.

Danke und Grüße
Dennis

[DeaD_EyE]

Durch unterschiedliche interne Probleme, ist es uns Zurzeit nicht möglich die Servomotoren in die SPS einzubinden.

SMC JXCP1 ist ganz gut. Ich kann man nachschauen, welche Controller/Achsen wir eingesetzt haben.

KOP und FUP ist für meinen Geschmack unübersichtlich (kann natürlich an fehlendem Wissen/Erfahrung liegen) und rein mit SCL wird das vermutlich auch nicht gehen.

KOP - Elektriker
FUP - Programmierer
SCL - Programmierer

Du kannst alles mit SCL machen. Rein theoretisch auch den OB1, macht aber niemand. Früher hat man AWL verwendet, aber das ist seit Einführung der S7-1200/S7-1500 obsolete und sogar langsamer, als SCL in der Ausführung. Der Unterschied ist, dass SCL, FUP, KOP in einen Zwischencode übersetzt werden, der dann auf der CPU der Steuerung ausgeführt wird. Der Code wird durch den Compiler optimiert und Datenstrukturen werden gepackt. Das ist z.B. auch der Grund, weswegen der Zugriff mit snap7 auf optimierte Datenstrukturen nicht möglich ist. AWL kann nicht optimiert werden. Bei Codesys ist das ähnlich. Da hat man dann die Codesys-Runtime auf dem Gerät.

In manchen Situationen ist FUP/KOP übersichtlicher. Es gibt aber viele Automatisierer, die ausschließlich SCL verwenden. Es hängt auch davon ab, ob Kunden einen Standard vorgeben.
Ich verwende z.B. mehr SCL als alles andere. Wenn ich Schrittketten für eine S7-1200 programmieren muss, verwende ich SCL, da Graph7 (Darstellung für Schrittketten) für die S7-1200 nicht verfügbar ist.
Bei großen Anlagen mit Hochregallager verwende ich für den Ablauf dann aber Graph7, weil es übersichtlicher ist und die S7-1500 verwendet wird.

In wie fern findest du Mikrocontroller in diesem Zusammenhang empfindlich?

Nur bezogen auf DevBoards und eigenem PCB-Design:

• die GPIOs sind empfindlich, sofern man diese nutzt. Um die GPIOs als Eingänge zu nutzen, kann man Spannungsteiler (24V > 3.3V) verwenden und vor Spannungsspitzen mit Zenerdioden schützen. Bein ESP32 ist das Limit 3.6 V soweit ich weiß. Alternativ Pegelwandler oder Optokoppler verwenden.
• wenn man digitale Eingänge der SPS nutzen will, müssen die 3.3V auf 24V gewandelt werden.
• EMV, wenn man DevBoards verwendet oder selbst PCB designt. Je nach Umgebung kann es z.B. passieren, dass der Mikrocontroller gestört wird. Dass ein Mikrocontroller die Anlage stört, ist eher unwahrscheinlich, da die Industriekomponenten störungssicher sind.

Im Endeffekt werden in der Industrie tonnenweise Mikrocontroller verwendet. Aber die sind dann in der SPS, in Technologie-Modulen, Controller für Servos/Schrittmotoren usw. Sind natürlich alle teurer, als das, was man aus dem Hobbybereich kennt. Die sind getestet worden, störungssicher und haben Zertifizierungen. Die Zertifikate und die Störungssicherheit erhöhen den Preis signifikant.

Und wieso ist OPC UA anstrengend?

Es ist unnötig komplex.

Die Art und Weise wie Nodes der Hierarchie adressiert werden ist umständlich und nicht für Menschen geeignet.
Das ist alles super, wenn man proprietäre Tools verwendet, um z.B. ein Modell zu erstellen.

Sobald man z.B. mittels Python über eine Datenstruktur via OPCUA iterieren will, wird es nervig.

Ein ganz anderes Problem ist bei den Steuerungen selbst aufgefallen. Es ist festgestellt worden, dass das Erstellen einer neuen OPCUA-Session viel Rechenzeit benötigt und bei älteren Firmwares hat das dazu geführt, dass die Verbindung verloren gegangen ist. Die Session wird in einem bestimmten Intervall automatisch erneuert.

Bis jetzt habe ich nur mal ein paar Sensorwerte abgefragt, mehr noch nicht.

Ja, das ist noch einfach. UaExplorer öffnen, node-id kopieren und dann die entsprechenden Methoden verwenden. Oder halt via InfluxDB abholen lassen.

[Dennis89]

Danke für deine Ausführungen.

Die Wahl der Programmier-Art/Sprache, ist in meinem Fall "egal", da ich glücklicherweise so gar nichts mit Standard/Kunden zu tun habe. (grob gesagt) Ich muss die Maschine erfolgreich betreiben/weiter entwickeln und dann kommt jemand und darf ein Standard daraus machen. Letztlich ist gerade die Kapazität von Mitarbeiter, die die SPS programmieren können, extrem begrenzt. Da muss ich hinten anstehen und daher meine Lösung mit den Mikrokontroller, weil ich mir da die Steuerung zu programmieren zutraue, ich den Code verstehe und so etwas ähnliches schon mal gemacht habe.
Btw. da hatte ich auch mit 24V und 3,3V zu tun und hatte die Steuersignale, wie du beschrieben hast, auch über Spannungsteiler und Dioden heruntergesetzt und abgesichert. Das wir dann unabhängig von der SPS und daher will ich dort auch keine Eingänge nutzen.

Mal schauen, eventuell schaue ich mir TIA die Tage noch einmal an und denke darüber nach, die Mikrokontroller weg zu lassen. Bzw. dann habe ich zwei Lösungswege und je nach zur Verfügung stehender Zeit, kann ich mich dann entscheiden. Weil ich muss schon zugeben, eine Steuereinheit ist schon angenehmer, als zwei.

Ich halte euch auf dem Laufenden. Spätestens wenn es Code zu beurteilen gibt, hört ihr auf jeden Fall wieder von mir

Grüße
Dennis