Frage zu Industrie 4.0 und IoT

[i_make_it]

Die Scenarien, die ich ab Morgen testen soll sehen leider anders aus.
Job Shop, Kunde läd im Webinterface Konstruktionsdaten hoch, gibt im Webinterface Produktions- und Technologiedaten ein und gibt den Auftrag auf.
Die Daten laufen direkt in CAD-CAM Kopplungssoftware und es wird z.B. G-Code für eine CNC erstellt und Beladeeinrichtungen (Roboter) mit Programmparamtern gefüttert.
Das Ziel Losgröße 1 und möglichst kostenneutrale Auftragsverarbeitung, Sprich wo es nur geht Automatisierung und Scripting.
Ein Angriff wäre nun ein SQL Injection am Webinterface um fehlerhafte Programme zu erzeugen die zu Schäden an Maschinen führen.
Andere Angriffe könnten DoS Angriffe im Firmennetz sein wenn es dort Sensoren gibt die direkt am LAN hängen (verhindern, verzögern der Kommunikation).

Ich Rede hier von mutwilliger Sabotage durch Hackerangriffe.
Wenn man mal einen Lasttrenner in einem Umspannwerk dazu bringt kurz nach dem Beginn des Öffnungsvorgangs stehen zu bleiben, z.B. weil die SPS zum Neustart gebracht wird, oder ein gefaktes ASI oder Feld Bus Telegramm der Steuerung das Erreichen der Endlage vorgaukelt, dann hat man einen Lichtbogen, der den Trenner zerstört und damit eine ganze Umspannstation lahmlegen kann.
Mach man das in einem kurzen Zeitfenster an einigen Staionen, bekommt man Dominoeffekte, die Auswirkungen quer durch den Kontinent haben.

Übrigens QM oder TQM spricht sich in der IT-Branche erst so langsam rum.
Habe ich selbst bei einem der größten IT-Häuser der Welt, 2010 erlebt.
Meine erste TQM Schulung habe ich in der Automobilbranche 1986 gehabt.
Meine letzte 2010 als ganz aktuelle Kampagne in der IT.
Also über ein viertel Jahrhundert um bekanntes Wissen und bekannte Verfahren unverändert von einer Branche in eine andere zu übernehmen. (Da ich noch meine Orginalunterlagen von 86 habe, konnte ich das dem Schulungsleiter zeigen. Der war übrigens erstaunt daß das schon so alt ist)
Und von wegen Top Management und QM.
Das sind Rahmenwerke die von dort kommen (wenn überhaupt) da steht von den für den konkreten Einzelfall notwendigen Parametern und Masnahmen gar nichts drin.
Wie auch, wie solle ein Volkswirt oder Betriebswirt der im Management sitzt wissen welche UVV, technische Norm oder sonstige Vorgabe 50 Hirachieebenen Weiter unten das Maß der Dinge sind.
Das bleibt dann doch Aufgabe des Entwicklers, Ingenieurs, Facharbeiters etc. der vor Ort ist und weis was er tut.
(wird auch meine Aufgabe werden, Prozesse, Handlungsanweisungen etc. zu verfassen)
Wobei ich selbst schon erlebt habe wie ein Maschinenbau Ingenieur mit einem Praxissemester komplett versagt hat und nach knapp 6 Wochen wieder vor die Tür gesetzt wurde.
Meine Erfahrung ist, das die Facharbeiter die nach ein paar Jahren Beruf ein Studium machen die besseren Ingenieure werden als die Abiturienten die direkt ins Studium gehen und dann mal 6 Monate eine Lehrwerkstatt von innen sehen und weitere 6 Monate hinter Fachahrbeitern herlaufen, denen sie sich überlegen fühlen und deshalb nicht drauf achten was sie da gezeigt bekommen.
Auch eigene Erfahrung, aus der Position des Facharbeiters der 4 Wochen lang einen Bereich zeigen und erklären sollte.
Es wurde nichts aufgeschrieben obwohl ich wiederholt darauf hingewiesen habe.
Und wenn ich mal gefragt habe wie derjenige denn jetzt vorgehen würde, wenn wir an eine ausgefallene Produktionsanlage kamen, kam nichts oder nur Unsinn rüber.
Und das obwohl ich erst gefragt habe wenn der Fall schon mal da war.

Das war übrigens 1990-92 gewesen. ist also kein neues Problem.
Wobei nach meiner Erfahrung, Bachalor und Master das Problem verstärkt zu haben scheinen.

[Peter(TOO)]

