OOP - Debugging- / Inbetriebnahmestrategie

[Biiebs]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Community,

ich bin schon relativ lange passiver Mitleser im Forum und ich weiß, dass ich mit dem Thema OOP wieder eine sehr große Diskussion auslösen werde, aber wir schauen mal wo die Reise hinläuft.
Vllt. wird sich die Thematik auch minimal mit meinem Vorgänger Post ("Inbetriebnahme Zeiten verkürzen") überschneiden, aber ich bezieh mich wahrscheinlich auf einen anderen Thematikschwerpunkt, andernfalls pass ich mich natürlich an.

Zu meinem ursprünglichen Problem:

Wir haben endlich die Möglichkeit bekommen eine Neuentwicklung einer Anlage mit einem OOP Ansatz zu programmieren. (Kleine Randnotiz: Die Prinzipien sind uns bekannt, an den Strategien und Architektur sind wir jedoch noch ein bisschen am Lernen)
Nun haben wir den ersten Anlagentyp ausgeliefert und die IBN gestartet. OOP im Softwareentwicklungsprozess ist kein Problem, OOP bei der IBN der Anlage wurde bei uns zu einem großen Problem. Das Problem dabei ist einfach, dass die für den SPSler üblichen Beobachtungswerte in den einzelnen Methoden etc. zur Nachverfolgung fehlten und wir das Programm leider nicht mit Breakpoints zukleistern konnten...

Im Großen und Ganzen reden wir hier von CODESYS bzw. von TwinCAT 3, jedoch sind die prinzipiellen Strategien wohl auch auf andere Hersteller portierbar.
Ich weißt, dass folgende Möglichkeiten bei CODESYS, TwinCAT 3 vorhanden sind:

• Eigenschaften (Properties): Attribut {attribute 'monitoring' := call}
• Methoden: Debugging Möglichkeit mit "Flow Control" --> Nachteil: Laufzeitvergrößerung ?
• Interfaces: ??? (Hier ist mir nichts bekannt)

Wie macht Ihr das bei euch mit einem OOP Ansatz wenn es in Richtung Debugging Prozess geht vor allem mit Interfaces, Methoden und Eigenschaften und ohne Beobachtungswerte ist es doch eher unmöglich eine Anlage in Betrieb zu nehmen oder?

Vielen Dank im Voraus.

Gruß,

Biiebs

 

[Blockmove]

Interessantes Thema
Ich hab mir OOP mal mit eCockpit auf Wago angeschaut und fand das Thema Debugging auch nicht gerade gut gelöst.
Bin auch auf Meinungen, Tipps und Tricks gespannt.

 

[ioStart]

Zuviel Werbung?
-> Hier kostenlos registrieren

OOP ist eine tolle Sache.
Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv). Daher versuche ich immer im Vorfeld möglichst viel abzufangen und durch Tests zu bestätigen. Das verschafft dann den Vorteil, dass man die Architektur mit größerer Sicherheit definieren kann und das Debuggen idealer-weiße ganz entfällt.

 

[Ralle]

Ich denke, man kann mit OOP genz schöne Programme schreiben, die dann allerdings, wie vom TE beschrieben, schlecht in Betrieb zu nehmen und noch viel schlechter zu warten sind. Da muß man sich genau fragen, welche Vorteile der OOP-Ansatz gegenüber einem "herkömmlichen Programm" mit Struktur durch FB ubd FC, eigene Standard-FB und mit vernünftigen definierten Schnittstellen (IN/OUT/INOUT) hat. Ich persönlich kann das nicht sehen, vielleicht liefert jemand ein paar Argumente?

 

[Biiebs]

@ioStart
Könntest du deinen Ansatz etwas genauer beschreiben?

