Sonstiges Toolchain-Desaster: Modernisierung in den nächsten Jahren realistisch?

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

Nach diesem provokanten Titel möchte ich mich zunächst selbst kurz vorstellen:

Mein Werdegang ist relativ untypisch für einen Software-Entwickler: Ich habe zuerst C/C++ gelernt, habe danach ein bisschen Erfahrung im industriellen Bereich gesammelt, bin dann aber aus dem industriellen Bereich "geflüchtet" und auf Frontend-Entwicklung mit TypeScript/React umgestiegen.


In dieser Zeit war ich schockiert darüber, welche Art von Software im Jahr 2020 in der Industrie eingesetzt wird: Nämlich monolithische Monsterprogramme, welche aufgrund ihrer Komplexität häufig abstürzen und mit regelmäßigen Updates bereits existierende Projekte inkompatibel oder unbrauchbar machen.
Das widerspricht allem, was ich früher über gute Software gelernt habe: Performance, Robustheit, Langzeit-Stabilität von File-Formaten etc...


Ich habe die folgende Serie an Artikeln beschrieben, welche dieses "Toolchain-Desaster" genauer erklären:
Links auf Wunsch des Autors entfernt, diese haben persönliche Daten enthalten (12.01.2022 Markus)


Jetzt werden mir manche vielleicht vorwerfen: Ich habe ja keine Ahnung von der Industrie, ich weiß gar nicht von was ich schreibe
Das stimmt teilweise, aber es ist meiner Meinung nach notwendig, dass auch "Outsider-Perspektiven" gehört werden, weil man sonst zu stark in der eigenen Betriebsblindheit gefangen ist.


Daher meine Fragen an euch:
Habt ihr auch das Gefühl, dass die Industrie derzeit in einem "Toolchain-Desaster" gefangen ist, sodass die Modernisierung der Entwicklungs-Flows eingebremst wird?
Falls ja, habt ihr das Gefühl dass es in den nächsten Jahren irgendeinen realistischen Ausbruch aus diesem "Toolchain-Desaster" gibt?

 

[DeltaMikeAir]

Habt ihr auch das Gefühl, dass die Industrie derzeit in einem "Toolchain-Desaster" gefangen ist

Nein, habe ich nicht.

sodass die Modernisierung der Entwicklungs-Flows eingebremst wird

Habe ich auch nicht

Falls ja, habt ihr das Gefühl dass es in den nächsten Jahren irgendeinen realistischen Ausbruch aus diesem "Toolchain-Desaster" gibt?

Naja, es werden immer mehr Anforderungen an die klassische SPS gestellt. Früher musste sie einfach steuern und regeln, ein Panel etwas visualisieren.
Es war sozusagen ein geschlossener Kosmos.
Heute sollen immer mehr Aufgaben übernommen werden, immer mehr Kommunikationsmöglichkeiten, integrierte Funktionen, safety, Fernwartung, OPC, OPC UA.....
Also wird es auch unumgänglich sein, regelmäßig die Software upzudaten / verbessern...

Was mit Step7 Classic übrigens auch schon so war ( Erschien 1995 ). Für diese Software ist vor ein paar Tagen erst ein Update erschienen.
Step7 V5.6 SP2 => Hotfix 5 verfügbar

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich sage jetzt nicht dass ich alles gut finde ( aber das war früher auch schon so, z.B. mit den Step7 Classic Anfängen, WinCC flexible..... ) aber:

welche aufgrund ihrer Komplexität häufig abstürzen

Bei mir läuft alles stabil ( V13 - 16 parallel, Logic Maschine Builder, Codesys, TwinCat... alles auf einer Win7 Installation )

und mit regelmäßigen Updates bereits existierende Projekte inkompatibel oder unbrauchbar machen.

Sie werden ja nicht inkompatibel oder unbrauchbar sondern sie können entweder direkt geöffnet werden oder müssen
hochmigriert werden, was ich schon oft gemacht habe ohne Probleme.

Das widerspricht allem, was ich früher über gute Software gelernt habe: Performance, Robustheit, Langzeit-Stabilität von File-Formaten etc...

