Sonstiges IoT - Stördatenanalyse / Auswertung von Daten / Datenerfassung ,...

Al.D

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

Ich hoffe mir kann hier jemand weiterhelfen.

In Zeiten der "Digitalisierung" werden die Anforderungen an die Anlagen immer größer.
Einer dieser Punkte ist eine automatische Stördatenanalyse.

Seit kurzem Versuche ich mit Hilfe der IoT von Siemens "Daten aus der Anlage zu ziehen". Meist haben wir hier eine S7 300 verwendet.
Ziel im ersten Step wäre alle Stör und Betriebsmeldungen die am Panel angezeigt werden mitzutriggern. Am besten natürlich mit sehr geringen Aufwand und im Idealfall sollte dies eine Plug & Play Lösung sein.

Ich glaube dieses Thema steckt noch ziemlich in den Kinderschuhen oder habt ihr hier schon Erfahrungen gemacht oder Tipps? Vielleicht ist ja der Weg über die IoT auch völlig falsch?!

Ich freu mich auf eure Antworten
 
Ich kann in deiner Auflistung jetzt keine konkrete Aufgabenstellung erkennen.
Daten aus der Anlage ziehen
Machen wir schon seit >20 Jahren, auch mit S5 ( hier gab es auch schon alle möglichen Sonderlösungen wie z.B. INAT CP usw... )
Hat also erst mal nichts mit I4.0 oder IOT zu tun

Ziel im ersten Step wäre alle Stör und Betriebsmeldungen die am Panel angezeigt werden mitzutriggern.
Auch dies ist ja nichts neues.


Vielleicht schreibst du einmal etwas konkreter, was gesammelt, ausgewertet und dargestellt werden soll. Und wo dies
überall präsentiert werden soll ( lokal, weltweit..... )
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

was meinst du genau mit Daten aus der Anlage ziehen? Sind die Daten in der S7 vorhanden (in einem DB?)? In welchem Format sollen sie hinterher angezeigt werden? Wo sollen die Daten gespeichert werden? Lokal in einer Datenbank? Cloud? Wie soll man hinterher auf die Daten zugreifen können?

Eine Möglichkeit wäre - anhand der bisher gegebenen Informationen - unsere icom Data Suite, welche auf unseren Gateways läuft. Hier könntest du z. B. sämtliche Daten aus der S7 anhand von Kriterien (event- oder zeitgetriggert) überwachen, verarbeiten und anschließend per MQTT oder HTTPS weitersenden. Ein Dashboard zur Visualisierung ist ebenfalls vorhanden. Durch die Routingfunktionalität in unseren Gateways hast du von überall zu jederzeit Zugriff auf diese Daten.

Bei Fragen oder wenn wir uns einmal telefonisch austauschen möchtest kannst du mir auch gerne eine PN schicken.
 
War wohl doch etwas ungenau.:oops:
(Ich bin leider noch nicht so sehr tief in der S7 oder anderen Programmiersprachen drin. Bin noch am lernen )
Das es schon diverse Lösungen gibt ist mir bekannt, die erscheinen mir allerdings teilweise sehr unpraktikabel.

Wir nutzen den DB10, in diesen sind ~4000 mögliche Bits frei in dem Stör und Betriebsmeldungen "abgelegt" werden können.
In unseren Panels werden dann zu den einzelnen Bits entsprechende Fehlermeldungen generiert.(das System ADAM von WINCC kenn ich auch bereits)


Mein Ist Stand ist folgender:
1.Ich Frage diese 4000Bits bereits auf Änderung ab und schreibe diese mit. (Anzahl + Dauer wie lange dieses Bit Ansteht)
2.Daraufhin leite ich die Stör und Betriebsmeldungen aus dem Panel aus ( Bit + Text)
3. Dann findet über einen Vergleich die Zuweisung zu den im Punkt 1. aufgeführten Meldungen statt

Vorerst genügt mir das lokale Speichern.
Angezeigt soll das ganze früher oder später mind. 1x täglich über einen Bildschirm angezeigt werden. Vielleicht sogar die Top10 Störmeldungen irgendwann in der Mindsphere.

@Sven Rothenspieler: Ich schau mir Ihr system einmal an und melde mich ggf. bei Ihnen.

Ich hoffe ihr Könnt mit den Daten was anfangen.
 
Nimms mir jetzt nicht böse. Aber dann lies doch bitte oben nochmal.
Da habe ich ja auch geschrieben, dass es vielleicht der falsche Weg ist und es bei weitem einfacher geht?!

Ich hab damit nun einfach mal noch keine bzw zu wenig Erfahrung.
Dafür ist ja so ein Forum da, dass einen weiter geholfen wird und man nicht dauernd belehrt wird!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dafür ist ja so ein Forum da, dass einen weiter geholfen wird und man nicht dauernd belehrt wird!
Das ist nicht belehren sondern Fragen. Ich kenne deine Anwendung nicht und versuche mich halt reinzudenken.
Und dafür sind halt auch mal Fragen notwendig. Falls sie dir zu kritikreich waren, bitte ich dies zu entschuldigen.
 