Klar, je nach Kapselung und Architektur des OOP-Projekts lassen sich die einzelnen Methoden und Klassen über Unit-Testframeworks (z.B. TcUnits (Twincat) / cfunit (CODESYS)) wunderbar testen, aber wir reden hier von den kleinsten zu prüfenden Programmteilen auf unterster Ebene. Erst im weiteren Prozess werden diese modular zusammengefügt. Dann ist das Testen mit Unit-Testframeworks zu aufwendig, da wir hier schon von Integrations- oder Systemtests sprechen, die in der SPS Welt leider nur durch aufwändige Emulationen oder Simulationen geprüft werden können. In anderen Hochsprachen sieht dieser (fast automatisierte) Prozess jedoch wiederum komplett anders aus.

Und genau hier liegt der Unterschied zwischen SPS und Hochsprachenentwicklung. In der SPS-Welt muss leider über einen steinigen langen Weg gegangen werden bis der Entwickler sich erstmal alles "von Hand" zusammenprogrammiert hat. In der Hochsprachenentwicklung gibt es unzählige Frameworks dafür.

Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv)

Aber genau das ist ja der wichtigste Punkt bei der Inbetriebnahme der Anlage... Wir programmieren ja genau auf dieses Ziel hin. Wie setzt du denn i Vorfeld deine Überlegungen hierfür um?

@Ralle
Genau für den Punkt "Inbetriebnahme und Wartung" versuch ich mit diesem Thread ja evtl. Lösungsansätze "zu diskutieren", da auch mir hierfür komplette Ansätze fehlen. Natürlich müssen wir davon ausgehen, dass die OOP Prinzipien auch dem Inbetriebnehmer und dem Wartungstechniker bekannt sind und er solche Programmarchitekturen auch versteht. Natürlich ist dies in der realen Praxis noch nicht wirklich der Fall, aber ich denke in dem Post sollten wir einfach mal die Annahme machen, dass dies der Fall wäre

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Genau für den Punkt "Inbetriebnahme und Wartung" versuch ich mit diesem Thread ja evtl. Lösungsansätze "zu diskutieren", da auch mir hierfür komplette Ansätze fehlen. Natürlich müssen wir davon ausgehen, dass die OOP Prinzipien auch dem Inbetriebnehmer und dem Wartungstechniker bekannt sind und er solche Programmarchitekturen auch versteht. Natürlich ist dies in der realen Praxis noch nicht wirklich der Fall, aber ich denke in dem Post sollten wir einfach mal die Annahme machen, dass dies der Fall wäre

Ja Ihr geht halt falsch herum an die Sache heran.
Richtig wäre zu überlegen, wie muss die Struktur aussehen, damit ne Anlage ordentlich in Betrieb gesetzt werden kann und 20 Jahre lang ordentlich erweitert und am Leben erhalten werden kann.
Wenn das mit OOP nicht geht, dann nutzt halt einfach eine der seit Jahrzehnten bewährten Programmierstile. Und versucht nicht OOP so zu verbiegen, das nicht gleich jeder die Hände über dem Kopf zusammenschlägt

Sicherlich muss man aber auch Unterschiede zw. Serienmaschinen und Sonderanlagen machen...

Unsere Sonderanlagen leben über Jahrzehnte und werden ständig im laufenden Betrieb mehr oder weniger groß umgebaut/erweitert...

 

[Biiebs]

Richtig wäre zu überlegen, wie muss die Struktur aussehen, damit ne Anlage ordentlich in Betrieb gesetzt werden kann und 20 Jahre lang ordentlich erweitert und am Leben erhalten werden kann.
Wenn das mit OOP nicht geht, dann nutzt halt einfach eine der seit Jahrzehnten bewährten Programmierstile. Und versucht nicht OOP so zu verbiegen, das nicht gleich jeder die Hände über dem Kopf zusammenschläg

Jaein... klar sollte eine Anlage mind. 20 Jahre funktionieren. Natürlich hat sich die klassische SPS-Programmierung ebenfalls die letzten 20 Jahre absolut bewährt, vor allem im Anlagenbau... Aber da wir ausnahmsweise mal die Gelegenheit haben etwas neues (OOP) auszuprobieren und zu evaluieren ob sich dies für unsere Firma / Branche bewährt würde ich schon gern beim Thema OOP bleiben, manch andere Firma haben mittlerweile Anlagenbau komplett auf OOP umgestellt.

 

