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

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Sorry für die Aussage, das trifft natürlich nicht auf alle Elektriker zu, habe den Satz deshalb weggelöscht.
Tendenziell ist es so, dass Software-Entwickler eher Erfahrung mit "Code-Reuse" haben, aber das bedeutet natürlich nicht, dass es andere Berufe nicht genauso können.

 

[Thomas_v2.1]

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

Die Probleme gerade beim TIA-Portal wurden hier in hunderten Posts angesprochen. Im Grunde ist auch verlorene Liebesmüh, da sich Siemens nicht mal der einfachsten Probleme annimmt. Und du wirst genauso wenig zur Lösung beitragen können. Ich weiß auch nicht wo deine Intention liegt, außer vielleicht Klicks auf dein Blog zu generieren.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ralle du hast vollkommen recht, dass wir mit TIA heftige Versionsprobleme haben.

Nur das ist bei der PC-Programmierung keinen Pfennig besser.
Wieviele Versionen vom .net Framework gibt es?
Wieviele Versionen von Versionen von Microsoft Visual C++ 20xx Redistributable hast du parallel drauf?
Das dann auch noch in 32 und 64Bit.

Ich hab vor einiger Zeit mal versucht ein Visualbasic 6 Projekt von 2003 zu migrieren.
Die Migration eines MP370 ist dagegen ein Klacks.

Den nächste IT'ler, der hier irgendwas von langfristig erzählt, stecke ich eigenhändig in einen Fluxkompensator (https://de.wikipedia.org/wiki/Zur%C3%BCck_in_die_Zukunft#Der_Fluxkompensator) und schicke ihn 20 Jahre in die Zukunft.

 

[fkrc]

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

Excel hat vielleicht sogar sehr viele Gemeinsamkeiten mit manchen PLC-Tools:

- Es ist groß und monolithisch (manche behaupten aufgebläht)
- Es arbeitet mit "kryptischen Binärfiles" (obwohl es im Hintergrund XML verwendet)
- Code-Reuse und Versionskontrolle sind nur mühselig möglich (aufgrund von Binär-Files und einem mangelnden Package-Manager)
- Es ist für viele Zwecke sehr mächtig, aber stößt trotzdem schnell auf Komplexitäts-Grenzen

Ich möchte auf keinen Fall die Existenz von Excel anzweifeln.
Trotzdem bezweifle ich, dass diese Ansätze der richtige Weg für zukünftige PLC-Tools sind.

 

[Blockmove]

Tendenziell ist es so, dass Software-Entwickler eher Erfahrung mit "Code-Reuse" haben, aber das bedeutet natürlich nicht, dass es andere Berufe nicht genauso können.

Schlichtweg falsch. Glaubst du, dass wir SPSler jedesmal den Code neu schreiben?
Ich behaupte, dass bei uns die Wiederverwendung sogar höher ist.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ralle du hast vollkommen recht, dass wir mit TIA heftige Versionsprobleme haben.

Nur das ist bei der PC-Programmierung keinen Pfennig besser.
Wieviele Versionen vom .net Framework gibt es?
Wieviele Versionen von Versionen von Microsoft Visual C++ 20xx Redistributable hast du parallel drauf?
Das dann auch noch in 32 und 64Bit.

Ich hab vor einiger Zeit mal versucht ein Visualbasic 6 Projekt von 2003 zu migrieren.
Die Migration eines MP370 ist dagegen ein Klacks.

Den nächste IT'ler, der hier irgendwas von langfristig erzählt, stecke ich eigenhändig in einen Fluxkompensator (https://de.wikipedia.org/wiki/Zurück_in_die_Zukunft#Der_Fluxkompensator) und schicke ihn 20 Jahre in die Zukunft.

Mir geht es weniger um die Existenz von Migrations-Problemen, sondern um die Schwierigkeit, Migrations-Probleme zu debuggen.
.NET/C# ist ein guter Vergleich:

Ein großes C#-Projekt hochzurüsten ist vielleicht viel zu aufwendig und teuer.
Dennoch ist es möglich, zumindest selektiven C#-Code aufzurüsten, weil mir der Compiler Line-by-line Fehlermeldung anzeigt (im Gegensatz zu kryptischen Error-Messages von TIA oder sonstigen Tools).
Ähnliches gilt auch für die Aufrüstung von 32-Bit-C-Code auf 64-Bit-C-Code.

 

[fkrc]

Schlichtweg falsch. Glaubst du, dass wir SPSler jedesmal den Code neu schreiben?
Ich behaupte, dass bei uns die Wiederverwendung sogar höher ist.

