• Aktuell gibt es hier im Forum Spam von langjĂ€hrigen Usern.

    Vermutlich wurden die Zugangsdaten dieser User irgendwo geleakt.

    Die BeitrÀge enthalten alle einen einen Link zu Schadsoftware. Bisher lassen sich diese BeitrÀge recht einfch erkennen. Sie sind in englisch und haben nichts mit dem Thema zu tun. Seid hier bitte sehr vorsichtig.

    1. Nicht auf solche Links klicken
    2. Bitte solche Dinge sofort melden (Button unten am Beitrag)
    3. Wenn jemand Private Nachrichten mit solchen Inhalten bekommt, bitte auch melden!

    Die betroffenn User haben wir gesperrt, Wenn du betroffen bist, dann melde dich gerne bei uns ĂŒber das Kontaktformular. Wir setzen dann dein Passwort zurĂŒck und du kannst dir ein neues vergeben.

    Danke fĂŒr eure Mithilfe!
    Markus

Software Resilienz im SPS-/Produktionsbereich

Zuviel Werbung?
-> Hier kostenlos registrieren
Interessant PLCOpen hat vorgestern ein Dokument zu dem Thema raus gebracht.


Scheint wohl nicht nur mich zu interessieren😁
Die Sau wird halt grad durchs Dorf getrieben...

Stell doch einfach mal ein Programm von Dir hier ein, vielleicht gibt Dir jemand VerbesserungsvorschlÀge.
 
Als ich angefangen habe, hat mir ein erfahrener Programmierer gesagt: "Der Quellcode selbst ist genug Kommentar!" 😉
GrundsÀtzlich stimmt das auch. Das Programm ansich sollte durch Struktur und Variablennamen und Netzwerktitel und Bausteinnamen etc. selbsterklÀrend sein. Trotzdem sollte man abundzu zumindest bei Sonderlocken im Kommentar vermerken, warum man hier dies oder jenes tut...

Solchen Quatsch hier kann man aber lassen:
Code:
U Pu1.Stoe // Pumpe 1 Störung
O Pu2.Stoe // Oder Pumpe 2 Störung
...

Zu viele Kommentare haben die Eigenart, bei Änderungen der Logik wĂ€hrend IBN oder spĂ€ter nicht mitgeĂ€ndert zu werden.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was gibt’s da zu Lachen?
Gerade bei Inbetriebnahmen kommt man doch mit einigen anderen Programmierern zusammen.
Und die wenigsten die ich kennengelernt habe sind menschenscheue Fachidioten.
Das er da ein bisschen lÀchelnd kann Ich verstehen,
Programmierer sind zwar keine Fachidioten, aber oft
Eigenbrödler vor den Herren. Jeder kann es besser!
Das merkt man ja schon in jedem Thread wo es um
Programmierstile geht, auch hier.

Liegt vielleicht in der Natur des Jobs, oft werden Sie
als Feuerwehr ausgenutzt, um Unklarheiten oder Fehl-
konstruktionen zu beseitigen, sind dann unter UmstÀnden
Wochenlang alleine oder mit einen Mechaniker auf der Baustelle
und kĂ€mpfen gegen WindmĂŒhlen.

Die Teamarbeit fÀngt ja nicht nur bei den Programmierern an,
sondern im Vertrieb.
  • Ist die Maschine / Anlage zum angemessenen Preis verkauft
  • Sind die Termine Realistisch
  • Sind alle Informationen im Haus und auch verteilt
  • Entspricht das was verkauft ist den Anforderungen des Kunden
Dann geht es in die Konstruktion SphĂ€re, ĂŒblicherweise Arbeiten da
alle beteiligten anneindar vorbei
  • Werden alle Gewerke der Konstruktion an der Konzeptfindung beteiligt
  • Arbeiten diese Gewerke als Team zusammen oder konstruiert jeder
    fĂŒr sich an den anderen vorbei
  • Gibt es ZeitplĂ€ne und wird versucht sich dran zu halten
  • Sind die Konstrukteure auf dem Stand der Technik oder alte Hasen und
    verweigern sich in der persönlichen Weiterendwicklung
  • Entspricht das was Konstruiert wurde den Anforderungen des Kunden