Naja, wenn man viel möchte, dann wird das Ganze halt auch etwas größer, komplexer und umfangreicher....

 

[DeltaMikeAir]

Das es so ist, wie es ist betrifft meiner Meinung nach alle Bereiche, nicht nur Industrie.

Beispiel Excel. Ich habe in meinem Schrank noch Excel 5.0 Originaldisketten aus den 90érn. Das sind 10 Stück 1.44MB Installationsdisketten
für das komplette Excel 5.0. Wenn ich nun Excel 2020 runterlade, dann würde dies umgerechnet 570 Stück 1.44MB Disketten entsprechen.
Und Tabellenkalkulation können beide Versionen aber 2020 kann halt noch viel viel mehr zusätzlich zur Tabellenkalkulation.

Ich würde dies nicht als Desaster bezeichnen sondern als Fortschritt

 

[Heinileini]

Und Tabellenkalkulation können beide Versionen aber 2020 kann halt noch viel viel mehr zusätzlich zur Tabellenkalkulation.

Und "mein" Excel (ich arbeite noch mit 2010) glaubt sogar, es könne sich selbst reparieren! Aber er will gar nicht wissen, wie die Funktionalität nach der Reparatur aussehen soll.
Er repariert einfach drauf los, macht zunächst alle bedingten Formatierungen platt - nicht nur die, die er zuvor eigenmächtig dem OriginalZustand bis zur Unkenntlichkeit hinzugefügt hat.
Manchmal ist er dann mit seiner Reparatur schon zufrieden, manchmal aber erst, nachdem er ausserdem den kompletten VBA-Bereich eliminiert hat.
Da das heutzutage aber anscheinend "Stand der Technik" ist, wird sich wohl auch niemand mehr daran stören, wenn die IT-ler meinen, in den Variablen der OT-ler herumschreiben zu müssen, um endlich Ordnung in das SpaghettiGewusel zu bringen.
Das widerspricht allem, was ich früher über gute Software gelernt habe: Performance, Robustheit, Langzeit-Stabilität von File-Formaten etc..
Die PLCs werden anscheinend nicht mehr benötigt, um die Funktionalität der Anlage/Maschine zu gewährleisten, sondern nur noch, um die IT-ler mit Daten für ihre statistischen Auswertungen zu überschütten.
Abstürze von PLCs? Tägliche Updates der PLC-Software, um die Schlampigkeit des gestrigen Updates wieder halbwegs gerade zu bügeln? Das hat uns gerade noch gefehlt.

PS:
Warum die Vorbehalte gegen BlackBoxes? Einerseits nach Kapselung schreien und andererseits BlackBoxes verteufeln?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

Nach diesem provokanten Titel möchte ich mich zunächst selbst kurz vorstellen:

Mein Werdegang ist relativ untypisch für einen Software-Entwickler: Ich habe zuerst C/C++ gelernt, habe danach ein bisschen Erfahrung im industriellen Bereich gesammelt, bin dann aber aus dem industriellen Bereich "geflüchtet" und auf Frontend-Entwicklung mit TypeScript/React umgestiegen.


In dieser Zeit war ich schockiert darüber, welche Art von Software im Jahr 2020 in der Industrie eingesetzt wird: Nämlich monolithische Monsterprogramme, welche aufgrund ihrer Komplexität häufig abstürzen und mit regelmäßigen Updates bereits existierende Projekte inkompatibel oder unbrauchbar machen.
Das widerspricht allem, was ich früher über gute Software gelernt habe: Performance, Robustheit, Langzeit-Stabilität von File-Formaten etc...

Wer selbst im Glashaus sitzt ...

Gerade das ganze Thema rund um HTML5, Javascript, Node JS hat nun wirklich nichts mit Langzeit-Stabilität und Performance zu tun.
Warum brauch ich im Jahr 2020 immer noch verschiedene Browser auf meinem Rechner / Smartphone?
Warum kann ich alte Word-Dokumente aus den 90ern mit OpenOffice öffnen aber nicht mehr mit MS Word nicht?