Ich glaube sehr wohl, dass eine große Menge an Bausteinen kopiert werden.
Allerdings habe ich Zweifel, ob dabei gute Package-Manager zum Einsatz kommen.
Es gibt nämlich einen großen Unterschied zwischen "Kopieren" und "gemanagten Packages".
In der IT-Welt gibt es "npm" mit hunderttausenden Packages, und jeder kann ein Package in 5 Minuten publishen oder updaten, egal ob firmenintern oder Open-Source.
Wenn ich hingegen ein Package kopiere, dann habe ich keinen "nachhaltigen" Code-Reuse, sondern nur genauso lange, bis das kopierte Package wieder veraltet und obsolet ist.

 

[Blockmove]

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.

Achja?
Die S7-Steuerung in meinem vorletzten Retrofit-Projekt war Baujahr 1998 ... Migration problemlos.

Das Thema mit den Files hast du bei der PC-Entwicklung genauso.
Was hilft dir das schönste XML-File, wenn die dazugehörige IDE nicht mehr läuft?
Erzähl mir nicht, dass du dann Visualstudio Formulare mit zig Elementen an Hand des XML-Files in HTML5 nachbauen kannst.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Achja?
Die S7-Steuerung in meinem vorletzten Retrofit-Projekt war Baujahr 1998 ... Migration problemlos.

Das würde ich fast schon als "Lucky-Strike-Migration" bezeichnen
Bei manchen PLC-Tools habe ich das Gefühl, dass Migrationen auf gut Glück funktionieren oder nicht funktionieren (obwohl es natürlich technische Gründe gibt, die aber nicht immer dokumentiert sind).
Wenn ich hingegen soetwas wie C#-Code migriere (Beispiel von vorhin), dann gibt es eine klare Anleitung, welche Änderungen zu tun sind (nämlich aufgrund von C#-Compiler-Errors für einzelne Lines).

Achja?
Das Thema mit den Files hast du bei der PC-Entwicklung genauso.
Was hilft dir das schönste XML-File, wenn die dazugehörige IDE nicht mehr läuft?
Erzähl mir nicht, dass du dann Visualstudio Formulare mit zig Elementen an Hand des XML-Files in HTML5 nachbauen kannst.

User-Interfaces mit XML würde ich nicht mehr als "Best Practice" bezeichnen, die Industrie entfernt sich eher von XML-Files.
Moderne Frameworks wie React, SwiftUI oder Flutter verwenden nur mehr Code für die UI-Programmierung.

 

[Blockmove]

Ich glaube sehr wohl, dass eine große Menge an Bausteinen kopiert werden.
Allerdings habe ich Zweifel, ob dabei gute Package-Manager zum Einsatz kommen.
Es gibt nämlich einen großen Unterschied zwischen "Kopieren" und "gemanagten Packages".
In der IT-Welt gibt es "npm" mit hunderttausenden Packages, und jeder kann ein Package in 5 Minuten publishen oder updaten, egal ob firmenintern oder Open-Source.
Wenn ich hingegen ein Package kopiere, dann habe ich keinen "nachhaltigen" Code-Reuse, sondern nur genauso lange, bis das kopierte Package wieder veraltet und obsolet ist.

NPM tolles Beispiel ... Ich bin ein Fan von Node RED und auch ioBroker.
Und ich liebe "gemanagte" NPMs.
Glücklicherweise gibt es Container mit dem einfachen Weg zurück
Deine NPMs sind nur so gut wie der Entwickler die Doku dazu pflegt.

 

[fkrc]

NPM tolles Beispiel ... Ich bin ein Fan von Node RED und auch ioBroker.
Und ich liebe "gemanagte" NPMs.
Glücklicherweise gibt es Container mit dem einfachen Weg zurück
Deine NPMs sind nur so gut wie der Entwickler die Doku dazu pflegt.

Es ist mir bewusst, dass viele npm-Packages eine Schrott-Qualität haben, und das liegt auch irgendwie an der Natur der Sache ^^

Der springende Punkt ist aber:
Wer will, der kann auf sehr einfache Art ein hochqualitatives npm-Package publishen.
Das ist vor allem für Unternehmen relevant, welche eine große Zahl von "ähnlichen Projekten" mit "ähnlichem Code" betreuen.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

NPM tolles Beispiel ... Ich bin ein Fan von Node RED und auch ioBroker.
Und ich liebe "gemanagte" NPMs.
Glücklicherweise gibt es Container mit dem einfachen Weg zurück
Deine NPMs sind nur so gut wie der Entwickler die Doku dazu pflegt.