Dann geht es irgendwann in die Fertigung
  • Haben die Jungs und MĂ€dels Bock auf das Projekt, bringen sich ein
    und kommunizieren mit der Konstruktion
  • Arbeiten Sie sauber oder rotzen, das was konstruiert ist nur so da hin
  • Bemerken Sie wĂ€hrend des Schraubens, da passt etwas nicht oder der
    Kollege hat etwas falsch zusammengeschraubt und es wird korrigiert
  • Entspricht das zusammengebaute den Anforderungen des Kunden
Ist die Abnahme mit HĂ€ngen und wĂŒrgen erfolgt geht es auf die Baustelle
  • Ist die Baustelle gut vorbereitet
  • Sind die Monteure gut und motiviert
  • Ist ausreichend Zeit fĂŒr die Aufstellung geplant
  • Können die Monteure die Maschine aufstellen oder sind Sie ĂŒberfordert
  • Haben die Monteure auch Bock auf die Anlage und den Kunden bzw. das Land
  • Hat der Kunde Bock auf die Maschine
  • Können die Monteure die Betreiber gut schulen
  • Entspricht das aufgestellte den Anforderungen des Kunden
Was hat das jetzt mit der Programmierung zu tun?
Eine ganze Menge, passt es oben nicht kannst du
Programmieren so sauber und fehlerfrei wie du willst,
es wird nichts helfen.

Code:
ShitOut := ShitIn;

Fehler werden zurrest immer am Programm gesucht, weil
es fĂŒr die anderen am wenigsten greifbar und augenscheinlich
wenig Arbeit bereitet.

Dann wirst du es als Programmierer auf der Baustelle immer versuchen irgendwie
hinzu Fummeln, schmierst in deinen noch so schönen Programm rum, weil es
ohne Flex und SchweißgerĂ€t geht. Am Ende ist es wieder ein Kunstwerk.
KĂŒnstler sind immer MerkwĂŒrdig
 
Zuletzt bearbeitet:
Zur SoftwarequalitĂ€t ansich, jemand der sich damit auskennt sollte nen Standardprogrammierstil bzw. Standardbausteine entwickeln, die dann fĂŒr einen Kunden oder die Automatisierungsfirma einheitlich gelten und ĂŒber Jahre fix bleiben.

Dann den Programmierer darauf schulen, eindeutige, umfĂ€gliche Vorgaben fĂŒr die Funktion geben, genĂŒgend Zeit fĂŒr Softwareerstellung und Inbetriebnahme zur VerfĂŒgung stellen.

Was ich halt noch mache, vor der Inbetriebnahme die Software und HMI im BĂŒro mit ner kleinen Minisimulation ordentlich durchtesten...
 
Zuletzt bearbeitet:
Zur SoftwarequalitĂ€t ansich, jemand der sich damit auskennt sollte nen Standardprogrammierstil bzw. Standardbausteine entwickeln, die dann fĂŒr einen Kunden oder die Automatisierungsfirma einheitlich gelten und ĂŒber Jahre fix bleiben.
Und die Anforderung ĂŒber einen einheitlichen Programmierstil und das jeder alle Programme verstehen sollte, halte ich fĂŒr unmöglich. Warum sollte jemand, der Palettentransport programmiert ein SPS Programm z.b. einer grĂ¶ĂŸeren AbfĂŒllanlage verstehen. Dazu gehören ja auch sehr viele spezifische Sachkenntnisse. Anders herum genauso. Beide Seiten mĂŒssten sich einarbeiten und von einem Programmierer ĂŒber Besonderheiten informiert werden ( bei grĂ¶ĂŸeren Änderungen ). Außer man Ă€ndert nur eine Bitmeldung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und die Anforderung ĂŒber einen einheitlichen Programmierstil und das jeder alle Programme verstehen sollte, halte ich fĂŒr unmöglich. Warum sollte jemand, der Palettentransport programmiert ein SPS Programm z.b. einer grĂ¶ĂŸeren AbfĂŒllanlage verstehen. Dazu gehören ja auch sehr viele spezifische Sachkenntnisse. Anders herum genauso. Beide Seiten mĂŒssten sich einarbeiten und von einem Programmierer ĂŒber Besonderheiten informiert werden ( bei grĂ¶ĂŸeren Änderungen ). Außer man Ă€ndert nur eine Bitmeldung.
Ja natĂŒrlich ist das stark BranchenabhĂ€ngig!
Üblicherweise (sinnvollerweise) wechselt aber der Programmierer bzw. die Automatisierungsfirma nicht jede Woche die Branche.
Fertigungsautomatisierung ist was ganz anderes als Prozessautomatisierung. Und ne Brauerei was anderes als nen Zementwerk. Und nen Fertigungsroboter was anderes als ne CNC-FrÀse. Mit jeweils passenden Werkzeugen und Programmierstilen und Standards.
 
