Dann ist es umso erstaunlicher, dass Du wirklich glaubst es würde sich durch Industrie 4.0 nichts für Entwickler ändern ...Zitat von White_Fox
Dann ist es umso erstaunlicher, dass Du wirklich glaubst es würde sich durch Industrie 4.0 nichts für Entwickler ändern ...
Man kann es ja so formulieren: Für die Entwickler ist es normal, dass sich die Dinge ändern. Insoweit ändert sich nichts.
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.
Mit dem Wissen Anwendungen eventuell so lange betreuen zu müssen, wird man aus Erfahrung natürlich recht konservativ in der Technologieauswahl. Aber wer weiß schon, ob Dinge die gerade hipp sind, z.B. Node.js, in zwölf Jahren auch noch so verbreitet sind.
Und ob das eine Herausforderung wird, auch die Frage der Zuständigkeit lässt sich heute noch garnicht so leicht klären.
Denn nach Inbetriebnahme einer komplett digitalisierten Anlage wird auch nicht unbedingt immer
ein IT oder Sicherheitsexperte zum Händchen halten vor Ort sein.
Und wehe die Module für die Du nicht unbedingt verantwortlich bist machen dann mal Probleme, sei es vor Ort
oder per Fernwartung, dann fängt der Spass und Fehlersuche ohne die Anlage samt IT Integration zu kennen erst richtig an.
Die Kunden IT wird in Zukunft aber so oder so eine deutlich wichtigere Rolle einnehmen müssen als heute,
und der Aussendienst wird neben dem Ingenieur auch IT Experten im Team haben, ganz ohne geht es nicht wirklich.
Hallo,
Leider ist das vor allem in KMUs oft so. Da ist einer aus dem Büro, welcher zu Hause hobbymässig ein bisschen programmieren kann, für die IT zuständig.
Zur Katastrophe wird es aber erst, wenn z.B. der Server explodiert und keine aktuellen Backups vorhanden sind ....
Bei Fremdmodulen ist das erste Problem, dass jeder die Schuld einem anderen zuschiebt, was der Problemlösung nicht dient!
Die IT-Experten im Aussenteam, sind auch nicht wirklich die Lösung. Wenn da mehrere Köche im Kunden-Netzwerk rumfummeln, funktioniert dieses auch nie wirklich!
Funktionieren kann es nur, wenn der Kunde EINEN Fachmann für die IT hat, welcher aber auch alles dokumentiert.
Wenn ich mein Gerät an ein Firmennetzwerk anbinden will, muss ich wissen wie dieses Netzwerk aufgebaut und geschützt ist. Nur mit dem Einstecken des RJ-45 ist es nicht getan. Bei einem gut geschützten Netzwerk muss man sich auch ins richtige Netzsegment hängen und Protokolle und Routen freischalten.
Dazu brauche ich jemanden, der sich mit dem konkreten Netzwerk(-Konzept) auskennt oder eine detaillierte aktuelle Dokumentation.
Hier wird sich noch einiges bewegen müssen!
Das ist auch der grundsätzliche Unterschied ob ein Konzept auf eine White- oder Black-List basiert.
Die Black-List ist einfach zu Handhaben, hinkt aber einer Bedrohung immer hinterher, bzw. kommt oft zu spät!
Eine White-List bietet maximale Sicherheit, macht aber Arbeit und Plug and Play ist auch nicht!
Leider hat die Werbung, besonders mit "Plug and Play" die Denkweise der meisten versaut.
Und die meisten PC-Zeitschriften legen mit ihren Produkt-Bewertungen noch nach. Wenn "Plug and Play" nicht funktioniert, dann gibt es schlechte Bewertungen.
Jeder der sich mit der Technik auskennt weiss aber, dass "Plug and Play" nur funktioniert, wenn alle Scheunentore Sperrangel weit offen sind
Wie sag ich's meinem Kunden ?????
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Hallo,
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,
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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.
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.
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.
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.
undCode:INPUT "Alles löschen", A$ If A$ = "N" THEN GOTO mach_nix REM Alles löschenEr 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"!Code:INPUT "Alles löschen", A$ If A$ = "J" THEN GOTO alles_löschen REM Mach nix
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Was sollte sich deiner Meinung denn auch ändern? Strom fließt immer (technisch) noch von + nach -, und auch Computer schieben nur Nullen und Einsen umher. Ob ich jetzt einem Temperatursensor mit WLAN ausrüste oder etwas anderes-wo soll da der Unterschied sein?
Wenn etwas Neues erfunden werden würde, neue Technologien, neue Werkzeuge...dann würde ich sagen, es ändert sich was. Als man z.B. von Klappertechnik auf elektronische Steuerungen umgesattelt hat-da hat sich was geändert. Aber bei I40 ändert sich nichts. Es stellt lediglich einen neuen Kontext dar, wie bereits (teilweise ziemlich lange) Bestehendes neu verknüpft und angewendet wird. Aber wie gesgt, da ändert sich für Entwickler und Ings kaum etwas.
Versteh mich nicht falsch...die Technik an sich entwickelt sich immer irgendwo ein kleines Stückchen weiter. Das war aber auch vor hundert Jahren schon so, und würde auch ohne I40 so sein, wobei die wirklichen Neuentwicklungen meiner Meinung nach immer seltener werden. Fast alles heutzutage sind entweder Weiterentwicklung oder, wie schon gesagt, eine neue Kombination von bereits schon längst existenter Technik.
Und ich kann mir auch kaum vorstellen daß sich für ITler wirklich viel ändert. Die meisten Herrausforderungen, die I40 mit sich bringt, gab es schon in anderen Bereichen (und wurden dort schon märchenhaft verschlafen). Sichere Funkverbindungen, Verschlüsselungen, Kommunikation in Netzwrken mit mehrern hundert Teilnehmern, harte Echtzeitanwendungen,... alles schon dagewesen.
Für die IT-Abteilungen könnte sich noch ändern, daß von der Firmenleitung neue Aufträge kommen wie "Bremst die Produktion der Konkurrenz". Firmen bekommen ganz neue Möglichkeiten des wirtschaftlichen Wettbewerbs. Stuxnet wäre ein schönes Beispiel, wie der Wettbewerb zukünftig aussehen könnte.
Es mag zwar bescheuert klingen, daß Coca Cola die Produktionsanlagen von Pepsi per Hackangriff lahmlegen würde. Da aber auch schon Geheimdienste von Ländern zur Wirtschaftsspionage angehalten wurden (Stuxnet wurde von staatlichen Geheimdiensten programmiert) würde ich in dieser Hinsicht rein gar nichts mehr ausschliessen. Und ich rede hier nicht von chinesischen oder russischen Hinterhofhackern die in einen amerikanischen Kleinserver einbrechen, sondern von Ländern, wo alle Beteiligten der achsotollen NATO-Partnerschaft angehören.
Also ich habe nicht wirklich den Eindruck, dass Du dich schon mal mit der Architektur und Referenzmodellen beschäftigt hast, wenn Du meinst das Entwickler hier nichts dazu lernen müssen.
Hallo,
Scheint alles schon Realität zu sein!
Im Darknet kann man aktuell, für etwa 60€/h DOS-Attacken bestellen. 10 Minuten, soll es als Muster gratis und für längere Attacken soll es dann entsprechenden Rabatt geben.
War hier in CH letzte Woche gerade ein aktuelles Thema, da mehrere DOS-Attacken auf Firmen stattgefunden haben.
Stuxnet war aber eigentlich auch nicht neu!
So Mitte der 80er Jahre gab es einen Virus, welcher auf IBM-PCs mit MC6845 Videcontroller die Bildfrequenz erhöht hat. Die damaligen IBM-Monitore hatten noch keinen Schutz vor einer zu hohen Bildfrequenz, das waren technisch eigentlich noch Fernseher. Hierbei wird die Hochspannung aus dem Zeilentrafo gewonnen, welcher mit der Bildfrequenz betrieben wird. Mit der Bildfrequenz steigen die Trafoverluste. Am Ende brannte dann meist der Zeilentrafo oder die Treiberstufe durch. Neben der Bildröhre war der Zeilentrafo das teuerste Ersatzteil.
Da es damals noch kein Internet in der heutigen Form gab, verbreitete sich dieser Virus über Disketten. Es genügte eine saubere Diskette in einen infizierten PC einzuschieben und schon war der Virus auf der Diskette. Also war auch Stuxnet ein alter Hut!
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo,
Ich weiss nicht mehr wie viele Protokolle ich auf µCs, von Scratch, implementiert habe, teilweise noch in Assembler. In den 80er Jahren war auch mal ein bei der S5 gebräuchliches dabei. Dazu kommen noch einige selber entwickelte Protokolle für propertiäre Anwendungen. Eigentlich alle nach dem OSI-Modell, wobei man nicht immer alle Schichten benötigt und manche Schichten auch zusammenfassen kann.
TCP/IP besteht, im Gegensatz zu den 7 Schichten bei OSI, auch nur aus 4 Schichten.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Berechtigungen
Zitieren
Lesezeichen