Hallo,

Ich Rede hier von mutwilliger Sabotage durch Hackerangriffe.
Wenn man mal einen Lasttrenner in einem Umspannwerk dazu bringt kurz nach dem Beginn des Öffnungsvorgangs stehen zu bleiben, z.B. weil die SPS zum Neustart gebracht wird, oder ein gefaktes ASI oder Feld Bus Telegramm der Steuerung das Erreichen der Endlage vorgaukelt, dann hat man einen Lichtbogen, der den Trenner zerstört und damit eine ganze Umspannstation lahmlegen kann.
Mach man das in einem kurzen Zeitfenster an einigen Staionen, bekommt man Dominoeffekte, die Auswirkungen quer durch den Kontinent haben.

So kompliziert muss man das gar nicht machen, es reicht an der richtigen Stelle "normal" zu unterbrechen, also per Hackerangriff einfach einen Lasttrenner zu öffnen.

2005 hat das hier die SBB mal "ausprobiert".
Wegen Bauarbeiten war nur eine Verbindungsleitung zwischen Norden und Süden in Betrieb und deren Kapazität wurde überschätzt.
Wissen muss man noch, dass die SBB-Kraftwerke sich hauptsächlich im Süden befinden und die meisten Bahnstrecken im Norden.
Durch eine Überlastung wurde diese letzte Verbindung abgeschaltet. Dann kam der Dominoeffekt mit Notabschaltung der Kraftwerke usw.
Zwischen der Störung und dem kompletten Ausfall vergingen 30 Minuten.
Am Ende fuhr in der ganzen Schweiz kein einziger Zug mehr!

Ein wichtiger Teil des Problems war auch das Mensch-Maschine Interface!
http://www.gotthardbahn.ch/downloads...konferenz2.pdf (Seite 10)

MfG Peter(TOO)

[i_make_it]

Na ja, nach so einem Ausfall kann man aber meist wieder geregelt hochfahren.
Ein Angriff der auf einen großen Schaden zielt, wird aber nur dann richtig wirksam, wenn die Reparaturarbeiten langwirig werden und es zu Ersatzteilengpässen kommt, die ein Wiedereinschalten um Wochen oder gar Monate verzögert.

Ich habe selbst erlebt wie dank "effektiven" Controllings die Ersatzteilhaltung (also die Kapitalbindung) soweit reduziert wurde, das durch Lieferengpässe seitens des Herstellers, Personal bis zu 8 Wochen ohne Arbeitsgerät da stand. Da ging es nur um ein paar Dutzend Notebook User.
Aber selbst bei kritischer Infrastruktur wird immer mehr auf Kosteneinspaarung denn auf Redundanz und Sicherheit geachtet.
Ende der 80er Jahre gab es einen Vorfall aus dem bis heute nichts gelernt worden ist.
Damals brannte eine einzige Kunststoff Fabrik in Ndien ab und weltweit gin die Chipproduktion in die Knie.
Was war passiert? Durch Outsourcing und Produktionsverlagerung in Billiglohnländer hatte man die Weltproduktion für den Vergußkunststoff von ICs auf zwei Fabriken reduziert.
Als eine davon abbrannte mußten alle Chiphersteller für Monate die Produktion drosseln.
Bei der PEPCON Explosion war es das selbe, betraf aber nur die Einsatzfähigkeit des Spaceshuttle.
Da das eine der zwei Fabriken war die den Treibstoff für die Booster herstellte.

[Peter(TOO)]

Hallo,

Ende der 80er Jahre gab es einen Vorfall aus dem bis heute nichts gelernt worden ist.
Damals brannte eine einzige Kunststoff Fabrik in Ndien ab und weltweit gin die Chipproduktion in die Knie.
Was war passiert? Durch Outsourcing und Produktionsverlagerung in Billiglohnländer hatte man die Weltproduktion für den Vergußkunststoff von ICs auf zwei Fabriken reduziert.
Als eine davon abbrannte mußten alle Chiphersteller für Monate die Produktion drosseln.

Der war herbeigeredet!

Das war die Fabrik von Hitachi und die hatten noch Material für 1 bis 2 Jahre an Lager, also eigentlich kein Problem.
Ich hatte da gerade relativ neu, meine direkten Kontakt zur Europazentrale von Hitachi. Die machen ja nicht nur in Elektronik, sondern sind auch ein grosser Chemiekonzern, bauen Supertanker, Bügeleisen, Staubsauger und Reiskocher sowie AKWs und weiss ich noch was. Ich hatte mal Prospekte mit dem ganzen Programm..