Dann habe ich das vielleicht einfach falsch aufgefasst.

Aber um wieder zum Thema zurückzukommen.

Wie würden Sie dass denn realisieren? Wie schon gesagt, dass Ziel sollte eine möglichst eine Vervielfältigung sein(wenig Programmieraufwand, ggf. nur Variablen anpassen)
 
Also wir hatten einmal Anlagen so ausgerüstet, dass sie die TOP Fehler sortiert hatten. Hierfür hatten wir einen SCL Baustein geschrieben,
jede Fehlermeldung wird indexiert als Bool + DINT als Fehlerzähler. Mit jeder Flanke einer FM wurde dann der entsprechende Fehler +1 hochgezählt.

Danach gab es eine Filterroutine, welche die DINT mit dem größten Zählerstand abwärts sortiert hat.

Dann kam z.B. raus:

1: FM[7]
2: FM[317]
usw.
Aus dem Display haben wir dann den Zähler mit dargestellt sowie den Fehlertext ( beides über den Index [7] )

Aber es gibt sicherlich mittlerweile elegantere Lösungen.
 
Hallo Al.D

Habe diese Woche spaßeshalber auch mal so was ähnliches umgesetzt:

Die Meldungen oder Werte werden via MQTT Protokoll an einen MQTT Broker gesendet. Dieser bereitet die Daten auf und visualisiert sie auf einem Dashboard, welches im Webbrowser abrufbar ist.

MQTT Publisher für die SIMATIC- CPU findest du hier:
https://support.industry.siemens.co...-publisher-für-die-simatic-cpu?dti=0&lc=de-WW

Als Server und gleichzeitig Dashboard setze ich die folgende Opensource-Software ein:
https://thingsboard.io

Alternativ kann auch der Mosquitto-Broker als MQTT Server eingesetzt werden und die Daten könnten dann mit Node-Red visualisiert werden. Alles opensource Software und noch flexibler als meine Lösung.

MfG Marco
 
Danke für die ganzen Antwort.
ich glaube da hab ich noch einiges vor um mich in einige Themen einzuarbeiten.:rolleyes:


Und mit Node Red sind wir eben gerade dabei dies zu versuchen.
Die IoT von Siemens basiert ja unter anderem auf der "Programmiersprache" Node Red
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die ganzen Antwort.
ich glaube da hab ich noch einiges vor um mich in einige Themen einzuarbeiten.:rolleyes:


Und mit Node Red sind wir eben gerade dabei dies zu versuchen.
Die IoT von Siemens basiert ja unter anderem auf der "Programmiersprache" Node Red

Also Node-Red ist schon mal eine gute Möglichkeit.
Dann packst du noch Influx-DB und Grafana dazu und du hast eine flexible und kostengünstige Lösung
 
Habe diese Woche spaßeshalber auch mal so was ähnliches umgesetzt:

@Marco: Hab mir das nur einmal kurz angesehen und mir gleich eine Frage gestellt, die du mir sicherlich leicht beantworten kannst ;)

Wenn ich die MQTT-Publisher in eine S7 stopfe, muss ich diese dann für jeden Wert neu aufrufen? (1 Wert = 1 Topic)
Und im Zusammenhang dazu, hast du dir einmal die Performance auf der CPU dazu angesehen?

Denn wenn ich jetzt überlege das ein "Testsystem" bei uns aktuell gut 80 REALs aus 2 DBs pro Sekunde ausliest und (leider :( ) direkt in eine SQL-DB stopft, wäre für mich die Variante mit MQTT allerdings wünschenswerter. Bringt nur nix, wenn ich im Vollausbau mit >200 Variablen eine 414 gleich gegen eine 417 tauschen müsste :D

MfG Fabsi
 
@Marco: Hab mir das nur einmal kurz angesehen und mir gleich eine Frage gestellt, die du mir sicherlich leicht beantworten kannst ;)

Wenn ich die MQTT-Publisher in eine S7 stopfe, muss ich diese dann für jeden Wert neu aufrufen? (1 Wert = 1 Topic)
Und im Zusammenhang dazu, hast du dir einmal die Performance auf der CPU dazu angesehen?

