Software Resilienz im SPS-/Produktionsbereich

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

nicht schlecht ...
Allerdings passen manche Dinge nicht so recht zu einer SPS _
4: die SPS kennt kein Dispose oder ähnlich
7: Unit-Tests sehe ich im komplexeren Umfeld eher problemeatisch - für kleinere Funktionseinheiten ggf. machbar

 

[rostiger Nagel]

nicht schlecht ...
Allerdings passen manche Dinge nicht so recht zu einer SPS _
4: die SPS kennt kein Dispose oder ähnlich
7: Unit-Tests sehe ich im komplexeren Umfeld eher problemeatisch - für kleinere Funktionseinheiten ggf. machbar

Irgendwie passen die beiden Punkte schon
4: Meldungen über ProgrammAlarm die systemweit auch ans PG gesendet
werden, macht für mich zb das Prohgrammieren sehr einfach.
Gehandhabt wird es auf SPS Seite.
Wenn man zusätzlich noch Pro Diag nutzt, kommt es auch eher aus der Steuerung,
mit den beide kann schon eine sehr… wirklich sehr umfangreiche Diagnose erstellen.
Pro Diag ist gerade für Schrittketten Enthusiasten wie du und ich das Mittel zur Wahl,
man sollte natürlich Graph nutzen, was neben SCL ein tolles Werkzeug geworden ist
in TIA.

7: Units Test ist doch jetzt bei TIA auch ein großes Thema geworden.
Jede große Anlagen bestehen doch im Prinzip aus kleinen Funktionseinheiten.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

@rostiger Nagel : Punkt 4 war Speicher freigeben ...

 

[rostiger Nagel]

Huch, dann nehme ich mein Statement zurück

 

[If-Schleife]