Üblicherweise (sinnvollerweise) wechselt aber der Programmierer bzw. die Automatisierungsfirma nicht jede Woche die Branche.
Damit meinte ich auch die Leute, die einem was von einheitlichen Code erzÀhlen, den jeder lesen und verstehen kann. Egal aus welcher Branche.
Üblicherweise sind diese Leute gar keine Programmierer oder im ersten Jahr ( oder Marketingler einer Firma die mit G anfĂ€ngt ).
 
Auch Spaghetticode in FUP ohne OOP ist ein Programmierstandard ;) und wenn der nicht wirr ist, in der Regel auch nachvollziehbar und gut beobachtbar đŸ€·â€â™‚ïž
Wenn Du in nem Werk 1000 SPSn hast, ĂŒber 50 Jahre gewachsen, von 100 Lieferanten, von 10 SPS Herstellern, ĂŒber mehrere Steuerungsgenerationen, ohne eigene Werksnorm... dann brauchst ĂŒber Programmierstile und Standardisierung eh nicht mehr reden... Sowas muss sehr langfristig angelegt sein. Und neue Werke auf der grĂŒnen Wiese gibts in Deutschland eh nur sehr selten....

Also wie immer, die Diskussion ist ziemlich mĂŒĂŸig đŸ€·â€â™‚ïž
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin auch schon an viele fremde SPS-Programme herangekommen, sei es zur Fehlerbehebung, zur Erweiterung oder Optimierung.
Ich kann nur Blockmove aus vollem Herzen zustimmen:
Es gibt Programmierer, die haben das Talent schönen Code zu schreiben. Programm öffnen und sich wohlfĂŒhlen.
Es gibt andere, da machst du das Programm auf und fragst dich ob es ĂŒberhaupt zu der Anlage gehört.

Meine Erfahrung möchte ich dabei so zusammenfassen:
Geht es um Maschinen (auch Sondermaschinen), die von Firmen gebaut werden, die solche Art Maschinen als Haupteinnahmequelle bauen, ist der Code meistens grottenschlecht. Was sich dann auch wieder nach außen auswirkt, weil das Personal dann sagt: Die Maschine lief noch nie fehlerfrei bzw. der Inbetriebnehmer hat monatelang an der Anlage gesessen und Fehler gesucht bzw. behoben.
Das geht ĂŒber Bausteine, die nur in AWL ohne jeglichen Kommentar vorhanden sind ĂŒber Bausteine, die per Instanzdaten verschaltet werden anstatt ĂŒber In/Outs bis zu unverstĂ€ndlichen Spaghetticode. Oder "Handshakesignale", die nach Zeit x automatisch zurĂŒckgesetzt werden, ohne zu wissen, ob die Gegenstelle die registriert hat.
Grund sind hier eben der wiederverwendete Code (ohne daß dieser auch in Jahrzehnten mal ĂŒberarbeitet, verbessert oder kommentiert wurde), sowie interne "Vorschriften", die dann aber auch nur die internen Mitarbeiter verstehen, oder aber Werkstudenten in solchen LĂ€den: Du machst das schon, mach das mal so wie in Anlage XY, dann klappt das schon. Oder eben auch Zeitmangel, weil der Vertrieb sagt: Sowas haben wir doch schon X Mal gebaut, da kann doch die Programmierung nicht so lange dauern. Also wird der Code hingerotzt.