Denn wenn ich jetzt überlege das ein "Testsystem" bei uns aktuell gut 80 REALs aus 2 DBs pro Sekunde ausliest und (leider :( ) direkt in eine SQL-DB stopft, wäre für mich die Variante mit MQTT allerdings wünschenswerter. Bringt nur nix, wenn ich im Vollausbau mit >200 Variablen eine 414 gleich gegen eine 417 tauschen müsste :D

MfG Fabsi

So wie ich gesehen habe, ist die Message (Nachrichteninhalt) einfach als String definiert.
Du musst sie dir also selber zusammenbauen.
Aufbau und Struktur der Nutzdaten muß bei MQTT sowieso mit der anderen Seite abgestimmt werden.
Da ist MQTT für uns SPSler kein Fortschritt.
Egal wie nun die Schnittstelle aussieht (simple Digital-IO oder JSON, MQTT, OPC-UA) es bleibt das alte Dilemma ... Man muß miteinander reden :p

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dann habe ich das vielleicht einfach falsch aufgefasst.

Aber um wieder zum Thema zurückzukommen.

Wie würden Sie dass denn realisieren? Wie schon gesagt, dass Ziel sollte eine möglichst eine Vervielfältigung sein(wenig Programmieraufwand, ggf. nur Variablen anpassen)

Das lässt sich auch mit einem ganz "normalen" WinCC realisieren. Wenn die 4000 Bits schön hintereinander abgelegt wurden, dann reicht dir auch eine 128 Tag Lizenz.

Genau so siehts aus!

Du nimmst ein WinCC V7 als "Leiitsystem", da kannnst Du relativ einfach alle Deine 300er Steuerungen aufschalten.

Im WinCC nutzt Du das Alarmlogging und Alarmarchiv.

Im Alarmcontrol kannst Du die aufgelaufenen Alarme statistisch auswerten, nach Häufigkeit oder sonstwas...

Wenn Du andere Auswertungen brauchst geht das mit Scripten, diversen Tools, oder auch Zugriff auf die Daten im SQL-Server vom WinCC.


Ich denke, Du unterschätzt ziemlich die Aufgabe, welche Du lösen sollst. Je nach Umfang un Menge der Daten krigst Du ganz schnell ein Problem mit einer selbstgebastelten Lösung. Da bist schnell beim Datenbankthema...

Falls Die Statistikauswertung relativ simpel sein sollte, könnte man sicherlich wie oben angesprochen, da auch dirket in der SPS was "zählen". Aber oft kommt der Appetit beim Essen und der Kunde will ganz schnell immer mehr ;)

Gruß.
 
@ducati: Acht ja, SCADA hátte ich bei uns schon gerne. Bezahlt aber keiner und Zeit dafür hat man auch nicht.
Das "Testsystem" hat eine "to*con*-in*sult*ing" Schmiede gefriemelt für den Konzern. Das Tool wächst immer mehr mit Funktionen, wird jetzt klein gehackt weil"s so wie von mir vorhergesagt absolut unsinnig im Aufbau war, läuft mehr oder weniger stabil und die super Anzeige/Auswertung anstatt Grafana zu nehmen und um Funktionen die es vielleicht noch nicht gibt für die Community zu erweitern, haben die einfach das ganze Teil auch selbst geschrieben. Sieht auf den ersten Blick toll aus, umständlich zu bedienen, es fehlen Funktionen und es tut sich nix...

Den Mosquitto und Grafana Server hab ich letzte Woche runter gefahren, weil das Templogging an der Stelle ich es verbaut hatte, nicht mehr benötigt wird.
Es wäre also alles da, was ich zu meinem Glück brauchen würde :D

Wenn ich mir jetzt aber auf rund 30 Maschinen (CPUs) insgesamt rund 7500 Strings zusammen basteln muss und die Werte dazu kopieren, gehen sicherlich davon ein paar in die Knie. Und dann zu erklären das wir aus heiterem Himmel für einige 10k€ neue CPUs brauchen, zahlt wieder keiner ;)

Insofern finde ich die Idee von Siemens das gleich zu implementieren ja schon gut. Jedoch fehlen da noch ein paar Sachen...
Beispielsweise ein "Topic/Value-DB" in dem man ein Haupttopic angeben kann, welches vor jeden anderen gesetzt wird.
(das ist ja bei MQTT eigentlich Standard, das Gerät x immer seine Topics startet mit /deutschland/werk1/maschine2/... )
Dann ein "untertopic" eingeben kann und vielleicht sogar die Speicherstelle des Wertes den man senden möchte.

Aber ich schweife ab, das ist nicht die Aufgabe eine SPS. Und wenn macht so etwas nur Sinn bsp. in einer ODK-CPU bei der man den Teil in den C-Code "auslagern" kann...

MfG Fabsi
 
@Fabsi
Ich bin absolut kein Freund von MQTT in der SPS-Welt.
Für die aktuellen Wago-SPSen ist es schon länger verfügbar und ich hab da schon meine Erfahrungen gesammelt.
Solange die andere Seite flexibel ist und die "Standard"-Payload versteht ist alles ok.
Musst du aber deine Nutzdaten in einem bestimmten Format abliefern, dann ist es eine ekelhafte Stringbastelei.
Wenn du variable Daten per MQTT bekommst, dann ist die Situation noch schlimmer.

OPC-UA ist für die Kommunikation mit Steuerungen das deutlich bessere Protokoll.
Wenn bei uns die Forderung nach MQTT kommt, dann wird das mittlerweile mit Node-Red erledigt.

Gruß
Blockmove
 
Zurück
Oben