Und dort fängt nämlich das wirkliche Toolchain-Desaster an. In den meisten dieser Projekte stecken so viele Abhängigkeiten von zig anderen Bibliotheken, wo es teilweise auch nur einen Maintainer gibt. Und wenn dieser kein Bock mehr hat und du einer der einzigen warst die das verwendet haben, dann kannst du dich darum auch noch kümmern.

Ich habe auch noch nicht verstanden worauf er sich bezieht. Auf die Engineering Software wie TIA-Portal? Das ist mir herzlich egal was da für Abhängigkeiten intern herrschen, ich kaufe die Software und sie muss laufen. Ändern kann ich daran eh nichts, und andere Hersteller sind auch nicht besser.

 

[fkrc]

Und dort fängt nämlich das wirkliche Toolchain-Desaster an. In den meisten dieser Projekte stecken so viele Abhängigkeiten von zig anderen Bibliotheken, wo es teilweise auch nur einen Maintainer gibt. Und wenn dieser kein Bock mehr hat und du einer der einzigen warst die das verwendet haben, dann kannst du dich darum auch noch kümmern.

Ich habe auch noch nicht verstanden worauf er sich bezieht. Auf die Engineering Software wie TIA-Portal? Das ist mir herzlich egal was da für Abhängigkeiten intern herrschen, ich kaufe die Software und sie muss laufen. Ändern kann ich daran eh nichts, und andere Hersteller sind auch nicht besser.

Ich stimme vollkommen zu, dass eine übertrieben hohe Zahl an Dependencies ein großes Problem sein kann, vor allem dann wenn die Dependencies schlecht gewartet sind.

Dennoch kann es nicht der Weisheit letzter Schluss sein, dass Siemens oder ein anderes Unternehmen der *einzige* Maintainer des Package-Ecosystems ist.
Erstens kann es potentiell lange dauern, bis Siemens auf eine neue Kundenforderung überhaupt reagiert.
Und zweitens kann kein Konzern der Welt die kollektive Intelligenz der User-Community im Alleingang übertreffen, weshalb solche offenen Package-Ecosystems eine riesige Stärkung für eine Software-Plattform sein können.

 

[Thomas_v2.1]

Dennoch kann es nicht der Weisheit letzter Schluss sein, dass Siemens oder ein anderes Unternehmen der *einzige* Maintainer des Package-Ecosystems ist.
Erstens kann es potentiell lange dauern, bis Siemens auf eine neue Kundenforderung überhaupt reagiert.
Und zweitens kann kein Konzern der Welt die kollektive Intelligenz der User-Community im Alleingang übertreffen, weshalb solche offenen Package-Ecosystems eine riesige Stärkung für eine Software-Plattform sein können.

Und du meinst, der Automatisierungstechniker der seine Projekte plant, programmiert, dokumentiert, in Betrieb nimmt, hat nebenher noch die Zeit sich um so etwas zu kümmern? Bei uns sind das beispielsweise zu 95% einmalige Anwendungen, die zudem oftmals in bestehende Anlagen integriert oder erweitert werden, und auf bestehende Codebasis oder Visualisierungen aufsetzen. Das mit deinem Paket-Manager funktioniert dann nur bei großen Maschinen- und Anlagenbauern, wo es so etwas auch in vielen Fällen gibt. Wie leben ja nicht völlig hinter dem Mond.

Wie schlecht Community-Projekte in dieser Branche funktionieren zeigt sich z.B. an Oscat, was eigentlich überhaupt der einzige Versuch in diese Richtung war, aber mittlerweile komplett eingeschlafen zu sein scheint. Das werden die meisten auch in ihrer Freizeit betrieben haben, weil die Arbeitgeber hier nicht bereit sind deine Arbeitszeit zum Nutzen anderer herzugeben. Das sieht bei der Anwendungs- oder Webprogrammierung von Kosten/Nutzen-Verhältnis eben anders aus, weil du dort sehr viel mehr auf die Arbeit anderer aufsetzt.

 

