Frage zu Industrie 4.0 und IoT

[Peter(TOO)]

Hallo,

Dann ist es umso erstaunlicher, dass Du wirklich glaubst es würde sich durch Industrie 4.0 nichts für Entwickler ändern ...

Es ändert sich, wie schon geschrieben, nichts grundsätzlich für einen Entwickler.

Wo sich etwas ändern muss, ist in den Ebenen über dem Entwickler!

Bei MS, in der Zeit als es von MS noch gar keine Updates gab, war es so, dass Billy der Überzeugung war, dass nur ganz junge Entwickler neue Ideen haben. Also wurden die meisten direkt ab UNI, oder sogar vor dem Abschluss, bei MS eingestellt.
Weiterhin hat Billy das Datum für die Veröffentlichung z.B. einer neuen Windows-Version festgelegt und dieser Termin musste eingehalten werden. Dabei war es egal ob der Entwickler noch eine Bugliste mit 100ten bekannten Bugs hatte oder nicht. Das Din musste zum Termin raus!

Vieles waren ganz doofe Anfänger-Fehler!
z.B. SASSER. Das Problem lag in der Automatisierungs-Schnittstelle. Per Definition wurden nur Meldungen mit maximal 4kB Grösse verwendet. Also nahm man das Datenpaket von der Ethernet-Schnittstelle und kopierte es in einen 4kB Buffer. Dabei wurde aber vergessen, dass Ethernet Pakete bis zu 64kB übertragen kann und hat die Paketgrösse von der Ethernet-Schnittstelle übernommen, aber nicht auf 4kB geprüft! Somit konnte man rund 60kB hinter den Buffer mit eigenen Daten, bzw. Code, überschreiben. Da diese Schnittstelle natürlich standardmässig freigeschaltet war, genügte es, Windows zu installieren und den PC mit dem Netzwerk zu verbinden.
Durch SASSER kam wenigstens MS so weit unter Druck, dass seither regelmässig Updates von MS ausgeliefert werden. Vorher war die Antwort auf Bugmeldungen: "Kaufen sie die neueste Version!". Wobei nicht garantiert wurde, dass der Bug da behoben ist.
Bei Win-95 gab es 5 verschiedene Versionen (95, 95A bis 95C, 95B gab es in zwei Versionen). Allerdings wurde dies nicht nach Aussen wirklich kommuniziert, kaufen konnte man nur Windows-95, was in der Schachtel war, war nicht wirklich ersichtlich.

Der Active-Desktop war auch so eine "geniale Idee". Dabei hat man über den ganzen Desktop noch eine HTML-Schicht gelegt, war eigentlich ein durchsichtiges Fenster des IE. Um Dinge automatisieren zu können, hat man dann HTML einfach erweitert, sodass man auch vollen Zugriff auf die Festplatten hatte und Programme starten konnte. Leider war das dann ALLES auch über Web-Seiten möglich!

Ähnliches geschah auch mit dem lizensierten Java. Die MS-Variante wurde so erweitert, bis die Sicherheit ganz im Keller war und MS die Lizenz verloren hat.

Windows NT sollte der damals sicherste Kernel werden, dazu hat man einen Entwickler von auswärts geholt. Eigentlich wurde dieses Ziel auch erreicht, bis dann die MS-Programmierer direkte Zugriffe auf den Kernel gemacht haben und somit die Sicherheit umgangen wurde. Der extra geholte Entwickler warf daraufhin das Handtuch und verliess MS.

Das Problem ist, dass heute die Entwicklung nichts kosten darf.
Also macht das möglichst ein Praktikant, welcher keine Ahnung hat. Und wenn es in etwa das macht, was es soll, wird es freigegeben. Irgendwelche Tests würden zusätzliche Kosten verursachen und vor allem Zeit beanspruchen. So kommt es halt, dass der ganze PC bei einem Tippfehler abstürzt.
Stichwort: Bananaware, das Produkt reift beim Kunden.

Vor allem die Amis schaffen es bis heute nicht, mit Umlauten umzugehen. Teilweise klemmt es schon auf der Webseite. Teilweise stimmt alles auf der Webseite, aber wenn ich Post oder eMail bekomme ...
(Zum Glück habe ich nur einen Umlaut im Nachnamen)

