Engineering Tool

[DerOnkel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich entwickle gerade ein lokales Engineering-Tool für Industrieanlagen (SPS/PLC), das vorhandene Anlagen automatisch analysiert und verständlich dokumentiert.

Das Tool verarbeitet mehrere vorhandene Quellen einer Anlage, z. B.:

• SPS-Programmcode (z. B. CoDeSys / IEC 61131-3)
• HMI/Visualisierung (XML)
• Datenlogger-Historie
• optional R&I-Schema oder Schaltplan

Daraus erstellt die Software automatisch ein Modell der Anlage und erlaubt im Browser:

• Anlagenobjekte (z. B. Ventile, Pumpen, Sensoren) anzuklicken
• alle Abhängigkeiten zu sehen (Code-Logik, Interlocks, Prozessschritte, Hardware-Adresse)
• nachzuvollziehen warum oder warum nicht ein Ausgang angesteuert wird
• Ablaufdiagramme und Prozesslogik automatisch zu visualisieren
• Änderungen zwischen zwei Programmversionen semantisch zu vergleichen
• Inkonsistenzen zwischen Code, HMI, Logger und Dokumentation zu erkennen

Die Anwendung läuft komplett lokal/offline und dient im Grunde als Reverse-Engineering- und Analysewerkzeug für bestehende Anlagen.

Meine Frage wäre:

Kennt jemand Software, die etwas Ähnliches für SPS-Programme und Anlagenanalyse macht?
Vielleicht kann ich mir auch noch Inspiration holen.

 

[Blockmove]

Hört sich sehr ambitioniert an.
Ich kenn sowas eigentlich nur, wenn bestimmte Regeln beim Erstellen des SPS-Programmes eingehalten wurden bzw. ein Framework verwendet wird. Früher gab es bei Siemens eine automatische Diagnose für die WF470 Visualisierungsbaugruppe und aktuell halt ProDiag und PCS7.
Aber eine allgemeine Lösung für einen bestehenden SPS-Code wäre mir neu.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

da ja in der Software und HMI alle möglichen Schweinereien veranstaltet sein können, seh ich das auch sportlich und vor allem, sind die ganzen Programmstände und EPläne überhaupt aktuell

Siemens hat intern diverse Tools für Migrationen für alles mögliche. Aber da kommt man sicherlich schlecht dran.

Irgend nen Student hatte mal nen Tool für Migration Siemens<->Phoenix gebaut. War aber ziemlich rudimentär.

@Jochen Kühner entwickelt doch grad auch sowas...

Am Ende stellt sich die Frage, was ist das Ziel des ganzen und ist die Umsetzung realistisch...

 

[zotos]

Kenne den Ansatz nur umgekehrt Anlagen mit UML Tools zu designen und daraus dann Objekte und Code zu erzeugen.

 

[DerOnkel]

Ok, danke erstmal an euch.
Also ein Klick und alles steht, das wird es nicht. Das Programm wurschtelt sich erst einmal durch alles was es finden kann, stellt daraus Objekte zusammen und geht dann Stück für Stück alles mit dem Benutzer durch. Später kommt die Erweiterung aus den Daten ein neues Programm zu erstellen.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

da ja in der Software und HMI alle möglichen Schweinereien veranstaltet sein können, seh ich das auch sportlich und vor allem, sind die ganzen Programmstände und EPläne überhaupt aktuell

Siemens hat intern diverse Tools für Migrationen für alles mögliche. Aber da kommt man sicherlich schlecht dran.

Irgend nen Student hatte mal nen Tool für Migration Siemens<->Phoenix gebaut. War aber ziemlich rudimentär.

@Jochen Kühner entwickelt doch grad auch sowas...

Am Ende stellt sich die Frage, was ist das Ziel des ganzen und ist die Umsetzung realistisch...

Ich entwickle eigentlich nur eine Bibliothek um TIA Projektfiles in allen Versionen zu lesen. (Und schau was für kleine Tools ich damit bauen kann....)

 

[Blockmove]

Ok, danke erstmal an euch.
Also ein Klick und alles steht, das wird es nicht. Das Programm wurschtelt sich erst einmal durch alles was es finden kann, stellt daraus Objekte zusammen und geht dann Stück für Stück alles mit dem Benutzer durch. Später kommt die Erweiterung aus den Daten ein neues Programm zu erstellen.

So wie ich das nun verstehe, willst du ein Tool für Retrofit / Migration programmieren.
Ich hab da früher immer Tabellen für jede Station mit den zusammengehörigen Sensoren / Aktoren / Bedienelementen / ... erstellt.
Diesen Vorgang willst du teilautomatisieren und später dann daraus neue Bausteine und HMI-Funktionen erstellen lassen.
Also eigentlich getrennte Funktionen. Einmal Analyse und dann Neugenerierung.
Kann viel Zeit sparen.

 

[ducati]

also. das geht schon mit Bezeichnungen/Namen los...

Jedes Feldgerät hat ja mindestens 4 verschiedenen Bezeichnungen (und oft stimmen die halt auch nicht 100%ig zusammen, bei gewachsenen Anlagen):
- BMK aus EPLAN
- Bezeichnung aus R+I
- Kurztext
- Langtext
- Kundenspezifischer Kennzeichnungsschlüssel
- Vorabarbeitsbezeichnungen
- Texte im HMI-Bild
- Texte in HMI-Alarmmeldungen
- symbolische Namen in SPS-Variablen + Kommentare dazu

Wie soll da ein Automatismus erkennen, was da zusammengehört?

Weiter gehts dann mit "virtuellen Bezeichnungen für Variablen/Meldungen die interne Zustände beschreiben und keinem Feldgerät zugeordnet sind (also Teilanlage1 ein/aus Teilanlage2 ein/aus usw..., Signale aus Buskopplungen...)

Dann so Sachen, mal heissts VL-Temp. mal VL-Temperatur mal Temp.-VL, Temperatur-VL ...

Vielleicht einfach alles in eine KI kippen und das Ergebnis besser nicht anschauen

 

[DerOnkel]

Zuviel Werbung?
-> Hier kostenlos registrieren

also. das geht schon mit Bezeichnungen/Namen los...

Jedes Feldgerät hat ja mindestens 4 verschiedenen Bezeichnungen (und oft stimmen die halt auch nicht 100%ig zusammen, bei gewachsenen Anlagen):
- BMK aus EPLAN
- Bezeichnung aus R+I
- Kurztext
- Langtext
- Kundenspezifischer Kennzeichnungsschlüssel
- Vorabarbeitsbezeichnungen
- Texte im HMI-Bild
- Texte in HMI-Alarmmeldungen
- symbolische Namen in SPS-Variablen + Kommentare dazu

Wie soll da ein Automatismus erkennen, was da zusammengehört?

Weiter gehts dann mit "virtuellen Bezeichnungen für Variablen/Meldungen die interne Zustände beschreiben und keinem Feldgerät zugeordnet sind (also Teilanlage1 ein/aus Teilanlage2 ein/aus usw..., Signale aus Buskopplungen...)

Dann so Sachen, mal heissts VL-Temp. mal VL-Temperatur mal Temp.-VL, Temperatur-VL ...

Vielleicht einfach alles in eine KI kippen und das Ergebnis besser nicht anschauen

Erst einmal Stück für Stück. Die Anlage läuft schon lange, das bedeutet das das Programm irgendwas richtig macht. Also nehme ich mir das Programm und die Hardware, die habe ich als XML vorliegen, ich generiere mir für alles eine ID. Jetzt nehme ich mir die Schaltpläne und lasse diese verknüpfen usw… ich lege erst einmal los. Der Knackpunkt bei KI liegt bei den sensible Daten, man will nicht mehr als nötig von Firmengeheimnissen teilen

 

[ducati]

naja, wie gesagt, wenn das alte System gut strukturiert ist und die Texte alle passen, dann kann man das vielleicht auch automatisiert analysieren. Dann gehts aber auch händisch fix
Wenns Kuddelmuddel ist, wirds mit dem Automatismus genauso schwierig wie von Hand...

 

[Blockmove]

Bei modular aufgebauten Maschinen wie Transferstrassen oder Rundtakttischen kann ich mir schon vorstellen, dass eine (Teil)automatische Analyse funktioniert. Erfahrungsgemäß finden sich da schon irgendwelche Muster in den Variablennamen / Symbolen.
Beim Retrofit war die Symbolik für mich auch immer der Ausgangspunkt. Zusammengefasst was zusammengehört. Dann korrigiert und mit den korrigierten Symbolen die alte Software neu übersetzt. Damit bekommt man etwas mehr Struktur ins alte Programm und erkennt dann auch Zusammenhänge.

 

[DerOnkel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei modular aufgebauten Maschinen wie Transferstrassen oder Rundtakttischen kann ich mir schon vorstellen, dass eine (Teil)automatische Analyse funktioniert. Erfahrungsgemäß finden sich da schon irgendwelche Muster in den Variablennamen / Symbolen.
Beim Retrofit war die Symbolik für mich auch immer der Ausgangspunkt. Zusammengefasst was zusammengehört. Dann korrigiert und mit den korrigierten Symbolen die alte Software neu übersetzt. Damit bekommt man etwas mehr Struktur ins alte Programm und erkennt dann auch Zusammenhänge.

Bei uns sind es ausschließlich chemische Anlagen. Ich habe erst einmal den leichten Teil erledigt mit dem Mappen von der Hardware, also OpenPLC XML rein und die variablen und den Aufbau aller IOs und den Stromlaufplan. Wenn dann die HMI dazu kommt, dann hat man eine gute Ausgangsbasis. Ich habe auch ein Datenlogger der alle Aktionen zwischen HMI und SPS aufzeichnet, also nur die Deltas, das sind in 2 Wochen gute 14GB, die wiederum will ich für die Plausibilität nutzen. Das größte Problem wird wohl der AWL Code sein, den muss ich sauber interpretieren. Ich hab auch schon mit einer lokalen KI probiert, das liefert gute Ergebnisse nach dem anlernen, aber soweit bin ich noch nicht.

Am Ende soll es ungefähr so werden, man drückt auf der Visu im Browser ein Ventil an und das Programm antwortet, das es im Programm X verwendet wir im Schritt Y auf der Profilbus Adresse 5 am Modul 2 über die Klemme 3.0 über das Kabel 21A1 auf Klemme X1 Kontakt 15 zum Ventil Y100.5 geht und über den Kontakt 16 zurück auf Masse geht( welches von Netzteil XY über L1 und Sicherung F5 abgesichert ist)

 

[Blockmove]

Sehr ambitioniert.
Ist der ganze Aufwand bei der Hardware notwendig?

• Venti: Zu jedem Autor gibt es eigentlich eine Rückmeldung (z.B. Endlagenschalter). Meist macht man da halt eine Laufzeitüberwachung und Plausibilitätsprüfung in der SPS.
• Schritt: Eigentlich sollte da auch eine Diagnose der notwendigen Freigaben und Überwachungen vorhanden sein. Zusätzlich noch Schritt-Überwachungszeit.
• Profibus: Da sollte es eigentlich eine Baugruppen-Diagnose geben die in der SPS ausgewertet wird.
• Netzteil und Sicherungen: Auch hier sollten eigentlich Störmeldungen in der SPS vorhanden sein.

Ich weiß nicht, ob es in der CodeSys-Welt sowas wie PDIAG bei Siemens gibt. Dort habe ich die Möglichkeit mir betroffene Netzwerke bzw. Schritte im PLC-Code-Viewer bzw im Graph-Viewer anzuschauen.

 

[DerOnkel]

Sehr ambitioniert.
Ist der ganze Aufwand bei der Hardware notwendig?

• Venti: Zu jedem Autor gibt es eigentlich eine Rückmeldung (z.B. Endlagenschalter). Meist macht man da halt eine Laufzeitüberwachung und Plausibilitätsprüfung in der SPS.
• Schritt: Eigentlich sollte da auch eine Diagnose der notwendigen Freigaben und Überwachungen vorhanden sein. Zusätzlich noch Schritt-Überwachungszeit.
• Profibus: Da sollte es eigentlich eine Baugruppen-Diagnose geben die in der SPS ausgewertet wird.
• Netzteil und Sicherungen: Auch hier sollten eigentlich Störmeldungen in der SPS vorhanden sein.

Ich weiß nicht, ob es in der CodeSys-Welt sowas wie PDIAG bei Siemens gibt. Dort habe ich die Möglichkeit mir betroffene Netzwerke bzw. Schritte im PLC-Code-Viewer bzw im Graph-Viewer anzuschauen.

Meine Testanlage hat 27 Profibus Teilnehmer über 16.000 Variablen irgendwas über 250 Seiten PDF als Schalpläne usw… manche teilprogramme haben über 2500 Zeilen in AWL. Und die SPS benutzt noch über UDP 5 andere Steuerungen.
Ich habe schon ein wenig nachgeforscht, aber so richtig etwas gefunden habe ich nicht.
Warum ich eigentlich das Projekt überhaupt gestartet habe ist, auf dem Weg erlangt man Erkenntnisse und wir haben zufälligerweise auch noch ein alten ausrangierten Server mit 268GB RAM und 28 Kerne
Wenn das Projekt von Interesse ist, kann ich auch gerne ein paar Bilder liefern was daraus geworden ist.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fotos wären sicher interessant.
Vor allem auch wie du eine neue Anlage anlegst und aus Hardware, Eplan und SPS-Programm zu deinen Objekten / IDs kommst.
Wieviel manueller Aufwand steckt dahinter?

 

[DerOnkel]

Fotos wären sicher interessant.
Vor allem auch wie du eine neue Anlage anlegst und aus Hardware, Eplan und SPS-Programm zu deinen Objekten / IDs kommst.
Wieviel manueller Aufwand steckt dahinter?

Um das am Ende zu testen nehme ich einfach eine andere Anlage von uns, nicht das ich das Programm nur auf die Anlage hin optimiert habe.
Die Schaltpläne liege als PDF vor, da arbeite ich mit Texterkennung im ersten Schritt. Die Hardware wird per Knopfdruck ausgegeben, mit dem eigentlichen SPS Programm ist es das gleiche und auch die HMI das ist in dem Fall von Copa-Data(sind in dem Fall 730MB XML), jetzt weis ich was an variablen kommt von der SPS und dort steckt eine gewisse Syntax drin, entweder im Variablennamen oder im Kommentar damit kann ich mich wiederum auf die Suche im Schaltplan begeben. Ich versuche es so gut es geht mit festen Regeln zu arbeiten. Wenn nach dieser Automatik(wo noch kein Eingreifen nötig war) noch Punkte offen sind und nicht vernetzt, da soll dann die AI eingreifen, die läuft lokal auf dem Rechner und zeigt dann endlagen gefunden(weil eindeutig) Ansteuerung nicht aber in PDF XY auf Seite 5( mit Vorschau) ist ein Ventil was dazu passen könnte.

Hier endet der „leichte“ Teil.

Ist das alles durch, geht es an den Speck, der alte AWL Code in eine moderne Sprache zu bekommen, damit ich später daraus meine Prozessbeschreibung erstellen kann. Hat mein Programm diese erstellt, dann kommt mein Datenlogger zum Einsatz um die Plausibilität zu prüfen.

 

[DerOnkel]

Ein Teil wäre schon mal geschafft. Läuft alles auf Debian, ein großer Teil ist Python, die Seite lässt sich wie ein Windowsprogramm steuern, habe der Front c# spendiert. Die SPS-Hardware ist nur ein Import dank der Codesys PLCopen XML. Das SPS-Programm, da habe ich einfach mal die alte gewohnte Umgebung von Codesys genutzt, dort ist auch nicht viel zu machen, aber ich habe es einstellbar gehalten, damit der Querverweis auch weis woher die Info kommt, also wenn die Variable von einer anderen SPS/HMI gelesen oder geschrieben wird oder von der Eigenen Hardware. Beim Schaltplan bin ich auch schon gut im rennen. Die HMI werde ich vielleicht noch weiter machen, aber die Infos die ich benötige sind schon alle da. Die lokale AI beantwortet schon dinge, aber ist noch nicht Sinnvoll eingebunden. Es ist nur schwierig Bilder für hier zu machen ohne etwas brauchbares von der Anlage offen zu legen, deshalb die großzügige Schwärzung. Hab schon wieder größere Pläne mit dem Programm, aber erst einmal die aktuellen Probleme lösen. Schönes Wochende

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sieht interessant aus und jetzt wird mir auch der Sinn mehr verständlich.
Durch das Mapping HMI <-> PLC-Programm <-> IO-Mapping <-> EPlan besteht z.B. die Fehlersuche zu einem Großteil aus Zusammensuchen. Dein Tool bringt das unter einen Hut.

 

[DerOnkel]

Sieht interessant aus und jetzt wird mir auch der Sinn mehr verständlich.
Durch das Mapping HMI <-> PLC-Programm <-> IO-Mapping <-> EPlan besteht z.B. die Fehlersuche zu einem Großteil aus Zusammensuchen. Dein Tool bringt das unter einen Hut.

Ja, so der Plan. Damit sehe ich den kompletten Prozessablauf vom Programm und wenn ich auf ein Ventil klicke, dann soll das Programm mir sagen das zuvor Prozess X gestartet werden muss und dann wir der Ausgang Y geschalten, das geht über diese Sicherung und Klemme und Kabel, bis zur Einspeisung zurück, ein kompletter Trace. Nach der ganze Arbeit und Visualisierung sollte es relativ leicht sein das Programm zu Portieren auf V3.5 . Soweit der Plan… Ich versuche das System so offen wie möglich zu halten, damit es vielleicht ein Open Source werden kann und andere Steuerungen unterstützt oder HMI, Schaltplan technisch könnte man auch eingescannte PDFs benutzen.

 

[sps_klassik]

Wie kann man AWL konvertieren in eine moderne Sprache?