Das Problem sind dann die Einkäufer der Amis.
Bei den Amis gibt es einerseits keinen Kündigungsschutz für Arbeitnehmer und andererseits ist das Vertragsrecht auch ganz anders.
Wenn morgens die Ware fehlt, hat Mittags ein anderer den Job als Einkäufer und der Alte steht auf der Strasse.
Deshalb bestellen die die volle Menge bei mehreren Lieferanten gleichzeitig. Wenn der erste liefert, bekommen die anderen eine Absage.
Bei einer solchen Zeitungsmeldung bestellen die dann bei 5 weiteren Lieferanten zusätzlich!

Sowas lässt dann die Preise hochschnellen und verknappt scheinbar das Angebot. Nachher bricht dann alles zusammen.

Deshalb ist bei den Amis das "Book to Bill", also bestellte zu tatsächlich verkaufter Menge, so eine wichtige Zahl.
Zudem denken die auch nur Quartalsweise.

So eine Kriese haben wir aber alle paar Jahre mal.
- Mitte 70er explodierte der Goldpreis, da wurden dann die Preise für Stecker, IC-Sockel usw. in einen Grundpreis und den Goldanteil, welcher zum Tageskurs verrechnet wurde, aufgeteilt. Ist bis heute so geblieben.
+ Da war, Ende 70er der 74LS05 (ein 4-fach NAND mit OC), der kostete eigentlich mal 20 Rappen, wurde dann aber für 15-20 Franken pro Stück gehandelt. OK, hier war der Grund der APPLE ][, der hatte diesen verbaut und als dann die Taiwanesen mit den Nachbauten angefangen haben ....
- Das nächste waren dann Tantalelkos.

- was sonst noch alles war, weiss ich gar nicht mehr?

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo ABC-Meise,

Das würde ich so nicht unbedingt sagen, denn die Industrie hat ja leider auch bedingt durch Probleme und Unfälle dazu gelernt und daraufhin technisch nachgebessert.
Die Frage ist nur wie man in der Vergangenheit mit Produktionsfehlern und Unfallstatistiken allgemein umgegangen ist und ob die Ursachen hier immer transparent kommuniziert wurden.

Die Unfallverhütung meinte ich gar nicht, sondern "nur" die Bedienung.
Bei meinen Programmen war z.B. der Hintergrund, grossflächig Grau, wenn nicht gemessen wurde.
Wenn alles innerhalb der Grenzen lag Grün.
Bei Störungen und wenn was sonst aus dem Ruder lief Rot.
Die Farbflächen kann man dann auf 10-15m Distanz erkennen.
Bei Grün und Gelb interessieren die Werte eigentlich gar nicht.
Bei Rot muss man dann sowieso zum Steuerpult hechten um genau zu sehen was da genau los ist.

Ich habe da viel anderes gesehen, meistens waren einfach nur die Werte, welcher ausserhalb der Toleranz waren, in Rot, aber das konnte man nur auf ein paar Meter erkennen.

Also in dem Zusammenhang was Peter ansprach, die Abläufe bei Kunden zu optimieren, sind Entwickler garnicht befugt darüber zu entscheiden.

Das habe ich auch nicht gemacht!
Aber als Entwickler kann ich das Interface so gestallten, dass es IN den Ablauf passt!
Ich kann meine Abfragemaske so gestallten, dass sie die selbe Reihenfolge wie auf dem Auftrag hat oder so, dass man sich alles auf dem Auftrag zusammensuchen muss. Beim Programmieren macht dies nicht einmal mehr Arbeit.
Auch kann ich Eingaben verlangen, welche in dieser Form nicht vorhanden sind und man bei der Eingabe erst mal mit dem Taschenrechner umrechnen muss! Oder ich mache die Umrechnung in meiner Software. Wenn da ein Amit-Teil ist, welches mit PSI arbeitet, erzwinge ich nicht die Eingabe in Bar, sondern verwende halt auch PSI.

Jetzt rate mal, welches System mehr Eingabefehler verursacht

Grundsätzlich verwende ich ISO-Einheiten, wenn aber in einem Betrieb mit alten, oder Hauseigenen, Einheiten gearbeitet wird, übernehme ich diese.
OK, wird natürlich nicht fest codiert, sondern ist konfigurierbar.

Ich habe aber z.B. die Software für die Vorfeld-Busse auf dem Zürcher Flughafen kennen gelernt. Der Sprechfunk ist das am meisten benutze Kommunikationsmittel. Nun ist diese aber nur in der 2ten Ebene eines Menüs erreichbar. Also 3 mal klicken, bis man sprechen kann und dies für jede Durchsage an den Fahrer. Ich hätte diese Funktion z.B. auf die SPACE-Taste gelegt!
Aber Siemens hat jede Menge Zertifikate!

Auch so ein grauenhaftes Beispiel, aus den 70er Jahren: Bei einem Buchhaltungsprogramm musste man die Zahlen von recht nach links eingeben (Also die Cents zuerst), war wohl für den Programmierer so einfacher ....

MfG Peter(TOO)

[SPSAmeise]

Die Scenarien, die ich ab Morgen testen soll sehen leider anders aus.
Job Shop, Kunde läd im Webinterface Konstruktionsdaten hoch, gibt im Webinterface Produktions- und Technologiedaten ein und gibt den Auftrag auf.
Die Daten laufen direkt in CAD-CAM Kopplungssoftware und es wird z.B. G-Code für eine CNC erstellt und Beladeeinrichtungen (Roboter) mit Programmparamtern gefüttert.
Das Ziel Losgröße 1 und möglichst kostenneutrale Auftragsverarbeitung, Sprich wo es nur geht Automatisierung und Scripting.
Ein Angriff wäre nun ein SQL Injection am Webinterface um fehlerhafte Programme zu erzeugen die zu Schäden an Maschinen führen.

Also SQL Injection, Crossite Scripting oder sämtliche Schwachpunkte wie auch Directory Traversal hängen leider immer mit schlampiger Planung und Entwicklung zusammen, denn es lässt sich von Anfang an vermeiden, indem man die Regeln beachtet. Hier reicht auch kein Codereview des Architekten sondern man sollte das auch von externen Sicherheitsexperten überprüfen lassen.
Ähnlich wie SaaS Provider die sich erstmal zertifizieren lassen sollten und teilweise müssen, bevor sie Kunden ihre Software auf einer Cloud anbieten.

Das bleibt dann doch Aufgabe des Entwicklers, Ingenieurs, Facharbeiters etc. der vor Ort ist und weis was er tut.

Also in dem Zusammenhang was Peter ansprach, die Abläufe bei Kunden zu optimieren, sind Entwickler garnicht befugt darüber zu entscheiden.
Es ging mir dabei auch nicht um Mitarbeiterkontrolle, sondern darum das die Qualitätsstandards nicht nur eingehalten werden, sondern auch kontinuierlich verbessert werden.

Deshalb fand ich das Beispiel von Peter eigentlich sehr gut, denn um solche Abläufe zu optimieren braucht es Feedback und Einschätzung der Kollegen vor Ort, aber eine entscheidene Veränderung von weiter oben.
Und dazu sollte auch immer mal wieder unabhängig kontrolliert werden, auch Verbesserungsvorschläge von Kollegen ernster genommen werden, bevor Kunden über Umwege damit konfrontiert werden und
gezwungener Weise erst eskalieren muss. Das mag jedes Unternehmen anders regeln, es wird aber höchste Zeit das man bei Qualität und Serviceanforderungen die gleiche Sprache spricht.

(wird auch meine Aufgabe werden, Prozesse, Handlungsanweisungen etc. zu verfassen)
Wobei ich selbst schon erlebt habe wie ein Maschinenbau Ingenieur mit einem Praxissemester komplett versagt hat und nach knapp 6 Wochen wieder vor die Tür gesetzt wurde.
Meine Erfahrung ist, das die Facharbeiter die nach ein paar Jahren Beruf ein Studium machen die besseren Ingenieure werden als die Abiturienten die direkt ins Studium gehen und dann mal 6 Monate eine Lehrwerkstatt von innen sehen und weitere 6 Monate hinter Fachahrbeitern herlaufen, denen sie sich überlegen fühlen und deshalb nicht drauf achten was sie da gezeigt bekommen.

Das kann ich aus der IT nur bestätigen, denn die praktische Berufserfahrung ist oft um einiges sinnvoller und effektiver als die Theorie und den damit verbundenen Qualifikationen auf Papier.
Hier kann man in bestimmten Bereichen auch dem Fachkräftemangel sinnvoll entgegen wirken, indem man z.B dem ein oder anderen motivierten Quereinsteiger über interne Spezialisierung und Fortbildung eine Chance bietet. Das ist deutlich Zielführender als auf gut ausgebildete Leute zu warten.