Die Jeep-Geschichte funktionierte über die Bluetooth-Schnittstelle der Reifensensoren. Für mich ist das ein Anfängerfehler im Konzept, wenn man über diese Schnittstelle vollen Zugriff auf den CAN-Bus und somit auf alles im Fahrzeug erhält. Ein kleines Filter, welches nur die bekannten Meldungen der Reifensensoren weiterleitet, hätte da genügt! Im Prinzip kann ein defekter Reifensensor, welcher zufällige Daten versendet, die ganze Kiste lahmlegen oder auch Vollgas geben!

Jeder Entwickler macht seine Fehler, das ist normal. Viele dieser Fehler macht man aber nur einmal im Berufsleben, dann weiss man es, das nennt man Erfahrung. Ein weiterer Punkt ist noch, ob so ein Fehler in die Produktion geht oder schon vorher, z.B. durch Tests, erkannt wird.

Für einen guten Entwickler ändert sich nichts grundlegendes!
Manche müssen lernen, nicht nur an Funktion ihres Produkts zu denken, sondern auch ein Augenmerk auf das Fehlverhalten zu werfen.
Zudem muss er Zeit für Tests einplanen.
Grundsätzlich müssen die Prozesse dahin geändert werden, dass, nicht nur auf dem Papier, mehr getestet und geprüft wird und man sich nicht einfach auf die Anderen verlässt.

Meine Erfahrung mit ISO 900x war anfänglich, dass die Qualität schlechter wurde, obwohl ISO eigentlich eine Verbesserung bringen sollte.
Aus meiner Sicht war hier das Problem, dass beim Hersteller eine Ausgangs- und beim Empfänger eine Eingangskontrolle vorgeschrieben wurde. Da dachte sich jeder, dass er sich das sparen kann, weil ja der Andere schon kontrolliert, schlussendlich wurde dann gar nicht kontrolliert

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo,

Für vernetzte Anwendungen wird das natürlich schon zur Herausforderung. Die langen Laufzeiten industrieller Anwendungen führen dazu, dass man die verwendeten Technologien mit Sorgfalt wählen muss. Wir haben Kunden, die unsere Industrie-PC Anwendungen über 10 bis 15 Jahre ohne Update betreiben. Nicht weil wir keine kompatiblen Updates anbieten würden, sondern weil sie das grundsätzlich nicht tun.

Das kenne ich auch so!

In den 80/90er Jahren, wollten einige Auftraggeber, dass ich fertige Interface-Steckkarten verwende. Da war dann das Problem, dass wenn der PC ausgefallen ist, die neuen keine ISA oder EISA Steckplätze mehr hatten. Kompatible Steckkarten, mit den neuen Bussen, gab es dann auch nicht mehr. Also musste man die Software komplett neu erstellen und die Kostenersparnis war dahin ...

Selbst entwickelte Hardware konnte man reparieren.

Später habe ich dann eigene Hardware nur noch über serielle Schnittstellen an den PC angebunden, dieses Konzept funktioniert heute noch

Das mit den Updates ist auch immer so eine Sache.
Wenn es keine grundlegenden Fehler gibt und keine benötigten neuen Funktionen geboten werden, macht ein Update keine Not.

Ich habe das bei Freunden erlebt, welche immer der neuesten Version nachgerannt sind!
Die waren eigentlich immer nur am lernen und sind laufend über neue Bugs gestolpert und kamen somit gar nie richtig dazu produktiv zu arbeiten.
Wenn man länger mit einer Version arbeitet, kennt man auch die Bugs und wie man sie umgehen kann, erlebt also weniger Überraschungen, welche einem beim Arbeiten unerwartet aufhalten.

MfG Peter(TOO)

[SPSAmeise]

Von welchen Entwicklern reden wir denn jetzt?
Die meisten sind spezialisiert auf Web, Datenbanken oder sonst irgendwas.
Es gibt aber nur wenige, die sich mit komplexen Backends und Security Layern und iot Architektur auskennen.
Von DLTS Layern auf Bankenniveau mal ganz zu schweigen.

[Peter(TOO)]

Hallo SPS-Meise,

Grundsätzlich würde ein Zitat oder eine Anrede, das verfolgen hier vereinfachen. Bei deinen Antworten weiss man nie so genau auf was du geantwortet hast.

Von welchen Entwicklern reden wir denn jetzt?

Beim UP ging es mal um Industrie 4.0 und IoT.
Also um alle Entwickler, welche sich in diesem Umfeld bewegen.