Im Bereich Automatisierung sind wir nicht besser oder schlechter unterwegs als bei der restlichen IT

 

[JesperMP]

Hallo Felix. Ich habe engefangen deine Artikel zu lesen. Bis auf dies:
"This culture clash can be illustrated by comparing the skills of electricians (OT) with software engineers (IT). An industrial electrician does not only know how to build circuits and connect machinery. The electrician also knows how to program circuits via Programmable Logic Controllers (PLCs) or similar tools. However, the electrician does not know very much about how to build reusable and maintainable programs."Es ist einfach verleumend. Danach habe ich aufgehört weiter zu lesen. Jepp, du hast keine Ahnung.

 

[DeltaMikeAir]

.....Jepp, du hast keine Ahnung.

Ich muss sagen, ich habe mich bei der unten zitierten Aussage schon etwas gewundert, ob da aus Erfahrung gesprochen wird oder
einfach so etwas in den Raum geworfen wird was nicht den Tatsachen entspricht. Egal mit welcher SPS Software ( und ich arbeite mit vielen ),
bei mir ist noch nie ein Projekt unbrauchbar geworden, durch ein Update ( in > 20 Jahren ). Wenn etwas unbrauchbar wurde an laufenden Systemen
dann waren es zumindest in meinem Industriebereich die Windows Updates als Verursacher, was ja wieder der IT-Sparte zuzurechnen ist .

....und mit regelmäßigen Updates bereits existierende Projekte inkompatibel oder unbrauchbar machen....

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab mir jetzt mal die Zeit genommen und hab die Beiträge nochmal gelesen.
Nunja irgendwie hab ich den Eindruck, dass der Kollege noch nicht viele Projekte umgesetzt hat.
Es ist ganz klar, dass sauber definierte Schnittstellen das A und O sind.
Nicht erst bei I4.0 sondern eigentlich schon immer.
OPC UA ist kein Heilmittel. Was der Kollege nämlich vergisst ist, dass OPC UA erst zur Laufzeit zur Verfügung.
Ich habe es vielleicht beim Variablenmapping zwischen den Systemen leichter und beim Debugen, aber das war‘s schon.
Aber das funktioniert auch nicht viel besser oder schlechter mit Schnittstellen-DBs.

Naja jeder kann seine Meinung haben

 

[fkrc]

Ich sage jetzt nicht dass ich alles gut finde ( aber das war früher auch schon so, z.B. mit den Step7 Classic Anfängen, WinCC flexible..... ) aber:

Bei mir läuft alles stabil ( V13 - 16 parallel, Logic Maschine Builder, Codesys, TwinCat... alles auf einer Win7 Installation )

Sie werden ja nicht inkompatibel oder unbrauchbar sondern sie können entweder direkt geöffnet werden oder müssen
hochmigriert werden, was ich schon oft gemacht habe ohne Probleme.

Naja, wenn man viel möchte, dann wird das Ganze halt auch etwas größer, komplexer und umfangreicher....

Hier stellt sich natürlich die kritische Frage, wodurch der Zwang entsteht, V13-V16 parallel zu betreiben.
Eine mögliche Ursache sind die obskuren Binärformate der Projekte, welche kaum ein gutes Versions-Debugging zulassen.
Würden das File-Format stabiler sein, dann würde womöglich V16 für alle Projekte ausreichen.

Meiner Meinung ist das Problem weniger die Existenz von Migrations-Fehlern, sondern die Möglichkeit, Migrationsprobleme effizient debuggen zu können.
Wenn ich beispielsweise einen C-Compiler aufrüste, dann sehe ich jede einzelne Zeilennummer wo die Kompilierung fehlschlägt, und kann das Problem entsprechend lösen.
Wenn ich hingegen TIA aufrüste, dann sehe ich womöglich nur eine kryptische, nichtssagende Fehlermeldung.

 

[fkrc]

