Frage zu Industrie 4.0 und IoT

Zitat:

---

Zitat von SPSAmeise

Von den Sprachen und Hardwareanforderungen mal abgesehen, wurde SPS mit der Zeit um Fehlerbehandlung, Datenverarbeitung, Skalierung usw. ergänzt.

---

Leider aber nicht um Sicherheitsfeatures.
Ab Übermorgen wird das ein Teil meiner Arbeit sein.
Steuerungen für I40 auf Security Schwachstellen checken.
Wenn die Maschine selbst, über das Firmennetzwerk und dessen Webanbindung in realtime hackbar wird, dann kann das ganz schnell nicht nur teuer sondern auch gefährlich werden.

Zitat:

---

Zitat von SPSAmeise

Mit der altmodischen Denke, darf man sich allerdings auch nicht um Fachkräftemangel in Deutschland wundern, denn moderne Ingenieure und Mechatroniker mit IT Expertenwissen wachsen nicht von Bäumen.

---

Meine Erfahrungen sind leider daß bei den neu ausgebildeten "Fachkräften" das solide altmodische Wissen oft komplett fehlt.
Warum z.B. ein von Grund auf stabiles System entwickeln, wenn man das mit Software stabil regeln kann. Dumm nur bei einem Software Ausfall, wo die fehlende Eigenstabilität einen kritischen Systemzustand hervorruft bevor alles abgeschaltet ist.

Deshalb ist es umso wichtiger, dass man das interdisziplinäre Wissen und seine Kernkompetenzen in den entsprechenden Teams besser ausbaut.
Davon mal abgesehen halte ich persönlich den Berufserfahrenen Kollegen immer noch für den besten Mentor, nur sollte das eben ein gut ausgebildeter Spezialist auf seinem Gebiet sein.

Und das sich die Sicherheit mit SPS nie verbessert hat, stimmt so nicht, schon garnicht zwischen Mensch und Maschine.
Nur erfordert die angestrebte Vernetzung und die Digitalisierung eine andere Sicherheit, die ohne IT Experten kein Ingenieur oder SPS Programmierer alleine bewältigen kann.

Hallo

Zitat:

---

Zitat von SPSAmeise

Und das sich die Sicherheit mit SPS nie verbessert hat, stimmt so nicht, schon garnicht zwischen Mensch und Maschine.

---

Mensch - Maschine ist weniger ein technologisches Problem, sondern ein ergonomisches!

Leider wird hier, vermutlich aus Unwissenheit, vieles an der Realität vorbei programmiert. Eigentlich sollten die verantwortlichen Entwickler so 1 bis 2 Tage vor Ort verbringen und etwas mitarbeiten um zu sehen was für die Arbeitsabläufe wichtig ist.

Genau so, sollten auch alle Geräteentwickler, so mindestens eine Woche im Jahr, im Feld ihre eigenen Geräte installieren und warten müssen. Vieles fällt einem erst auf, wenn man in 6m Höhe auf einer Leiter steht und dann eigentlich drei Hände braucht um eine Messung durchzuführen! Im Labor ist das keine Kunst.

Ich hatte das Privileg, immer von der Erstellung des Pflichtenheftes bis zur Erstinstallation dabei zu sein. Und bei den hartnäckigen Fehlern, musst ich dann als Entwickler auch immer ins Feld. Man lernt nirgends mehr, für die nächsten Projekte als im Feld!
z.B. bei einem Projekt für ein Online-Messgerät für das QM, stellte ich am grünen Tisch die Frage, wie die Parameter verwaltet werden können. Hier war dann die Auskunft, dass alles für jede Charge individuell ist. Vor Ort dann, im Gespräch mit dem Maschinenführer zeigte sich, dass es für jeden Auftrag eine Rezeptnummer gibt, welche eigentlich auch die Messparameter enthält! Das waren aber nur so um die 30 Rezepte. Also gab es dann eine kleine Datenbank mit den Rezeptnummern als Eingabe unter welchen die ganzen Parameter abgelegt wurden. Neue Rezepte konnten auch direkt im Programm erstellt werden. Somit war dann auch gewährleistet, dass jede Schicht auch mit den selben Parametern misst.

Zitat:

---

Zitat von SPSAmeise

Nur erfordert die angestrebte Vernetzung und die Digitalisierung eine andere Sicherheit, die ohne IT Experten kein Ingenieur oder SPS Programmierer alleine bewältigen kann.