Ist eine Anlage individuell programmiert, weil es ein EinzelstĂŒck ist, wird der Code von Grund auf geschrieben und ist meistens auch strukturiert, kommentiert und man "fĂŒhlt sich wohl" darin.
Der Grund ist eben, daß der Programmierer sich fĂŒr genau diese Anlage Gedanken macht und das Programm auch entsprechend aufbaut. Oft gibt es dann auch nicht den Baustein, den man aus seiner eigenen Bibliothek wiederverwenden kann, den eierlegenden Wollmilchbaustein. Dadurch wird das Programm ĂŒbersichtlicher. Meistens ist hier dann auch die entsprechende Zeit im Projekt einkalkuliert und man setzt nicht "mal eben" einen Werksstudenten dran.

Klar hat jeder Programmierer seine Eigenarten. Klar sagt man bei dem ein oder Anderen: Was hat der da gemacht? Aber das ist bei jedem Handwerker so und schlußendlich gibt es viele Wege nach Rom.
Was ich aber denke, was ausschlaggebend ist, ist immer die Vorgeschichte zum Programm, wie auch @rostiger Nagel in #43 schreibt. Da kommt vieles zusammen:
Ist eine realistische Zeit fĂŒr die Programmierung (und ihrer Planung) einkalkuliert?
Werden die "richtigen" Personen mit der Erstellung beauftragt?
Ist die Mechanik korrekt geplant und ausgereift oder muß der Programmierer die MĂ€ngel der Mechanik ausgleichen?
Hat der Kunde korrekte Vorgaben gemacht oder soll die Maschine nach IBN völlig andere Anforderungen (zusĂ€tzlich) erfĂŒllen, als bei Bestellung?
Wer pflegt das Programm? 1, 2, 3 Personen oder jede Woche jemand Anderes?

Hallo Zusammen,

Gerne wĂŒrde ich mit euch das Thema Software Resilienz im Bereich SPS diskutieren!

Glaub ihr es ist ein Bereich der fĂŒr SPSen Sinn ergibt? Glaub ihr es gibt generell Programmierstrategien die eine Software stabiler macht? Und glaubt ihr es ist messbar, wenn man diese anwendet?


Ich habe sehr oft den Eindruck, dass in meinem Bereich so programmiert wird: "Hauptsache die Anlage lÀuft und besteht die Abnahme - egal wie!"

Auch jeder programmier hat seinen eigenen Stil und hĂ€lt den fĂŒr den besten!?

Aber gibt es Herangehensweisen die man Newbys mitgeben kann, damit eine Software stabiler lÀuft? Und welche sind diese?


Freue mich auf eure Ideen!

Ich denke "Sinn" macht es, sich mit dem Thema zu beschÀftigen, genauso wie "Styleguides" Sinn machen.
Am Ende muß aber lesbarer Code herauskommen, egal wie die Variablen benannt sind oder das Programm aufgebaut ist. Signale mĂŒssen nachvollzogen werden können, Signalwege mĂŒssen klar sein, Code sollte durch EinrĂŒcken und Kommentare strukturiert werden, Netzwerke Überschriften bekommen.

Ich glaube, die beste Programmierstrategie ist die, daß die Zeit fĂŒr die Programmierung realistisch kalkuliert wird und der Programmierer vor Beginn seiner Arbeit einmal in sich geht und ĂŒberlegt, wie er das Programm am besten aufbauen kann und nicht einfach drauf losprogrammiert und vor allem, daß die Anforderungen an die Mechanik und das Programm eindeutig formuliert sind. Denn was nĂŒtzt mir das schönste Programm, wenn ich am Ende alles umstricken muß, von hinten durch die Brust ins Auge, weil die Anforderungen der Mechanik oder des Kunden sich plötzlich völlig verĂ€ndern.
 