Ich hab mir jetzt mal die Zeit genommen und hab die Beiträge nochmal gelesen.
Nunja irgendwie hab ich den Eindruck, dass der Kollege noch nicht viele Projekte umgesetzt hat.
Es ist ganz klar, dass sauber definierte Schnittstellen das A und O sind.
Nicht erst bei I4.0 sondern eigentlich schon immer.
OPC UA ist kein Heilmittel. Was der Kollege nämlich vergisst ist, dass OPC UA erst zur Laufzeit zur Verfügung.
Ich habe es vielleicht beim Variablenmapping zwischen den Systemen leichter und beim Debugen, aber das war‘s schon.
Aber das funktioniert auch nicht viel besser oder schlechter mit Schnittstellen-DBs.

Ich stimme zu, OPC UA ist kein Allheilmittel. Ich habe OPC UA nur deshalb hervorgehoben, weil es aktuell eine der größten Initiativen in diesem Bereich ist.

Dass OPC UA erst zur Laufzeit zur Verfügung steht, dass würde ich nicht als in Stein gemeißelt sehen. Ja, bei derzeitigen Tools steht OPC UA vielleicht erst zur Laufzeit zur Verfügung. Ich versuche aber, bereits einen Schritt weiter zu denken, wie eine optimale Integration aussehen könnte (unabhängig davon, ob die derzeitigen Tools das können).

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie Blockmove schon geschrieben hat, fällt jemandem der sich schon länger mit der Materie in der Praxis befasst auf, dass du noch nicht viel Erfahrung in dem Bereich hat.

Das Feld der Automatisierung ist so weit gestreut, wenn du meinst den Stein der Weisen gefunden zu haben, dann passt das vielleicht gerade auf deinen Anwendungsfall in deiner Branche. Du befindest dich im Maschinenbau, dann kommt jemand aus der Pharmabranche und sagt, bei uns muss das so sein. Dann kommt jemand aus dem Kraftwerksbereich, da muss das so und so sein und so weiter.

Etwas nur mit Offline-Daten projektieren zu können ist das A und O. Nur dann kannst du etwas komplett vorbereiten, da die Inbetriebnahme an der Anlage möglichst kurz sein soll.

Ich glaube so alle 1-2 Jahre schlägt hier jemand auf mit 0 Posts, 0 Erfahrung in der Automatisierungstechnik, meint alles besser zu wissen, und er ist gerade dabei als 1-Mann Projekt eine komplette Automatisierungslösung aufzusetzen. Und nach 10 Posts ist Funkstille.

 

[DeltaMikeAir]

Da war doch erst kürzlich der Beitrag, vielleicht kann ihn jemand verlinken. Ich weiß nur noch das zig mal das Wort IDE und C++ fiel......

Kommt mit vom Inhalt auch irgendwie sehr ähnlich vor...

 

[rostiger Nagel]

Da war doch erst kürzlich der Beitrag, vielleicht kann ihn jemand verlinken. Ich weiß nur noch das zig mal das Wort IDE und C++ fiel......

Kommt mit vom Inhalt auch irgendwie sehr ähnlich vor...

Ihr Wunsch ist mir Befehl.

https://www.sps-forum.de/programmierstrategien/96002-codegenerierung-der-praxis.html?highlight=ide

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den meinte ich
https://www.sps-forum.de/sonstige-steuerungen/100360-sps-mit-ohne-editor-ide-programmieren.html?highlight=Ide

 

[fkrc]

Da das heutzutage aber anscheinend "Stand der Technik" ist, wird sich wohl auch niemand mehr daran stören, wenn die IT-ler meinen, in den Variablen der OT-ler herumschreiben zu müssen, um endlich Ordnung in das SpaghettiGewusel zu bringen.
Das widerspricht allem, was ich früher über gute Software gelernt habe: Performance, Robustheit, Langzeit-Stabilität von File-Formaten etc..
Die PLCs werden anscheinend nicht mehr benötigt, um die Funktionalität der Anlage/Maschine zu gewährleisten, sondern nur noch, um die IT-ler mit Daten für ihre statistischen Auswertungen zu überschütten.
Abstürze von PLCs? Tägliche Updates der PLC-Software, um die Schlampigkeit des gestrigen Updates wieder halbwegs gerade zu bügeln? Das hat uns gerade noch gefehlt.