[ioStart]

@ioStart

Könntest du deinen Ansatz etwas genauer beschreiben?

OOP bedeutet für mich, dass es beispielsweise einen Baustein für ein Pneumatikventil gibt. Da ist Störbehandlung und Meldungsausgabe enthalten. Je nach Anzahl an Ventile/Zylindern gibt es halt entsprechend viele Instanzen.

Die Instanzen kann ich notfalls auch bei der Inbetriebnahme anlegen und die variablen Werte über die Schnittstelle übergeben. Allerdings möchte ich nicht bei der Inbetriebnahme eine Baustein für Ventile, Motoren, Servos, Hydraulik.... entwickeln

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ioStart

OOP bedeutet für mich, dass es beispielsweise einen Baustein für ein Pneumatikventil gibt. Da ist Störbehandlung und Meldungsausgabe enthalten. Je nach Anzahl an Ventile/Zylindern gibt es halt entsprechend viele Instanzen.

Die Instanzen kann ich notfalls auch bei der Inbetriebnahme anlegen und die variablen Werte über die Schnittstelle übergeben. Allerdings möchte ich nicht bei der Inbetriebnahme eine Baustein für Ventile, Motoren, Servos, Hydraulik.... entwickeln

OK, dann hab ich OOP schon vor 20 Jahren eingesetzt.
Solange man keine Multiinstanz-DBs verwendet geht das auch im laufenden Betrieb einfach zu erweitern. Zumindest bei Siemens

PS: ist doch wahr hat ja Ralle weiter oben auch schon angesprochen

 

[Blockmove]

Ich würde das Thema gerne auf Codesys und "richtiges" OOP beschränken und Siemens aussen vor lassen.
Siemens und Codesys entspricht etwa C und C++.
Und @Biiebs meint hier wirklich die Möglichkeiten von Codesys / Twincat und nicht die vergleichsweise einfachen Siemens Multiinstanzen.

OOP ist eine tolle Sache.
Das Testen der Funktionen bei der Inbetriebnahme ist mit allerdings zu riskant (weil zeitintensiv). Daher versuche ich immer im Vorfeld möglichst viel abzufangen und durch Tests zu bestätigen. Das verschafft dann den Vorteil, dass man die Architektur mit größerer Sicherheit definieren kann und das Debuggen idealer-weiße ganz entfällt.

Beim Online-Test sehe ich aktuell auch noch das Thema. Wenn ich selbst ein Programm schreibe, dann bin ich mit den Eigenschaften und Methoden vertraut. Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.

 

[ducati]

Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.

Wenn man den Programmierstil nicht schnell durchschauen kann, führt jede Änderung/Erweiterung welche nicht durch den ursprünglichen Programmierer gemacht wird, zur parallelen Einführung eines zweiten Programmierstils in der gleichen Steuerung...

 