Wenn ich aber Punkt vier umformuliere in: "Nicht verwendeten Code entfernen!" Passt dann nicht auch das Thema Ressourcen freigeben?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@If-Schleife
Ich hab jetzt deine Zusammenstellung gelesen und finde sie auch ok.
Am Anfang der Diskussion (Beitrag #7) habe ich geschrieben, dass man sich einfach an die alten Programmierregeln die seit Anbeginn gelten halten soll. Genau diese Regeln hast du nun zusammen geschrieben ... Somit keine neuen Erkenntnisse

Was aber in deinen Punkten zu kurz kommt und auch von anderen angesprochen worden, sind die ganzen Themen rund um das Programmieren.
Also die Dinge wie:

• Kommunikation zwischen allen Beteiligten
• Informationsbeschaffung
• Prozessverständniss
• Projektorganisation
• Regelmässiges Anpassen, Optimieren und Hinterfragen von Firmenstandards
• Fort- und Weiterbildung
• Arbeitsklima
• ...

Du kannst dich noch so an Programmiervorgaben und Styleguides halten und bekommst trotzdem keine gut funktionierende Anlage.
Eine Anlage bzw. eine Software ist nur so gut wie das Umfeld aus dem sie kommt.

 

[Mrtain]

Ich hab jetzt deine Zusammenstellung gelesen und finde sie auch ok.
Am Anfang der Diskussion (Beitrag #7) habe ich geschrieben, dass man sich einfach an die alten Programmierregeln die seit Anbeginn gelten halten soll. Genau diese Regeln hast du nun zusammen geschrieben ... Somit keine neuen Erkenntnisse

Ja, aber jetzt man das alt bewährte unter einem neuen Buzzword zusammengefasst. Da freut sich doch das Marketing

 

[If-Schleife]

Ja, aber jetzt man das alt bewährte unter einem neuen Buzzword zusammengefasst. Da freut sich doch das Marketing

Ich will das nicht fürs Marketing zusammen fassen sondern für mich. Manchmal braucht man Erinnerungen, und Gedankenstützen.

So wollte ich das sehen

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

@If-Schleife,
du musst dich nicht rechtfertigen, meiner Ansicht nach ist
eine schöne Diskussion entstanden.
Was mich erstaunt, das Thema hat jetzt länger als ein Tag,
mit vielen Beiträgen gehalten, ohne große Streit, das ist fast
nie so.

Vielleicht nimmst du die Punkte von Blockmove aus Beitrag #206
mit auf und kopierst deine Auflistung in den ersten Beitrag, in der
Mitte geht das einfach unter.

Ich lese mir das morgen noch mal durch, vielleicht mache ich
da einen FAQ raus.

 

[Mrtain]

Ich will das nicht fürs Marketing zusammen fassen sondern für mich. Manchmal braucht man Erinnerungen, und Gedankenstützen.

So wollte ich das sehen

Das war jetzt nicht auf dich bezogen.
Persönlich finde ich die Zusammenfassung der Punkte gut und auch Diskussion war schön zu verfolgen. Nur mit dem Begriff Resilenz kann ich mich nicht so anfreunden. Für ich das einfach gutes Softwaredesign/Architektur. Und dazu gibt es jede Menge Literatur. Aber das ist nur meine persönliche Meinung ^^

 

[If-Schleife]

Text etwas optimiert:

1. Robuste Fehlerbehandlung:
   • Implementiere effektive Fehlerbehandlung, um unerwartete Probleme abzufangen und angemessen zu reagieren.
   • Protokolliere Fehlermeldungen für spätere Diagnose und Behebung.
2. Klare Struktur und Lesbarkeit:
   • Verwende aussagekräftige Bezeichner für Variablen, Funktionen und Klassen.
   • Halte den Code gut strukturiert und formatiert, um die Lesbarkeit zu erleichtern.
   • Kommentiere komplexen Code, um anderen Entwicklern das Verständnis zu erleichtern.
3. Vermeidung von Redundanz:
   • Vermeide doppelten Code (Redundanz), um Wartbarkeit und Änderbarkeit zu verbessern.
   • Nutze Funktionen und Klassen, um Code logisch zu organisieren und zu wiederverwenden.
4. Effiziente Ressourcennutzung:
   • Achte darauf, Ressourcen wie Speicher und CPU effizient zu nutzen.
   • Schließe Ressourcen, wenn sie nicht mehr benötigt werden, um Lecks zu vermeiden.
5. Gute Dokumentation und Kommunikation:
   • Dokumentiere den Code klar und konsistent, um anderen Entwicklern die Arbeit zu erleichtern.
   • Beschreibe Schnittstellen, Funktionen und wichtige Entscheidungen. Biete Plattformen für den Informationsaustausch zwischen den Fachexperten.
6. Einhalten von Coding Standards:
   • Befolge die geltenden Coding Standards für die verwendete Programmiersprache.
   • Konsistenz in der Formatierung und im Stil fördert die Lesbarkeit und Wartbarkeit.
7. Tests und Testautomatisierung:
   • Schreibe umfassende Tests, um sicherzustellen, dass der Code korrekt funktioniert.
   • Automatisiere Tests, um eine konsistente Überprüfung bei Codeänderungen sicherzustellen.
8. Versionierung und Backups:
   • Verwende ein Versionskontrollsystem wie Git, um den Code zu verfolgen und zu sichern.
   • Erstelle regelmäßig Backups, um Datenverlust zu verhindern.
9. Performanceoptimierung:
   • Identifiziere und behebe Engpässe in der Performance, um eine reibungslose Ausführung sicherzustellen.
10. Sicherheit:
    • Berücksichtige Sicherheitsaspekte und verhindere potenzielle Schwachstellen.
    • Validiere Benutzereingaben.

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Einige Anmerkungen hätte ich allerdings noch:

• Punkt 3: Das Prinzip nennt sich DRY (Dont repeat yourself)
• Für mich gehört das KISS - Prinzip auch noch dazu ( Keep it stupid simple)

 

[If-Schleife]

Das war jetzt nicht auf dich bezogen.
Persönlich finde ich die Zusammenfassung der Punkte gut und auch Diskussion war schön zu verfolgen. Nur mit dem Begriff Resilenz kann ich mich nicht so anfreunden. Für ich das einfach gutes Softwaredesign/Architektur. Und dazu gibt es jede Menge Literatur. Aber das ist nur meine persönliche Meinung ^^

Ich fand das wort ganz toll. Vielleicht hätten viele mit dem Wort Stabilität erst gar nicht angefangen zu lesen.


Neues regt die Neugierde

Am Ende ist es nichts neues. Natürlich.

 

[Larry Laffer]

Jetzt fehlt in der Aufstellung für mich (und ja anscheinend nicht nur für mich) die Anregungen von @Blockmove im Beitrag #206.
Auch die Hinweise (gerade weil es ja auch nette und gute Buzzwords sind) von @Mrtain im Beitrag #212 sind auch aus meiner Sicht nenneswert !

Auch ich fand, dass diese Diskussion nach anfänglichen Startproblemen gut gelaufen ist. Normalerweise geht so etwas, wie @rostiger Nagel schon geschrieben hat, auch schnell mal nach hinten los ...

 

[If-Schleife]

Zuviel Werbung?
-> Hier kostenlos registrieren

• Kommunikation zwischen allen Beteiligten
• Informationsbeschaffung
• Prozessverständniss
• Projektorganisation
• Regelmässiges Anpassen, Optimieren und Hinterfragen von Firmenstandards
• Fort- und Weiterbildung
• Arbeitsklima

Ich habe das Thema Kommunikation mit aufgenommen.


Ich finde Prozessverständnis ein sehe wichtiges Thema und da muss ich mich natürlich einarbeiten.

Die Projektorganisation, da kann ich nur meinen Beitrag leisten. Aber alles habe ich nicht in der Hand. Von dem her habe ich es nicht in die Liste genommen.

Fort und Weiterbildung kann ich als Angestellter nur einfördern aber selbst bezahlen will ich so etwas nicht. Am Ende bin ich nicht Selbständig und der Gewinn geht an meine Firma. Also sehe ich sie hier auch in der Verantwortung.


Arbeitsklima sehe ich wie oben.


Deswegen habe ich jetzt ein paar Punkte nicht mit aufgenommen

 

[Larry Laffer]

Denk immer daran, dass @rostiger Nagel ja überlegt, es in unseren FAQ-Bereich zu überführen. An der Stelle ist Vollständigkeit dann schon sinnig ...

 

[If-Schleife]

Denk immer daran, dass @rostiger Nagel ja überlegt, es in unseren FAQ-Bereich zu überführen. An der Stelle ist Vollständigkeit dann schon sinnig

Ja, das hatte ich überlesen. Ich versuche es vollständig zu machen.

Bei ein paar Punkten bin ich mir noch nicht sicher und erhoffe mir noch gute Anregungen. Ob es reingehört oder nicht.

Da @rostiger Nagel aber das FAQ macht kann er es hinzufügen. Gerne. Unterschiedliche Meinungen sind ja gewünscht

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja ... du wärst dann schon der Author ... deine Entscheidung.
Ich hatte auch schon daran gedacht - aber Helmut war da dann schneller ...

 

[Blockmove]

Einige Anmerkungen hätte ich allerdings noch:

• Punkt 3: Das Prinzip nennt sich DRY (Dont repeat yourself)
• Für mich gehört das KISS - Prinzip auch noch dazu ( Keep it stupid simple)

Stimmt KISS gehört unbedingt dazu.

DRY ist zweischneidig und auch mit Gefahren verbunden.
Beispiel:
Wir haben viel Fördertechnik im Haus. Also Rollenbahnen, Riemenförderer, Umsetzer, Drehtische, Lift, usw.
Auf den ersten Blick schreit das natürlich nach FBs.
Aber:
Man soll es nicht für möglich halten, wie viele Ablauf-Varianten es nur von Rollenbahnen gibt.
Ich denk 20 werden da nicht reichen. Du fängst also mit dem simplen FB an und hast ruckzuck die nicht mehr wartbare eierlegende Wollmichsau.
Bei der Inbetriebnahme ändert sich dann auch noch jedes mal was und Änderungen sollen auch noch in der laufenden Produktion ohne leerräumen möglich sein. Ich verzichte da lieber auf komplexe Bausteine und hab dann eben RY antstelle von DRY.
Hat sich (in dem Anwendungsfall) über viele Jahre bewährt. Ich denke das deckt sich auch mit den Anmerkungen von @PN/DP mit den Verknüpfungssteuerungen.
Hier kann dann auch noch bei OOP ein zusätzliches Risiko entstehen. Stimmt nämlich das Grundgerüst nicht, kann hier selbst ne kleine Änderung einiges nach sich ziehen. Betonung auf "kann"

 

[Larry Laffer]

@Blockmove : so ein Super-Alleskönner-Baustein macht auch keinen Sinn und ist auch nicht mit DRY gemeint. Hier geht es aus meiner Sicht eher um sich wiederholende identische Operationen (die man ggf. sinnvoll als Funktion abbilden kann - also z.B. FC) - gleiche Berechnungen (aber 10 mal programmiert) - ein Baustein für einen FU, der dann x-mal verwendet werden kann - etc.