PS:
Warum die Vorbehalte gegen BlackBoxes? Einerseits nach Kapselung schreien und andererseits BlackBoxes verteufeln?

Also jetzt wird es langsam bizarr
Natürlich soll man nicht auf jede Variable Schreibzugriff kriegen, aber wenn ein Schreibzugriff gebraucht wird, dann sollte das auf einfachste Art funktionieren:
- Eine zusätzliche Checkbox während der Programmierung der PLC (OT).
- Wenig bis gar keine Programmierung auf Seiten der IT (falls ein generischer Client verwendet wird).

Wenn hingegen ein Variablen-Zugriff einen sogenannten "Projekt-Import" auf Seiten der IT benötigt, dann frage ich mich, aus welchem Jahrhundert diese Lösung stammt
Zum Vergleich: Wenn ich eine private Website in ein internes Netzwerk stelle, dann brauche ich schließlich auch keinen sogenannten "Projekt-Import", um meine Website browsen zu können.

PS: Die Blackboxes werden dir wahrscheinlich genau so lange gefallen, bis irgendeine kryptische Fehlermeldung kommt, und die "Lösung" ist "Projekt neu aufsetzen" oder "TIA neu installieren". Es hat schon seinen Grund, warum Programmierer gerne mit text-basierten Formaten arbeiten und nicht mit kryptischen Binär-Dateien

 

[fkrc]

Wie Blockmove schon geschrieben hat, fällt jemandem der sich schon länger mit der Materie in der Praxis befasst auf, dass du noch nicht viel Erfahrung in dem Bereich hat.

Das Feld der Automatisierung ist so weit gestreut, wenn du meinst den Stein der Weisen gefunden zu haben, dann passt das vielleicht gerade auf deinen Anwendungsfall in deiner Branche. Du befindest dich im Maschinenbau, dann kommt jemand aus der Pharmabranche und sagt, bei uns muss das so sein. Dann kommt jemand aus dem Kraftwerksbereich, da muss das so und so sein und so weiter.

Etwas nur mit Offline-Daten projektieren zu können ist das A und O. Nur dann kannst du etwas komplett vorbereiten, da die Inbetriebnahme an der Anlage möglichst kurz sein soll.

Ich glaube so alle 1-2 Jahre schlägt hier jemand auf mit 0 Posts, 0 Erfahrung in der Automatisierungstechnik, meint alles besser zu wissen, und er ist gerade dabei als 1-Mann Projekt eine komplette Automatisierungslösung aufzusetzen. Und nach 10 Posts ist Funkstille.

Es gibt schon noch einen großen Unterschied zwischen "alles besser wissen" und "den Status Quo anzweifeln"
Wer glaubt, dass eh alles optimal funktioniert, der kann sich auch nie ernsthaft verbessern.
Als 1-Mann Projekt eine komplette Lösung aufzusetzen ist eher unrealistisch, aber das hat ganz andere Gründe als die Themen in diesem Thread.

Sinnvoller wäre es, einen Blick auf die Stärken und Schwächen der derzeitigen Tools zu werfen, anstatt jede Kritik grundsätzlich zu vernichten:

- Projektierung mit Offline-Daten kann in manchen Projekten sehr wichtig sein, und dann würde auch ein Online-Browsing von PLC-Variablen wahrscheinlich wenig helfen.
- Versions-Kontrolle und Code-Reuse mittels Libraries sind aber eher eine Schwäche von vielen PLC-Tools, wenn man es mit Standards aus der IT-Welt vergleicht.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, habe ich nicht.

Habe ich auch nicht

Ich vermute, dass sich die erfahrenen Experten mit diesen Problemen leichter tun, weil sie die Workarounds und Probleme der Tools bereits gut genug gelernt haben.
Für einen Experten ist es vielleicht kein Problem, drei verschiedene TIA-Versionen parallel zu betreiben.
Für einen Anfänger hingegen können drei verschiedene TIA-Versionen eine große Abschreckung sein.
Jetzt denken die Experten vielleicht: "Ist mir egal, ich kenne mich gut genug aus mit den Tools."
Trotzdem halte ich es für ein Problem, wenn für solche "trivialen" Probleme wie Versions-Verwaltung, Code-Sharing oder Aufrüstungen regelmäßig Expertenwissen benötigt wird.