[SPS-Bitschubser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bißchen out off topich....
Was ich mich frage was sind die Vorteile von OOP zu der jetzigen Programmierung?
Wie lange dauert Änderungen? Richtig Dokumentieren etc.
Wie schaut es aus mit der Migration auf andere Systeme?
S5 AUF s7 AUF TIA...
Meiner Meinung nach setzen die Firmen auf OOP die wo die letzten 20 Jahre keine richtigen Schnittstellen zur Visualisierung geschaffen haben.
Ähnlich ca. Das industrie 4.0 Thema. Nach 15 Jahren meinen manche Firmen könnte alles besser machen als andere andern die das schon 20 jahre davor umgesetzt haben.

 

[Blockmove]

@SPS-Bitschubser

Vorneweg zum Verständnis:
Richtige OOP gibt es bei Siemens bislang eigentlich nicht.
Multiinstanz kann man vielleicht als Vorstufe betrachten.
Codesys ist hier ein gutes Stück weiter und hat das OOP-Konzept deutlich weiter umgesetzt.
Du hast hier z.B. Eigenschaften, Methoden, Interfaces, Vererbung ...
Das hat durchaus Vorteile für den Programmierer. Du bekommst ein sehr klar strukturiertes Programm mit guter Lesbarkeit.
Visu, Überwachung und Diagnose lassen sich gut und ohne viel Aufwand integrieren. Der Programmieraufwand sinkt deutlich.

Was aber jetzt noch nicht so ausgereift ist, sind die Tools für Inbetriebnahme und Online-Fehlersuche.
Bei S5 konntest du auf Adressebene Fehler suchen. Hast du die beteiligten E/A Adressen gekannt, konntest du dich durchhangeln.
Bei S7, TIA, Codesys 2.x kamen dann schon Instanzen dazu. Wenn jemand unsauber programmiert und schlecht dokumentiert, dann wird's schwierig. Bei Codesys 3.x kommen Methoden und Eigenschaften dazu. Eigentlich ist das im Prinzip noch eine weitere Abstraktionsschicht, die noch weiter von der Hardware weg ist.

Um es etwas mit Siemens zu vergleichen:
Bei S7-Classic war der Zugriff auf Instanz-Daten eigentlich schlechter Stil.
Mit TIA hat sich das geändert. Zuerst wurden HMI-Daten Bestandteil der Instanzen.
Mittlerweile habe ich schon FBs gesehen, bei denen nicht mehr über die Schnittelle (In, Out, InOut) zugegriffen wird, sondern direkt in den Static-Bereich geschrieben wird. OK die Querverweisfunktionen von TIA sind nun deutlich besser, aber als Instandhalter muss man mit sowas erstmal zurecht kommen.

Schau mer mal was die Entwicklung noch bringt

Gruß
Blockmove

 

[holgermaik]

Ich denke OOP wird sich in der klassischen Anlagen- / Maschinensteuerung nicht durchsetzen.
Mit Interfaces, Vererbung, Methoden und dann den Pointern "This" und "Super" an Anlagen die jemand fremdes programmiert hat, sind 99,5% der Leute einfach überfordert einen Fehler zu finden.
Der eigendliche Programmierer mag ja wissen was er wo macht (eventuell auch nach 5 Jahren noch) aber jemand fremdes hat hier keine Chance in einem angemessenen Zeitrahmen einen Fehler zu finden, geschweige ein Programm zu erweitern.
Die Ersparnis beim Programmieren zahlt der Endkunde doppelt & dreifach drauf.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@holgermaik
Ich sehe es nicht so pessimistisch.
Es hängt ganz viel an den Tools / der Entwicklungsumgebung.
Mit einem vernünftigen Online Objektbrowser und guten Online-Status kann es schon was werden

 

[rostiger Nagel]

Die Ersparnis beim Programmieren zahlt der Endkunde doppelt & dreifach drauf.

Genau das kann ja auch von so manchen Maschinenbauer gewollt sein.
Für so jede noch so kleine Störung muss dann der Spezialist ran, über
die Fernwartung oder auch vor Ort. Dieses wird dann teuer bezahlt.

 

[Biiebs]

Und @Biiebs meint hier wirklich die Möglichkeiten von Codesys / Twincat und nicht die vergleichsweise einfachen Siemens Multiinstanzen.

Wir unterscheiden hier einfach 2 komplett unterschiedliche Welten mit Siemens und Codesys / Twincat und deren Werkzeuge, aber die Thematik wird im Forum ja schon Jahrelang diskutiert . Und ich mein in meinem Post auch nur die Codesys / Twincat Welt.

Beim Online-Test sehe ich aktuell auch noch das Thema. Wenn ich selbst ein Programm schreibe, dann bin ich mit den Eigenschaften und Methoden vertraut. Komme ich als Fremder / Instandhalter an ein OOP-Programm dann ist es (für mich) schwer die Abhängigkeiten zu finden.
Wenn ich eine Anlage überhaupt nicht kenne, dann suche ich vom Aktor rückwärts bis ich die fehlenden Bedingungen finde. Und bei dieser Vorgehensweise tu ich mich bei OOP schwer.

Ich denke OOP wird sich in der klassischen Anlagen- / Maschinensteuerung nicht durchsetzen.
Mit Interfaces, Vererbung, Methoden und dann den Pointern "This" und "Super" an Anlagen die jemand fremdes programmiert hat, sind 99,5% der Leute einfach überfordert einen Fehler zu finden.

Ihr habt zum Teil recht, aber ist das aktuell nicht egal ob jetzt in "klassischer" Programmierung oder OOP? Wenn ein Inbetriebnehmer das Programm und die Strukutur nicht kennt, ist leider der Weg sehr mühselig von unterster Aktor/Sensorebene sich bis nach oben durchzuarbeiten. Gegenüberstellen würd ich es eher so:

Klassische Programmierung:
* Je nach Strukturt / Architektur und Programmiersprache (AWL, FUP,...) kann aber muss das Programm nicht unbedingt leserlich sein. Es kommt hier ebenso auf die Programmierskills des Entwicklers an (Spaghetticode ist genauso unübersicht)
* Debugging / IBN ist aufjedenfall machbar, da alles sich über globale Variablenlisten oder Funktionsbausteinen geschieht, wodurch der aktuelle Beobachtungswert immer verfügbar ist. (Aber auch hier gilt... reine Funktionen haben ebenfalls kein Gedächtnis, also auch keinen Beobachtungswert)

OOP:
* Je nach Struktur / Architektur kann es zu erheblichen Zeitersparnis in der Entwicklung der Software kommen, da durch einige Prinzipien (Vererbung etc.) einiges an Quellcode eingespart werden kann und dadurch, je nach einwandfreier Dokumentation, das Programm um ein vielfaches kleiner und übersichtlicher wirkt.
* Der Vorteil liegt hierbei ebenfalls bei der Skalierbarkeit der Software, da hier im Gegensatz zu dauerhaftem IN_OUT durchgeschleife, so gut wie keine Abhängigkeiten zwischen den einzelnen Bausteinen besteht, was einen erhebliche Zeitersparnis bei einer Erweiterung zur Folge hat (Vorausgesetzt die Basisstruktur stimmt)
* Der Nachteil liegt hier eben bei der Inbetriebnahme der Anlage, da wir hier Methoden, Eigenschaften und Interfaces benutzen, die im Gegensatz zur Basisklasse (Bausteininstanz), genauso wie Funktionen kein Gedächtnis besitzen und der aktuelle Beobachtungswert mit "???" angezeigt wird. Und genau das würde ich hier gerne etwas genauer analysieren ob es hier nicht Möglichkeiten gibt wie man in diesem Use-Case der Inbetriebnahme dieses Problem lösen könnte.

Mir ist bekannt, dass einige größere Firmen und Hersteller schon komplett auf OOP umgestellt haben, wäre hier jedenfalls mal interessant zu wissen, wie diese das Problem in den Griff bekommen.

(Ich weiß OOP lässt schnell die Möglichkeit zum Abschweifen


____
Offtopic:

Da hier die OOP Thematik doch sehr viel Interpretationsspielraum zulässt und einige doch etwas interessierter der Thematik entgegen schweifen. Hätte ich mal den Vorschlag, was haltet ihr davon, wenn wir einfach mal gemeinsam Post erstellen, indem wir evtl. mal die OOP Thematik, speziell in der SPS-Welt, in einem "FAQ / Tutorial / Ansätze" und vllt. Beispielprojekt auf klassischer Programmierung und dem versch. OOP Ansätze (z.B. Vererbung, Dekoration u. Delegation, Design Pattern) entgegen stellen um hier dem ein oder anderen in diese Thematik den Sprung zu erleichtern? Vllt. wird dem ein oder anderen auch etwas klarer was die Vorteile und Nachteile hierüber sind?

(Die Idee hiervon kommt eigentlich daher, da hier im Forum, sowie im Codesys-Forum, jeder mal den Sprung in Richtung wagen möchte, die Beiträge hierfür jedoch nur in einer sehr geringer Anzahl vorhanden sind und das OOP Thema durch fehlendes Wissen wieder sein gelassen wird. In anderen Sprachen funktionieren diese Prinzipien ja auch. Klar kann dies nicht 1:1 auf die SPS-Welt portiert werden, aber genau hier ist ja das Problem, dass viele nicht lösen können/wollen)

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ein Inbetriebnehmer das Programm und die Strukutur nicht kennt, ist leider der Weg sehr mühselig von unterster Aktor/Sensorebene sich bis nach oben durchzuarbeiten.

Dann ist das ganze für die Industrieautomatisierung ungeeignet bzw. gaaanz unsauberer Programmierstil...

Programmierskills des Entwicklers an (Spaghetticode ist genauso unübersicht)

naja... solange der code nicht total verworren ist, kann man bei Spaghetticode zumindest mal hinten was anfügen

(Aber auch hier gilt... reine Funktionen haben ebenfalls kein Gedächtnis, also auch keinen Beobachtungswert)

Also bei Siemens kann man FCs online beobachten...

OOP:
* Je nach Struktur / Architektur kann es zu erheblichen Zeitersparnis in der Entwicklung der Software kommen, da durch einige Prinzipien (Vererbung etc.) einiges an Quellcode eingespart werden kann und dadurch, je nach einwandfreier Dokumentation, das Programm um ein vielfaches kleiner und übersichtlicher wirkt.
* Der Vorteil liegt hierbei ebenfalls bei der Skalierbarkeit der Software, da hier im Gegensatz zu dauerhaftem IN_OUT durchgeschleife, so gut wie keine Abhängigkeiten zwischen den einzelnen Bausteinen besteht, was einen erhebliche Zeitersparnis bei einer Erweiterung zur Folge hat (Vorausgesetzt die Basisstruktur stimmt)

wieso und warum spar ich denn da soviel Zeit gegenüber einer Ordentlichen Struktur mit mehrfach verwendbaren Bausteinen beim Siemens???

Ich stell mir so grad Supermonsterspezialbausteine vor, welche dann aber trotzdem bei ner neuen Anlage nicht das abdecken, was ich grade brauch...

Wir haben einen sehr schlanken Programmierstil mit sehr rudimentären Grundbausteinen, welche aber dafür immer passen, schon seit Jahrzehnten... Die Spezialsachen werden drumherum programmiert...

Ich hab schon viel gesehn, aber der Programmierstil in meiner aktuellen Firma ist das, was mir in den letzten 30 Jahren am besten gefallen hat...

 

[ducati]

Vorneweg zum Verständnis:
Richtige OOP gibt es bei Siemens bislang eigentlich nicht.
Multiinstanz kann man vielleicht als Vorstufe betrachten.
Codesys ist hier ein gutes Stück weiter und hat das OOP-Konzept deutlich weiter umgesetzt.
Du hast hier z.B. Eigenschaften, Methoden, Interfaces, Vererbung ...
Das hat durchaus Vorteile für den Programmierer. Du bekommst ein sehr klar strukturiertes Programm mit guter Lesbarkeit.
Visu, Überwachung und Diagnose lassen sich gut und ohne viel Aufwand integrieren. Der Programmieraufwand sinkt deutlich.

kann man denn in diesen ganzen Eigenschaften, Methoden, Interfaces, Vererbung irgendwas im laufenden Betrieb also stoßfrei und ohne Aktualdatenverlust ohne CPU Stopp Ändern/Erweitern? Wenn Nein, dann fällt das für uns sowieso schon raus...

Das ist beim Siemens mit den Multiinstanzen ja schon ein No-Go... erstrecht beim TIA...

 

[ducati]

Da hier die OOP Thematik doch sehr viel Interpretationsspielraum zulässt und einige doch etwas interessierter der Thematik entgegen schweifen. Hätte ich mal den Vorschlag, was haltet ihr davon, wenn wir einfach mal gemeinsam Post erstellen, indem wir evtl. mal die OOP Thematik, speziell in der SPS-Welt, in einem "FAQ / Tutorial / Ansätze" und vllt. Beispielprojekt auf klassischer Programmierung und dem versch. OOP Ansätze (z.B. Vererbung, Dekoration u. Delegation, Design Pattern) entgegen stellen

ja gerne...