[fkrc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und du meinst, der Automatisierungstechniker der seine Projekte plant, programmiert, dokumentiert, in Betrieb nimmt, hat nebenher noch die Zeit sich um so etwas zu kümmern? Bei uns sind das beispielsweise zu 95% einmalige Anwendungen, die zudem oftmals in bestehende Anlagen integriert oder erweitert werden, und auf bestehende Codebasis oder Visualisierungen aufsetzen.

Genau für solche Leute könnte es von Vorteil sein, wenn es fertige Packages gibt, die "einfach funktionieren".
Es wird selbstverständlich nicht jeder Automatisierungstechniker irgendwelche Packages publishen, aber es gibt sehr wohl Unternehmen, für welche Packages intern und/oder extern interessant sein könnten.

Das mit deinem Paket-Manager funktioniert dann nur bei großen Maschinen- und Anlagenbauern, wo es so etwas auch in vielen Fällen gibt. Wie leben ja nicht völlig hinter dem Mond.

Eine Kernfrage ist hier, wie "groß" ein Maschinen- und Anlagebauer sein muss, damit die Kostenrechnung für Packages aufgeht.
Je schlechter die Tools sind, desto schlechter fällt die Kostenrechnung aus.
Derzeit sieht es danach aus, dass die Tools eher schlecht sind; mir ist kein SPS-Package-Manager bekannt, welcher auch nur annähernd in Richtung npm funktioniert.

Wie schlecht Community-Projekte in dieser Branche funktionieren zeigt sich z.B. an Oscat, was eigentlich überhaupt der einzige Versuch in diese Richtung war, aber mittlerweile komplett eingeschlafen zu sein scheint. Das werden die meisten auch in ihrer Freizeit betrieben haben, weil die Arbeitgeber hier nicht bereit sind deine Arbeitszeit zum Nutzen anderer herzugeben. Das sieht bei der Anwendungs- oder Webprogrammierung von Kosten/Nutzen-Verhältnis eben anders aus, weil du dort sehr viel mehr auf die Arbeit anderer aufsetzt.

Eine pure Freizeit-Open-Source-Community wird in diesem Bereich zu wenig Rückhalt haben, um bestehen zu können. Deshalb wird es wahrscheinlich zumindest einen größeren Hersteller brauchen, der hinter so einem Projekt steht.
Ich sehe es so, dass viele kleinere Lieferanten von Automatisierungs-Technik davon profitieren könnten, wenn sie einfache Packages für ihre an Kunden ausgelieferte Hardware publishen könnten.
Dennoch ist es unklar, wer dazu fähig ist, ein solches System am Leben zu halten.
Sogar npm war meines Wissens nach bis zuletzt im Verlustbereich, bevor sie von GitHub/Microsoft aufgekauft worden sind.

 

[Blockmove]

Beinahe jeder Hersteller von intelligenten Sensoren oder Aktoren hat EPlan Makros und SPS-Bausteine zum Download.
Die Qualität ist wie bei den NPMs. Mal gut, mal weniger gut.
Diese binde ich in mein Projekt ein und gut is.
Entdecke ich da einen Fehler, dann melde ich den.
Hier kann ich mir vorstellen, dass ein Repository Vorteile hätte.
Für unsere internen Standard-Bausteine nutzen wir Bibliotheken.
Und da gibt es sowohl bei Siemens als auch bei Codesys Versionierung.

Felix, ich denke du siehst, dass Projekte im Bereich Anlagen- und Maschinenbau anders funktionieren.
Vieles aus der PC-Programmierung lässt sich nicht übertragen bzw. sind die Vorteile gering.
Beim Thema Schnittstellen hast du recht. Die Protokolle sind veraltet und unsicher.
Hier ist OPC UA und MQTT ein klarer Fortschritt. Aber auch hier habe ich keine riesen Vorteile.
Für die Offline-Programmierung brauche ich die klassische Schnittstellenbeschreibung.

Was mir z.B. wirklich was bringen würde, wäre eine bessere und einfachere Verbindung von z.B. 3D-CAD, Elektro-CAD, SPS-Software und Visualisierung. Hier steckt deutlich mehr Potential als in all den von dir angesprochenen Punkten.

Gruß
Blockmove

 

[ducati]

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

Reden wir jetzt hier eigentlich davon, dass TIA Scheisse ist (ja) oder alle SPS-Programmierer Scheisse sind (nein).

Glaub hier wird grad das TIA-Debakel verallgemeinert...

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss fkrc mal beistehen.

Die Automatisierungswelt ist was das Engineering betrifft grausam in ihrer Welt gefangen.

Echte Versionskontrolle bei Siemens inkl. Hardware und HMI Änderung?
Da gibt es null Möglichkeiten.
Hat mal jemand mit PCS7 V9 und CMT/EMT gearbeitet?
Sündhaft teuer und man kann eigentlich nichts nachvollziehen.

Und ich habe noch nie eine Software gesehen in der man in Listen so langsam Scrollt wie bei Siemens...
Verteiltes Zusammenarbeiten an einem Projekt? Ja da könnte man den Siemens Hauseigenen Multiserver verwenden... *hust*

Aber es gibt auch andere: Festo und Beckhoff zum Beispiel die alles in offenen Formaten speichern und man so die Möglichkeit hat eine richtige Versionsverwaltung aufzubauen.

Ich als "Junger" Programmierer ärgere mich praktisch pausenlos über Siemens und ich habe noch etliche Jahre Berufsleben vor mir.

 

[ducati]

Ich muss fkrc mal beistehen.

Die Automatisierungswelt ist was das Engineering betrifft grausam in ihrer Welt gefangen.

Echte Versionskontrolle bei Siemens inkl. Hardware und HMI Änderung?
Da gibt es null Möglichkeiten.
Hat mal jemand mit PCS7 V9 und CMT/EMT gearbeitet?
Sündhaft teuer und man kann eigentlich nichts nachvollziehen.

Und ich habe noch nie eine Software gesehen in der man in Listen so langsam Scrollt wie bei Siemens...
Verteiltes Zusammenarbeiten an einem Projekt? Ja da könnte man den Siemens Hauseigenen Multiserver verwenden... *hust*

Aber es gibt auch andere: Festo und Beckhoff zum Beispiel die alles in offenen Formaten speichern und man so die Möglichkeit hat eine richtige Versionsverwaltung aufzubauen.

Ich als "Junger" Programmierer ärgere mich praktisch pausenlos über Siemens und ich habe noch etliche Jahre Berufsleben vor mir.

wie ich eben schon geschrieben hab, gehts hier doch nicht darum, dass TIA im speziellen Scheisse ist? Oder doch? Dann könnt Ihr aber auch im "TIA Frust" weiter diskutieren

 

[fkrc]

Beinahe jeder Hersteller von intelligenten Sensoren oder Aktoren hat EPlan Makros und SPS-Bausteine zum Download.
Die Qualität ist wie bei den NPMs. Mal gut, mal weniger gut.
Diese binde ich in mein Projekt ein und gut is.
Entdecke ich da einen Fehler, dann melde ich den.
Hier kann ich mir vorstellen, dass ein Repository Vorteile hätte.
Für unsere internen Standard-Bausteine nutzen wir Bibliotheken.
Und da gibt es sowohl bei Siemens als auch bei Codesys Versionierung.

Felix, ich denke du siehst, dass Projekte im Bereich Anlagen- und Maschinenbau anders funktionieren.
Vieles aus der PC-Programmierung lässt sich nicht übertragen bzw. sind die Vorteile gering.
Beim Thema Schnittstellen hast du recht. Die Protokolle sind veraltet und unsicher.
Hier ist OPC UA und MQTT ein klarer Fortschritt. Aber auch hier habe ich keine riesen Vorteile.
Für die Offline-Programmierung brauche ich die klassische Schnittstellenbeschreibung.

Was mir z.B. wirklich was bringen würde, wäre eine bessere und einfachere Verbindung von z.B. 3D-CAD, Elektro-CAD, SPS-Software und Visualisierung. Hier steckt deutlich mehr Potential als in all den von dir angesprochenen Punkten.

Gruß
Blockmove

Ich stimme zu, dass die Prioritäten im Anlagen- und Maschinenbau wesentlich anders sind, aber ich glaube nicht, dass die Ziele wesentlich anders sind.
Mit einem Package-Manager möchte ich folgendes erreichen:

- Schnelle Einbindung von Packages, idealerweise mit einem einzigen Kommando.
- Ein Versions-Locking, damit sich die exakt gleichen Packages auch in 10 Jahren noch bauen lassen (im Extremfall).
- Schmerzfreie Auslieferung von Updates, idealerweise mit einem einzigen Kommando.
- Einfaches Publishen von eigenen Packages.

Für mich ist ein Package-Manager quasi die "erweiterte Versionskontrolle". Während Git meinen eigenen Code versioniert, versioniert ein Package-Manager ein ganzes Software-Ecosystem.
Man kann ruhig eingestehen, dass das in der PLC-Welt nicht wirklich gut gelöst ist (weder die Versionierung von Einzelprojekten, noch die Versionierung des Package-Ecosystems).

Es ist zwar gut und schön, dass manche Hersteller Bausteine zum Download zur Verfügung stellen, aber manuelle Baustein-Downloads über Websites sind schon seit Jahren nicht mehr State-of-the-art.

Die JavaScript-Kritiker werden vielleicht lachen, aber ich habe 5 Jahre alte npm-Packages gesehen, bei denen ein "npm install/build/test" immer noch out of the box funktioniert. Und zwar deshalb, weil die exakten Versionen der Dependencies hardgelockt sind (und zwar jedes einzelne Byte mit Hilfe von einem kryptografisch sicheren SHA256-Hash).

Bezüglich Visualisierung/3D-CAD etc. kann ich nicht viel sagen, weil das außerhalb meiner Expertise liegt.