Nein, habe ich nicht.
Naja, es werden immer mehr Anforderungen an die klassische SPS gestellt. Früher musste sie einfach steuern und regeln, ein Panel etwas visualisieren.
Es war sozusagen ein geschlossener Kosmos.
Heute sollen immer mehr Aufgaben übernommen werden, immer mehr Kommunikationsmöglichkeiten, integrierte Funktionen, safety, Fernwartung, OPC, OPC UA.....
Also wird es auch unumgänglich sein, regelmäßig die Software upzudaten / verbessern...

Genau das ist der Sinn und Zweck dieses Threads.
Die derzeitigen Tools waren vielleicht vor 15 Jahren gut genug, aber sind es jetzt möglicherweise nicht mehr.

Was mit Step7 Classic übrigens auch schon so war ( Erschien 1995 ). Für diese Software ist vor ein paar Tagen erst ein Update erschienen.
Step7 V5.6 SP2 => Hotfix 5 verfügbar

Ich kann mir vorstellen, dass es sogar mit Step7 Classic immer noch hocheffiziente Programmierer gibt, welche Projekte in Serie abliefern.
Trotzdem halte ich solche Legacy-Systeme nicht für zukunftsfähig, und nicht für moderne Anforderungen geeignet.

 

[Ralle]

Aber man muß schon anmerken:

Das Versions-Chaos, welches Siemens gerade stiftet, V10.5-V17, jedes Jahr eine neue Beta (mehr ist das nicht, was die jedesmal veröffentlichen), selbst Upd-Pakete, die nicht mit dem vorherigen Upd kompatibel sind, das ist übel, schlechtester Stil und wird uns noch mind. 20 Jahre verfolgen. Die eine Software paßt nicht zur alten Firmware, die Hardware läßt sich nicht auf die neue Firmware hochrüsten. Wer das gut findet ....

Das „alte“ Step7 war in dieser Hinsicht TIA um Längen voraus, selbst Step5 war da besser. Armes Siemens, von Stümpern und BWL-ern übernommen [emoji1][emoji99]

Wartet ab...


Gesendet von mir mit Tapatalk

 

[fkrc]

Wer selbst im Glashaus sitzt ...

Gerade das ganze Thema rund um HTML5, Javascript, Node JS hat nun wirklich nichts mit Langzeit-Stabilität und Performance zu tun.
Warum brauch ich im Jahr 2020 immer noch verschiedene Browser auf meinem Rechner / Smartphone?
Warum kann ich alte Word-Dokumente aus den 90ern mit OpenOffice öffnen aber nicht mehr mit MS Word nicht?

Word ist vielleicht ein schlechtes Beispiel; ich würde den Vergleich eher mit klassischen Programmiersprachen ziehen
Zum Beispiel JavaScript:
JavaScript ist nicht unbedingt stabil oder performant, aber es ist vergleichsweise einfach migrierbar, weil der Source-Code transformiert werden kann (händisch oder automatisch).
Solche Code-Transformationen sind mit kryptischen Binär-Files in der PLC-Welt eher schwer möglich.

Im Bereich Automatisierung sind wir nicht besser oder schlechter unterwegs als bei der restlichen IT

In manchen Bereichen ja, in anderen Bereichen nein.
In den Bereichen "Versionskontrolle" und "Code-Sharing" ist die IT vermutlich deutlich besser unterwegs.
Generell glaube ich, dass "Versionskontrolle" und "Code-Sharing" von vielen unterschätzt werden.
Man denkt sich: "Was interessiert mich dieses IT-Zeug, ich will nur mein eigenes Projekt fertig projektieren".
Das zugrunde liegende Problem ist aber, dass ohne Versionskontrolle und Code-Sharing der Aufbau und Erhalt von Wissen eingebremst wird, selbst wenn es in einzelnen Projekten vielleicht nicht direkt spürbar ist.