Grundsätzlich habe ich nur 2 Arten von Entwicklern kennen gelernt.
Die einen denken nur bis zu Kante des Labortisches, bei den anderen ist die Welt grösser.

Die meisten sind spezialisiert auf Web, Datenbanken oder sonst irgendwas.
Es gibt aber nur wenige, die sich mit komplexen Backends und Security Layern und iot Architektur auskennen.
Von DLTS Layern auf Bankenniveau mal ganz zu schweigen.

DLTS kenne ich nur als "Deep Level Transient Spectroscopy"


Nun, früher hat man kritische Anlagen, wie z.B. die Steuerwarte eines AKWs, in einem gepanzerten Raum gesperrt und eine Zutrittskontrolle zu diesem Raum eingerichtet. Das Problem, dass unbefugte da rumspielen, war dadurch gelöst.
Mittlerweile hat dieser Raum aber einen Internet-Anschluss.

Das selbe bei IoT, Kaffee machen konnte, wer zutritt zu meine Kaffeemaschine hatte!
Mit iot kann das jeder, von irgendwo auf der Welt!

Manche machen das aus Spass an der Freude, bzw. weil sie es können, Andere um wirtschaftlichen Schaden anzurichten und mein Kaffeelieferant vielleicht um seinen Umsatz zu steigern?

Bisher galt für Entwickler, dass der Missbrauch seines Produkts, das Problem des Kunden war.
Wenn die Geräte nun alle vernetzt werden, muss der Entwickler auch Gedanken daran "verschwenden", wie er die Zutrittskontrolle in sein Produkt integriert. Der Kunde muss das dann aber immer noch irgendwie verwalten können.

Ein guter Entwickler hat sich aber schon immer Gedanken zur Sicherheit seines Produkts gemacht, für ihn ändert sich daran nichts.
Das "Geheimnis" guter Software, bestand schon immer aus Plausibilitätsprüfungen und entsprechender Verweigerung einen Befehl auszuführen.

Das fängt bei etwas einfachem wie der Abfrage von Benutzername und Passwort an!
Schlechte Software gibt einen Hinweis, welcher Teil falsch ist, damit hat man schon 50% gehackt, gute Software lässt einem im ungewissen!
Das nächste ist dann, nach z.B. 3 Fehlversuchen den Zugang zu sperren oder eine Wartezeit einzufügen, das verhindert recht gut Brute Force Angriffe und ist Programmtechnisch kein wirklicher Aufwand. Kennt man aber alles schon seit den 60er Jahren.
Hat sich aber immer noch nicht bei allen Programmieren rumgesprochen.

Ich hatte ende 70er Jahre mal einen Streit mit einem Programmierer, weil er nicht im Stande war den Unterschied folgenden Codes zu sehen.

INPUT "Alles löschen", A$
If A$ = "N" THEN GOTO mach_nix
REM Alles löschen

und

INPUT "Alles löschen", A$
If A$ = "J" THEN GOTO alles_löschen
REM Mach nix

Er konnte einfach nicht erkennen, was passiert wenn man sich vertippt und Anstatt "N", ein "M" erwischt. Der konnte nur digital denken und es gab für ihn nur "N" und "J"!

Aber bei vielen Dingen genügt schon gesunder Menschenverstand und es brauch nicht wirklich Spezielles Wissen!
1. Nur verschlüsselte Verbindungen zulassen und nur Protokolle verwenden, welche auch die Passwörter verschlüsselt übertragen. Dazu muss ich mich nicht wirklich mit Verschlüsselung auskennen, dazu gibt es eine Bibliothek.
2. Zwischen Anmeldeversuchen eine Pause erzwingen. Kann man z.B. nur alle 10s eine Eingabe machen, kann auch der schnellste Rechner der Welt nicht mehr als 360 Versuch/h austesten. Bei nur schon einem 4-stelligen PIN, also nur Ziffern, braucht dieser dann im Mittel etwa 14h, für einen Treffer.
3. Timeout der Verbindung, wenn sie eine Weile nicht benutzt wird.
4. Plausibiltätsprüfung! Erst alle Parameter auf Gültigkeit überprüfen und dann den Befehl ausführen. Alles andere wird ignoriert oder ergibt eine Fehlermeldung.

Zusammen mit einem sicheren Netzwerktreiber und IP-Stack, beides ohne Hintertürchen, hat man dann schon ein recht sicheres System.

MfG Peter(TOO)