---

Das Problem beginnt schon damit, dass die Steuerung überhaupt von ausserhalb des Hauses erreichbar ist. Argument ist meistens die Fernwartung, nur ist ein Zugriff von Aussen meistens höchst gefährlich! Ich will gar nicht wissen, was alles passieren kann, wenn ich bei laufender Maschine ein Firmware-Update mache!
Der andere Punkt ist, wenn jemand auch nur lesend auf Daten zugreifen kann, er jede Menge erfährt, was ihn nichts angeht.

So Mitte der 90er habe ich, für einen Kunden, eine Art Smartmeter entwickelt. Da konnte man z.B. genau sehen, wann morgens der erste kommt und das Licht in der Halle an macht, dann lief er zum nächsten Raum und machte auch dort das Licht an... In den Pausen machte der Kaffeeautomat im Bürotrakt die grösste Lastspitze, da konnte man sogar die rausgelassenen Getränke mitzählen. Da waren aber nur 3 oder 4 Stromzähler verbaut.
Ein anderes Projekt in diesem Rahmen, war ein Spital, da ging es nur um den Gesamt-Stromverbrauch für eine Neuprojektierung. Dir grössten Spitzenströme verursachten die Lifte, dann die OPs. Man konnte da gut erkennen, wenn Nachts ein Not-OP durchgeführt wurde.

Selbst wenn man Windows als Betriebssystem für eine Maschinen-Steuerung verwendet, muss dieses die automatischen Updates nicht machen können! Wenn sich die Maschinen in einem eigenen geschlossenen Netz-Segment befinden, gibt es keine Probleme mit Malware-Angriffen von Aussen. So lange es kein Update für die Steuersoftware gibt, muss auch das Betriebssystem nicht auf dem neuesten Stand sein, ausser es gibt ein konkretes Software-Problem.

An einem funktionierenden System, soll man bekanntlich nichts ändern.

Eigentlich gibt es keine technische Notwendigkeit, dass eine Steuerung weltweit über das Netzwerk erreichbar sein muss!

Ich hatte Kunden, welche PC-basierte (DOS) Steuerungen über 15 Jahre unverändert in Betrieb hatten. Der PC musste dabei aber ein paar mal ausgetauscht werden. Das Aus kam dann, weil wir ISA-Karten eingesetzt hatten und dann keine PCs mit ISA-Bus mehr erhältlich waren. Da musste der Kunde dann auf das neue System umsteigen.

MfG Peter(TOO)

Zitat:

---

Zitat von Peter(TOO)

Hallo

Mensch - Maschine ist weniger ein technologisches Problem, sondern ein ergonomisches!

---

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.

Zitat:

---

Leider wird hier, vermutlich aus Unwissenheit, vieles an der Realität vorbei programmiert. Eigentlich sollten die verantwortlichen Entwickler so 1 bis 2 Tage vor Ort verbringen und etwas mitarbeiten um zu sehen was für die Arbeitsabläufe wichtig ist.

---

Die Praxis mag anders aussehen, und nicht immer so Gewissenhaft und zuverlässig sein wie Du es beschreibst, aber das gehört für mich bereits zur Aufgabe und den Pflichten von QM sowie des Top Managements,
um genau solche Abläufe sicher zu stellen. Der Entwickler selbst kann hier nur Feedback geben, aber die Servicequalität und Richtlinien sollten schon von anderer Stelle konsequent kontrolliert werden.

Das was Du hier beschrieben hast, ist also bereits ein wichtiger Standard für Qualität und Kundenservice und wer das nicht durchsetzt, arbeitet für mein Verständnis einfach nicht professionell und spart leider auch mal wieder an der falschen Stelle.

Zitat:

---

Das Problem beginnt schon damit, dass die Steuerung überhaupt von ausserhalb des Hauses erreichbar ist. Argument ist meistens die Fernwartung, nur ist ein Zugriff von Aussen meistens höchst gefährlich! Ich will gar nicht wissen, was alles passieren kann, wenn ich bei laufender Maschine ein Firmware-Update mache!

---

Das ist kein Problem, sondern eine Option von der Kunden kein Gebrauch machen müssen.
Die Sicherheit beginnt bereits beim Personal mit Verantwortung, und nicht erst bei der Netzwerktechnik.
Die Vorstellung das ein Servicetechniker mal eben Vollzugriff von extern bekommt, ohne Zwischenschicht und keinerlei Kompetenzen vor Ort, halte ich für sehr unrealistisch.