Und die Anforderung ĂŒber einen einheitlichen Programmierstil und das jeder alle Programme verstehen sollte, halte ich fĂŒr unmöglich. Warum sollte jemand, der Palettentransport programmiert ein SPS Programm z.b. einer grĂ¶ĂŸeren AbfĂŒllanlage verstehen.
Das sehe ich jetzt nicht so.
Die Basis der allermeißten Programme sind doch wohl AblĂ€ufe - also normalerweise Schrittketten.
Hier allerdings scheiden sich dann schon wieder die Geister in der Umsetzung :
- Graph (Siemens)
- "Merker"
- CASE (SCL / ST)
Danach kommt dann die Doku der Schritte - auch so ein Thema ...
Dann : wie werden von der Schrittkette die Aktionen geschaltet ? Direkt am Schritt ? Oder gesammelt am Ende (mein Favourit).

Bei speziellen Berechnungen (egal welcher Art) oder Regelungen gebe ich dir natĂŒrlich Recht - die sind aber meißtens (hoffentlich) in sich gekapselt und damit dann ggf. mit ErklĂ€rung dazu auch nachvollziehbar zu machen ...

Dazu gehören ja auch sehr viele spezifische Sachkenntnisse.
Die Kenntnis um die Maschine selbst und deren AblĂ€ufe und was wie zusammengehört setze ich hier natĂŒrlich auch voraus ...
 
Die Basis der allermeißten Programme sind doch wohl AblĂ€ufe - also normalerweise Schrittketten.
Da geht es doch schon los. Bei unseren Palettentransportanlagen wirst du keine einzige Schrittkette finden sondern einen FB pro Band.
Und in dem FB gibt es keine Schrittketten sondern nur logische VerknĂŒpfungen. Nur mal so als Beispiel.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da geht es doch schon los. Bei unseren Palettentransportanlagen wirst du keine einzige Schrittkette finden sondern einen FB pro Band.
Genau - unterschiedliche Vorgehensweisen ...
wĂŒrde ich z.B. in keinem Fall so machen - ich hĂ€tte immer eine Schrittkette, die von Segment 1 nach Segment 2 ĂŒbergibt - ggf. als eigenstĂ€ndigen parametrierbaren FB. Und das dann so oft wie Segment-Übergaben gibt ... (nach meiner Erfahrung ist das fĂŒr den Instandhalter auch nachvollziehbarer)
 
Jeder kann es besser!
Das merkt man ja schon in jedem Thread wo es um
Programmierstile geht, auch hier.
... da hast du (leider) Recht ... wobei das ja eigentlich gar nicht das Thema dieses Thread ist (auch wenn ich da jetzt auch drauf eingestiegen bin).
Das Thema war ja "stabile Programme" und das ist vom Programmierstil erst mal unabhÀngig ...
 
... da hast du (leider) Recht ... wobei das ja eigentlich gar nicht das Thema dieses Thread ist (auch wenn ich da jetzt auch drauf eingestiegen bin).
Das Thema war ja "stabile Programme" und das ist vom Programmierstil erst mal unabhÀngig ...
Ich bin der Meinung, das eine hÀngt mit dem Anderen zusammen und kann (oder sollte) nicht einzeln betrachtet werden.
Die Resilienz bedeutet ja eben, daß es "Fehler" (welcher Art auch immer) aushalten kann.
Die beste Resilienz ist bei einem solch "stabilen" System wie einer SPS ja, in erster Linie eigene Fehler zu vermeiden. In zweiter Linie, Ă€ußere zu erwartende Fehler abzufangen.
Die eigenen Fehler zu vermeiden hĂ€ngt meiner Meinung nach aber mit der Art und Weise der Programmierung zusammen. Wenn schon der Ersteller unĂŒbersichtlich programmiert, erkennt er selber nicht, ob er initialisiert, ĂŒber Array-Grenzen schreibt, Variablen doppelt belegt/benutzt, Speicherbereiche ĂŒberlappt.... Und wenn dann die erste Softwarepflege durch eine 2. Person erfolgt und diese nicht durch das Programm steigt, ja, wie soll diese Person dann Fehler ausschließen?

FĂŒr mich gehört das zusammen, denn ohne eine Strategie (ĂŒber deren Art man sich dann wiederum trefflich streiten kann) bekomme ich keine HĂ€rtung gegen Fehler.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@JSEngineering :
Jetzt wĂ€re ich aber nicht so vermessen zu sagen, dass ein Programm, nur weil es nicht meinem Programmierstil entspricht, schlechter ist als eines fĂŒr dieselbe Aufgabe von mir.
Um bei dem konkreten Beispiel zu bleiben (von @DeltaMikeAir ) kann ich mir schon gut vorstellen, dass die Programme von denen auch durchaus nachvollziehbar sind und stabil laufen ... Von meinen eigenen Werken mal nicht zu reden ... :cool:
 
... als ErgÀnzung zu Allem :
Aber natĂŒrlich bin ich (auch) schon an Maschinen gekommen, die nicht gut liefen und das Programm sooo grottig war, dass ich es kurzerhand weggeschmissen habe und es nach eigenen Vorstellungen neu gemacht habe. Danach war dann Frieden im Haus.
Das ist natĂŒrlich nur als Mitarbeiter im eigenen Haus so möglich ...
 
@JSEngineering :
Jetzt wĂ€re ich aber nicht so vermessen zu sagen, dass ein Programm, nur weil es nicht meinem Programmierstil entspricht, schlechter ist als eines fĂŒr dieselbe Aufgabe von mir.
Um bei dem konkreten Beispiel zu bleiben (von @DeltaMikeAir ) kann ich mir schon gut vorstellen, dass die Programme von denen auch durchaus nachvollziehbar sind und stabil laufen ... Von meinen eigenen Werken mal nicht zu reden ... :cool:
Das habe ich ja auch nicht gesagt :D

Ich hab weder gesagt, daß eine Strategie besser ist als die andere.
Nur ich habe Deinem Satz widersprochen, daß das Thema "stabile Programme" unabhĂ€ngig vom Programmierstil ist.
Der Stil trÀgt meiner Meinung essentiell dazu bei, ein Programm zu stabilisieren.

Ob das nun durch Schrittketten oder ĂŒbersichtliche logische VerknĂŒpfungen geschieht, sei dahingestellt, so lange es ĂŒbersichtlich und nachvollziehbar ist, was dann wieder der Programmierstil ist.
 
@JSEngineering :
Jetzt wĂ€re ich aber nicht so vermessen zu sagen, dass ein Programm, nur weil es nicht meinem Programmierstil entspricht, schlechter ist als eines fĂŒr dieselbe Aufgabe von mir.
Um bei dem konkreten Beispiel zu bleiben (von @DeltaMikeAir ) kann ich mir schon gut vorstellen, dass die Programme von denen auch durchaus nachvollziehbar sind und stabil laufen ... Von meinen eigenen Werken mal nicht zu reden ... :cool:
Aber da fÀngt es doch schon an, auch wenn der eigene Programmierstil, wirklich
der beste ist, heißt es noch lange nicht das er fĂŒr das Team der beste ist, wenn es
das Team nicht beherrscht.
Entweder kann ich das Team auf das Niveau heben, ansonsten muss ich unten bleiben
und versuchen es langsam zu verbessern.

Man sieht ja schon wieder die unterschiedliche Herangehensweise von euch beiden, der
eine will fĂŒr die gleiche Anwendung Schrittketten der andere Statemachine nutzen.
Sicher wird beides gut.
 
Ich hab weder gesagt, daß eine Strategie besser ist als die andere.
Nur ich habe Deinem Satz widersprochen, daß das Thema "stabile Programme" unabhĂ€ngig vom Programmierstil ist.
Der Stil trÀgt meiner Meinung essentiell dazu bei, ein Programm zu stabilisieren.
Sorry, Jens - da widersprichst du dir jetzt selber ...
Und genau auf dein Statement hatte ich mich bezogen ...
Der Stil trĂ€gt natĂŒrlich dazu bei - aber er ist nicht der SchlĂŒssel ...
 
ZurĂŒck
Oben