Nur weil man technische Möglichkeiten bietet, heisst das noch lange nicht, dass man keine Sicherheitsrelevanten Entscheidungen in der IT mehr treffen wird.

Zitat:

---

Der andere Punkt ist, wenn jemand auch nur lesend auf Daten zugreifen kann, er jede Menge erfährt, was ihn nichts angeht.

---

Klar, dass haben Produktivsysteme mit sensiblen Kundendaten so an sich, und ist für Support und Wartungsfälle immer schon ein Risiko gewesen, egal in welcher Branche.
Die meisten Probleme lassen sich aber bereits vorher lösen indem man in eine flexible Sandbox und Testlabs mit Kundennahen Simulationen investiert.
Das ist für die Reproduktion von Fehlern in der Industrie sogar einfacher als in der IT, weil man genau weiss mit welcher Hard und Software man es zutun hat und nicht erst lange raten muss

Für eine gute Testabdeckung und Testlabs muss man allerdings auch viel mehr Geld in die Hand nehmen, ob das immer der Fall ist wage ich stark zu bezweifeln, vorallem beim Mittelstand.

Zitat:

---

Eigentlich gibt es keine technische Notwendigkeit, dass eine Steuerung weltweit über das Netzwerk erreichbar sein muss!

---

Man sollte sich hier allerdings nicht in Szenarien reinsteigern, die so auch garnicht umgesetzt werden können.
Denn bei der Vernetzung geht es den meisten Unternehmen weniger um die direkte Steuerung , sondern viel mehr um bessere Analysemöglichkeiten auf Basis
von Sensordaten und mehr Details über Abläufe zu erfahren um effizienter und sicherer zu produzieren, Stichwort Data Science, Predictive Analytics , predictive maintenance etc..

Aus Sicherheitsgründen wird es in Zukunft nicht immer einen Live Zugriff geben, dass macht vielleicht Sinn wenn man an mehreren Standorten produziert, aber selbst dann wird
es immer isolierte Schichten geben, auf denen zum Beispiel ein Update wartet, dass vor Ort aber erstmal synchronisert und wahrscheinlich in einer isolierten Testumgebung überprüft werden würde.

Sicher kann man die Schichten hacken auf der Updates liegen, und dort einen Virus einspielen etc.., aber deshalb hat man noch lange kein Zugriff auf das Netzwerk der Produktion.
Das lässt sich mit einer Cloud vergleichen, mal angenommen der Zugang eines Kunden der amazon Cloud würde gehackt, dann hätte der jenige zwar Zugriff auf einen Bereich innerhalb der Cloud,
allerdings hat man dadurch noch lange kein Zugriff auf das Datacenter des Cloud providers.

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.

Hallo,

Zitat:

---

Zitat von i_make_it

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)

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.

Zitat:

---

Zitat von 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.

---

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.

Zitat:

---

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.

Zitat:

---

(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.

Hallo,

Zitat:

---

Zitat von i_make_it

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,

Zitat:

---

Zitat von SPSAmeise

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.

Zitat:

---

Zitat von SPSAmeise

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)

Zitat:

---

Zitat von Peter(TOO)

Das habe ich auch nicht gemacht!
Aber als Entwickler kann ich das Interface so gestallten, dass es IN den Ablauf passt!

---

Das ist klar, aber Du sagtest auch das allgemein vieles an der Realität vorbei programmiert sei und das verantwortliche Entwickler 1 bis 2 Tage vor Ort verbringen sollten um zu sehen was für die Arbeitsabläufe wichtig ist.
Dies mag unsere Erwartungshaltung sein, ist aber eben kein Standard und kann je nach Kundenlösung nicht nur enorm hohen Aufwand bedeuten sondern auch zum ernsten Problem werden.

Und da wären wir doch beim Kernthema von Industrie 4.0.

Für Kundenanforderungen waren bisher immer individuelle Einzellösungen in einem geschlossenen System erforderlich,
was allerdings sehr teuer und technisch nicht immer ganz trivial ist.

Da die Industrie schon länger die mangelnde Interoperabilität in der Robotik beklagt, muss sie auch innovativ voran gehen indem sie bereit ist langfristig neue globale Kommunikations und Datenstandards zu definieren
und dazu gehört nunmal auch die "verteufelte" IT Vernetzung.