Eigentlich sollte ich mich nicht so weit aus dem Fenster lehnen und eine Überschrift wählen, die die katholisch geführte Diskussion zum Thema "Industrie 4.0" persifliert.
Abgesehen davon, dass das Buzzword zum Jahresende 2014 immer noch als Begriffsware gehandelt wird, wird es weiter aufgeladen und nicht etwa realisiert.
Begriffsware deshalb, weil jeder Storrage-Spezialist behauptet: "Industrie 4.0 fängt bei unserer Cloud an", jeder Anti-Viren-Hersteller damit wirbt, das "Industrie 4.0 ersteinmal sicher sein muss - durch uns". Man merkt, wohin das führt. Eine Größe der Branche behauptet den Stein der Weisen zu besitzen, allein durch die Anhängung des Etiketts an ihr bestehendes Produkt. Somit wird bedeuerlicher Weise ein heres Unterfangen zu eben; einem Etikett. Die Version 3.5 ist daher als Respektsbekundung gewählt worden, um mit diesem Artikel eben ein wenig leiser zu schreien.
Der zweite Teil ist angelehnt an dem neuen Modebegriff: Generation Y. Also jene 'digital natives' der neusten Generation, die als Bachelor of Engineering, bewaffnet mit Tablets, irgendwas mit Industrie 4.0 machen sollen. (so gesehen in: SPS-Special 2014, Seite 258)
Meine Vorahnung aus: "Buzzword hier" hat sich leider bewahrheitet und die industrielle Revolution hat ihre erste Generation gefordert.
Das eine Produktevolution bei Messgeräten mit modernen Anzeigegeräten (Tablets/Smartphones) sinnvoll erscheint, mag dahingestellt sein. Das Thema wird nicht getroffen, wenn der erste Krug noch nicht leer ist, ein neues Faß aber angeschlagen wird.
Das Thema, besser gesagt, das Ereignis bietet mehr als Etikettenhascherei und die Überladung mit Marketingsprech. Meiner Meinung nach, könnte die Revolution schon ein Stück vorangeschritten sein, wenn eine Roadmap aufgestellt worden wäre, nach dem Schema Eingabe/Ausgabe/Verarbeitung. Z.B.:
1. Sensoren auf den neusten Stand bringen und informationstechnisch und sinnvoll an ein System anbinden.
2. Anzeigesysteme modernisiere, an die Gewohnheiten der Benutzer des 21.Jhr.
3. Verarbeitungssysteme konzipieren, die die Datenmengen bewältigen und zur Weiterverarbeitung strukturieren. - Von mir aus auch in einer Cloud.
Der größte Umbruch wird in dem Verständnis über den alten Begriff: Prozessdaten stattfinden. Nicht nur Daten zur Steuerung einer Anlage werden die große Rolle spielen, sondern auch die Daten der Sensoren und die Daten der Visualisierung. Aktuell sind diese noch eins und erschweren das Konvertieren in eine neue Ära.
So gesehen, ist Industrie 4.0 vorrangig eine Revolution in den Köpfen. Dazu sind Buzzwords gute Hilfsmittel. Über das Ziel hinaus sollte aber nicht geschossen werden.
SPS versus ...
... guten Geschmack. -Die wilden Geschichten im Anlagenbau-
Freitag, 21. November 2014
Dienstag, 18. Juni 2013
Buzzword hier: Industrie 0.4
Industrie 4.0 heißt es korrekt und die "soll die vierte industrielle Revolution zum Ausdruck bringen". - Puh, ein schweres Los welches die deutsche Industrie da gezogen hat. Wahrscheinlich wird eine ganze Generation von Ingenieuren und Technikern für diese Revolution draufgehen. Darunter macht es die Industrie-Consulting-Szene halt nicht und warum sollte es auch leicht gehen?
Auch ohne Plakatismus finde ich das Anliegen wiklich revolutionär - die Schaffung eines individuellen Gutes allein definniert durch die Kreativität des Kunden. Das kommt dem Replikator aus "Star Trek" schon sehr nahe. Leider wird immer schnell eine Idee zu einem Begriff; und dieser Begriff wird stark aufgeladen, wodurch es der oben genannten Generation schwer fallen wird, Produkte mit dem Label "Industrie 4.0" zu entwickeln, besonders wenn weitere Schlagworte, wie: "Internet der Dinge" oder "Cyber-physische Systeme" hinterher gerufen werden. - Szenetypisch.
Ingenieurstypisch muss vor dem Umbruch ersteinmal eine Bestandsaufnahme gemacht werden, um zu erkennen wofür Industrie 4.0 wahrhaftig stehen könnte. Zugegeben ist dies ein Versuch, die Angelegenheit aus einer vollkommen individualisierten Sicht zu betrachten.
Solange ich im Anlagenbau als Entwickler und Inbetriebnehmer beschäftigt war, haben sich mir immer fünf Teilnehmer (Objekte) dargestellt.
- Auftraggeber (AG)
- Entwickler (E)
- Operator/Bediener (O)
- Anlage/Werkzeug (WZ)
- Werkstück (WS)
Weiter kann ich die Angelegenheit leider nicht symbolisieren. Denn auch im Rückblick fällt es mir schwer ein univerelles Verfahren aufzuzeigen, welches die Objekte in Beziehung setzt oder eine vollständige Darstellung der Prozesskette und deren Verantwortlichkeiten abbildet, da die Aufgabenverteilungen für ein reproduzierbares Gut aktuell immer individuell gehalten werden. Das hält jeder Hersteller beziehungsweise Auftraggeber anders. Gerade eben, weil es etliche Entwicklungs-Modelle, Geschäftsprozesse, Normen, etc. gibt. Für den nächsten großen Schritt zur Industrie 4.0 muss dieses korrigiert werden. Denn für ein indivuduelles Gut brauchen wir reproduzierbare Strategien.
Meiner Meinung nach, ist dies auch eine große Chance, wodurch diese Richtlinien auf ein einzelnes Objekt herunter gebrochen werden können, nämlich "das Gut". Zusätzlich werden diese Strategien alleinig vom Individuum und der technischen Möglichkeiten bestimmt. Der Kunde wird wieder zum König, wie man so schön sagt.
Dieser Schritt verlangt viel vom Auftraggeber ab, da er vermeintlich einiges an Souveränität und Kompetenz an den Kunden verliert. Aber auch der Entwickler und der Operator haben ab sofort keinen alleinigen Befehlsgeber mehr. - Oder doch?
Meiner Ansicht nach, ist die Revolution eine Projektion der Wünsche des Kunden auf ein und der technologischen Machbarkeit der Herstellers für ein Objekt, so dass sich nachrangig das Teil autark verhält und weiteren Anforderungen den restlichen Beteiligten, zum Beispiel dem Operator vorgibt.
Ansatzweise ist diese Revolution bei einigen Produzenten auch so im Gebrauch. Man kennt das: Drop-down-Listen auf der Webseite, um sich sein Produkt zu konfigurieren. Es bleibt letztendlich bei diesem Ansatz, da alle weiteren Produktionsschritte auf dem herkömmlichen Wege beschritten werden, wie zum Beispiel:
Auftragseingang manuell bearbeiten und abheften, Maschine X händisch auf Parametersatz Y einstellen, welcher im Ordner XY im Regal der Technischen Abteilung niedergeschrieben steht, Farbe anmischen und Probedruck erstellen und so weiter. Es ist somit ein komplexer Aufwand entstanden, bei dem viele Beteiligte wissentlich und unwissentlich ihre Spuren hinterlassen.
Das diese Litarnei an Schritten wegfallen muss, liegt auf der Hand. Nicht um Kosten zu reduzieren, sondern hauptsächlich um Fehler zu vermeiden und ein qualitativ hochwertiges Gut herzustellen.
Den Produktionsprozess zu vereinfachen und alle Prozessschritte dem Gut anzuhängen und diesen selbständig dürch die Fertigung zirkulieren zu lassen, sehe ich nicht als die größte Herausforderung an. Wahrscheinlich kann das auch weiterhin Herstellerabhängig geschehen. Worauf man sich einigen muss, und was auch weit schwieriger zu etablieren sein wird, wäre der Überblick des technisch Machbaren für den Kunden.
Denn idealerweise wird diesem ab dann keine Drop-down-Liste mit wohldefinierten Abstufungen mehr präsentiert, sondern Schieberegler die in möglichen Grenzen verstellt werden können. Worauf zu achten ist, diese Grenzen offen zu kommunizieren und auch vom Kunden richtig verstanden werden.
Letztendlich trägt man mit Industrie 4.0 einen großen Berg Verwaltungsaufwand ab und kann es dem Kunden überlassen, sein Produkt ordentlich zu parametrieren und zu verwalten. Die Generation von Ingenieuren und Techniker bekommen dadurch eine neue klar definierte Aufgabe zugesprochen, den des Wissensvermittler. Denn sie wissen am besten wie sich eine Anlage, in ihren Grenzen, verhalten wird und können dem Kunden an die Hand gehen, falls er diese Hilfe benötigt.
Auch ohne Plakatismus finde ich das Anliegen wiklich revolutionär - die Schaffung eines individuellen Gutes allein definniert durch die Kreativität des Kunden. Das kommt dem Replikator aus "Star Trek" schon sehr nahe. Leider wird immer schnell eine Idee zu einem Begriff; und dieser Begriff wird stark aufgeladen, wodurch es der oben genannten Generation schwer fallen wird, Produkte mit dem Label "Industrie 4.0" zu entwickeln, besonders wenn weitere Schlagworte, wie: "Internet der Dinge" oder "Cyber-physische Systeme" hinterher gerufen werden. - Szenetypisch.
Ingenieurstypisch muss vor dem Umbruch ersteinmal eine Bestandsaufnahme gemacht werden, um zu erkennen wofür Industrie 4.0 wahrhaftig stehen könnte. Zugegeben ist dies ein Versuch, die Angelegenheit aus einer vollkommen individualisierten Sicht zu betrachten.
Solange ich im Anlagenbau als Entwickler und Inbetriebnehmer beschäftigt war, haben sich mir immer fünf Teilnehmer (Objekte) dargestellt.
- Auftraggeber (AG)
- Entwickler (E)
- Operator/Bediener (O)
- Anlage/Werkzeug (WZ)
- Werkstück (WS)
Weiter kann ich die Angelegenheit leider nicht symbolisieren. Denn auch im Rückblick fällt es mir schwer ein univerelles Verfahren aufzuzeigen, welches die Objekte in Beziehung setzt oder eine vollständige Darstellung der Prozesskette und deren Verantwortlichkeiten abbildet, da die Aufgabenverteilungen für ein reproduzierbares Gut aktuell immer individuell gehalten werden. Das hält jeder Hersteller beziehungsweise Auftraggeber anders. Gerade eben, weil es etliche Entwicklungs-Modelle, Geschäftsprozesse, Normen, etc. gibt. Für den nächsten großen Schritt zur Industrie 4.0 muss dieses korrigiert werden. Denn für ein indivuduelles Gut brauchen wir reproduzierbare Strategien.
Meiner Meinung nach, ist dies auch eine große Chance, wodurch diese Richtlinien auf ein einzelnes Objekt herunter gebrochen werden können, nämlich "das Gut". Zusätzlich werden diese Strategien alleinig vom Individuum und der technischen Möglichkeiten bestimmt. Der Kunde wird wieder zum König, wie man so schön sagt.
Dieser Schritt verlangt viel vom Auftraggeber ab, da er vermeintlich einiges an Souveränität und Kompetenz an den Kunden verliert. Aber auch der Entwickler und der Operator haben ab sofort keinen alleinigen Befehlsgeber mehr. - Oder doch?
Meiner Ansicht nach, ist die Revolution eine Projektion der Wünsche des Kunden auf ein und der technologischen Machbarkeit der Herstellers für ein Objekt, so dass sich nachrangig das Teil autark verhält und weiteren Anforderungen den restlichen Beteiligten, zum Beispiel dem Operator vorgibt.
Ansatzweise ist diese Revolution bei einigen Produzenten auch so im Gebrauch. Man kennt das: Drop-down-Listen auf der Webseite, um sich sein Produkt zu konfigurieren. Es bleibt letztendlich bei diesem Ansatz, da alle weiteren Produktionsschritte auf dem herkömmlichen Wege beschritten werden, wie zum Beispiel:
Auftragseingang manuell bearbeiten und abheften, Maschine X händisch auf Parametersatz Y einstellen, welcher im Ordner XY im Regal der Technischen Abteilung niedergeschrieben steht, Farbe anmischen und Probedruck erstellen und so weiter. Es ist somit ein komplexer Aufwand entstanden, bei dem viele Beteiligte wissentlich und unwissentlich ihre Spuren hinterlassen.
Das diese Litarnei an Schritten wegfallen muss, liegt auf der Hand. Nicht um Kosten zu reduzieren, sondern hauptsächlich um Fehler zu vermeiden und ein qualitativ hochwertiges Gut herzustellen.
Den Produktionsprozess zu vereinfachen und alle Prozessschritte dem Gut anzuhängen und diesen selbständig dürch die Fertigung zirkulieren zu lassen, sehe ich nicht als die größte Herausforderung an. Wahrscheinlich kann das auch weiterhin Herstellerabhängig geschehen. Worauf man sich einigen muss, und was auch weit schwieriger zu etablieren sein wird, wäre der Überblick des technisch Machbaren für den Kunden.
Denn idealerweise wird diesem ab dann keine Drop-down-Liste mit wohldefinierten Abstufungen mehr präsentiert, sondern Schieberegler die in möglichen Grenzen verstellt werden können. Worauf zu achten ist, diese Grenzen offen zu kommunizieren und auch vom Kunden richtig verstanden werden.
Letztendlich trägt man mit Industrie 4.0 einen großen Berg Verwaltungsaufwand ab und kann es dem Kunden überlassen, sein Produkt ordentlich zu parametrieren und zu verwalten. Die Generation von Ingenieuren und Techniker bekommen dadurch eine neue klar definierte Aufgabe zugesprochen, den des Wissensvermittler. Denn sie wissen am besten wie sich eine Anlage, in ihren Grenzen, verhalten wird und können dem Kunden an die Hand gehen, falls er diese Hilfe benötigt.
Montag, 26. November 2012
Apps und Anlagenbau
Smartphone-Anwendungen (Apps) und die Steuerung von Anlagen sind nur auf dem ersten Blick konträr. Und das ausschließlich, weil man beide Teile noch nie als Ganzes betrachtet hatte. Auf dem zweiten Blick, der etwas in die Zukunft gerichtet ist, erkennt man einen neuen Umgang mit Maschinen sowie neue Geschäftsfelder.
Wie Herr Beu von der User Interface Design GmbH in der November '12 Ausgabe des SPS-Magazins richtig erwähnt hatte, ist es nur noch eine zeitliche Angelegenheit, wann Smartphones oder Tablets den Personal Computer ablösen.
Eine solche Umwälzung bedeutet wahrlich nicht die vollständige Ersetzung aller konventionellen PCs und deren Beitrag zu Lösungen im Anlagenbau. Vielmehr werden diese kleinen Computer vorerst in den Bereichen ihren Dienst verrichten, in denen sich ein Mehrwert zum Bestehenden, erreichen läßt.
Im besagten Artikel wurde ebenfalls der Arbeitskreis „Mobile, Tablets, Apps + Co.“, vom VDMA erwähnt, der hierzu bestimmt bald einige Diskussionen anstoßen wird.
Schon heute kann ich mir eine Anwendung, sowie deren Mehrwert, mit Android & Co. vorstellen, welche ich in der Rubrik: ...Android versucht habe darzustellen. Zugegebenermaßen insistiere ich dabei auf die vollständige Ersetzung aller konventioneller Teile im Anlagenbau, welche aber als Diskussionseinstieg unabdingbar war, um Ressentiments ungefiltert zu erfassen.
Einen solchen Medienbruch von klassischen Engineering in der Anlagensteuerung zu Comsumer-Geräten und deren Implementierungsmöglichkeiten bietet nebenbei den Vorteil sich weitere Konzepte zur Programmgestaltung anzueignen und ist mit nichten ein Nachteil. In ihrer Arbeit: "Intuitive und attraktive Bedienoberflächen für Maschinen", von Beu & Stetter hat man den Vorgang benannt. Zum Beispiel wenn die Maschine zum Subjekt wird und der Bediener über die Benutzeroberfläche einen nicht unerheblichen Interaktionsspielraum zur Verfügung gestellt bekommt. Eine sorgfältig ausgearbeitete Schnittstelle, als Richtungsvorgabe für Bediener und Programmdesigner darf dann nicht mehr von Dritten verändert werden. Die vorherrschende Vorgehensweise, eine Melange aus Funktionen und Gestaltungselementen, vom Vertrieb an den klassischen Programmierer von Anlagen an zu tragen, birgt die Gefahr, das dieser sein ganzes Konzept in Frage stellt, um dann auf der "Zielgeraden" dieses Konzept nicht unerheblich umzugestalten.
Der Entwurf und die Implementierung von sog. Apps fordert eine andere Herangehensweise, bei der eine klare Trennung zumindest zwischen Entwurf, Design der grafischen Oberfläche und Programmimplementierung statt findet. Ebenfalls können einzelne Module aktualisiert bzw. verändert werden ohne das Ergebnis zu zerstören. Dadurch kann erreicht werden, dass Projektaufgaben separiert und parallel bearbeitet werden können und, bei geschicktem Engineering-Prozess, kontinuierlich ein lauffähiges Produkt bereit gestellt werden kann. Besonders interessant wird diese Modularisierung bei Angelegenheiten, die nur temporär bearbeitet werden müssen, zum Beispiel ein "Hotfix" bezüglich eines Sicherheitsaspektes. Die Update-Prozesse von iPhone & Android würden hierbei helfen, flexibel und schnell am Markt reagieren zu können, unabhängig von der Stückzahl das Produkts.
Neue Geschäftsfelder könnten sich durch eine andere Aufgabenverteilung und der Professionalisierung der Anwendungsmodule ergeben. Eine Entlastung des Programmierers, der für "alles Elektrische" zuständig ist, ist zwingend angeraten.
Wie Herr Beu von der User Interface Design GmbH in der November '12 Ausgabe des SPS-Magazins richtig erwähnt hatte, ist es nur noch eine zeitliche Angelegenheit, wann Smartphones oder Tablets den Personal Computer ablösen.
Eine solche Umwälzung bedeutet wahrlich nicht die vollständige Ersetzung aller konventionellen PCs und deren Beitrag zu Lösungen im Anlagenbau. Vielmehr werden diese kleinen Computer vorerst in den Bereichen ihren Dienst verrichten, in denen sich ein Mehrwert zum Bestehenden, erreichen läßt.
Im besagten Artikel wurde ebenfalls der Arbeitskreis „Mobile, Tablets, Apps + Co.“, vom VDMA erwähnt, der hierzu bestimmt bald einige Diskussionen anstoßen wird.
Schon heute kann ich mir eine Anwendung, sowie deren Mehrwert, mit Android & Co. vorstellen, welche ich in der Rubrik: ...Android versucht habe darzustellen. Zugegebenermaßen insistiere ich dabei auf die vollständige Ersetzung aller konventioneller Teile im Anlagenbau, welche aber als Diskussionseinstieg unabdingbar war, um Ressentiments ungefiltert zu erfassen.
Einen solchen Medienbruch von klassischen Engineering in der Anlagensteuerung zu Comsumer-Geräten und deren Implementierungsmöglichkeiten bietet nebenbei den Vorteil sich weitere Konzepte zur Programmgestaltung anzueignen und ist mit nichten ein Nachteil. In ihrer Arbeit: "Intuitive und attraktive Bedienoberflächen für Maschinen", von Beu & Stetter hat man den Vorgang benannt. Zum Beispiel wenn die Maschine zum Subjekt wird und der Bediener über die Benutzeroberfläche einen nicht unerheblichen Interaktionsspielraum zur Verfügung gestellt bekommt. Eine sorgfältig ausgearbeitete Schnittstelle, als Richtungsvorgabe für Bediener und Programmdesigner darf dann nicht mehr von Dritten verändert werden. Die vorherrschende Vorgehensweise, eine Melange aus Funktionen und Gestaltungselementen, vom Vertrieb an den klassischen Programmierer von Anlagen an zu tragen, birgt die Gefahr, das dieser sein ganzes Konzept in Frage stellt, um dann auf der "Zielgeraden" dieses Konzept nicht unerheblich umzugestalten.
Der Entwurf und die Implementierung von sog. Apps fordert eine andere Herangehensweise, bei der eine klare Trennung zumindest zwischen Entwurf, Design der grafischen Oberfläche und Programmimplementierung statt findet. Ebenfalls können einzelne Module aktualisiert bzw. verändert werden ohne das Ergebnis zu zerstören. Dadurch kann erreicht werden, dass Projektaufgaben separiert und parallel bearbeitet werden können und, bei geschicktem Engineering-Prozess, kontinuierlich ein lauffähiges Produkt bereit gestellt werden kann. Besonders interessant wird diese Modularisierung bei Angelegenheiten, die nur temporär bearbeitet werden müssen, zum Beispiel ein "Hotfix" bezüglich eines Sicherheitsaspektes. Die Update-Prozesse von iPhone & Android würden hierbei helfen, flexibel und schnell am Markt reagieren zu können, unabhängig von der Stückzahl das Produkts.
Neue Geschäftsfelder könnten sich durch eine andere Aufgabenverteilung und der Professionalisierung der Anwendungsmodule ergeben. Eine Entlastung des Programmierers, der für "alles Elektrische" zuständig ist, ist zwingend angeraten.
Donnerstag, 22. November 2012
Die Sicherheit von ...
Speicherprogrammierbaren Steuerungen ist ein größeres Feld, als ein Groß der Programmierer und Systementwickler allgemein annehmen.
Die Robustheits-Mär habe ich vor Kurzem in einem Post zu widerlegen versucht. Zur Belegung meiner Annahme sind heute wieder Meldungen von heise hereingekommen.
Eine Meldung vom 03.08.2011 berichtet davon, dass es nicht schwer ist, eine SPS über das Internet zu finden und dann zu steuern. Mit der Hilfe von Google und markanten Begriffen läßt sich ein SCADA-System bzw. eine vernetzte SPS aufspüren. Alles weitere bestimmt die kriminelle Energie des Angreifers.
Die neuere Meldung vom 22.11.2012 führt vor Augen, dass eben diese kriminelle Energie existiert. Dazu werden SCADA-Schwächen ausgenutzt und das Wissen darüber an den Meistbietenden veräussert.
Es ist also gut zu überlegen, ob man etwas per se als sicher deklariert und Schwachstellen eines Systems geflissentlich übersieht.
Die Robustheits-Mär habe ich vor Kurzem in einem Post zu widerlegen versucht. Zur Belegung meiner Annahme sind heute wieder Meldungen von heise hereingekommen.
Eine Meldung vom 03.08.2011 berichtet davon, dass es nicht schwer ist, eine SPS über das Internet zu finden und dann zu steuern. Mit der Hilfe von Google und markanten Begriffen läßt sich ein SCADA-System bzw. eine vernetzte SPS aufspüren. Alles weitere bestimmt die kriminelle Energie des Angreifers.
Die neuere Meldung vom 22.11.2012 führt vor Augen, dass eben diese kriminelle Energie existiert. Dazu werden SCADA-Schwächen ausgenutzt und das Wissen darüber an den Meistbietenden veräussert.
Es ist also gut zu überlegen, ob man etwas per se als sicher deklariert und Schwachstellen eines Systems geflissentlich übersieht.
Montag, 5. November 2012
Update, der Stand der Dinge
Wenn ich eine Software geschrieben habe und ich irgendwann zu dem Schluss gelangt bin, dass diese Software bereit ist für den produktiven Einsatz, dann veröffentliche ich sie. Immer stellt sich im Nachhinein heraus, dass diese Software noch Fehler enthält. Meistens zu Problematiken, die erst zu einem späteren Zeitpunkt geklärt werden konnten, da sie vorher gar nicht als solche wahrgenommen wurden. Dieser Umstand liegt in der Natur der Sache, da ich, wie schon einmal erwähnt, meine Software nicht auf unbekanntes Verhalten prüfen kann.
Um diese Problematik zu entschärfen, wird Software kontinuierlich aktualisiert, also mit einem Update versorgt. An diesem Vorgehen ist nichts verwerfliches. Es ist sogar ein ehrliches und löbliches Verhalten des Programmierers, welches sogar bei ganzen Betriebssystemen praktiziert wird.
Es liegt also in der Verantwortung des Programmierers, seine Software auf dem neusten Stand zu halten.
Immer öfters kommt es vor, dass bekannte Schwächen von Software solange verschleiert werden, um sie erst bei der nächsten, noch besseren, noch bunteren und noch teureren Version zu beheben.
Hier liegt die Verantwortung beim Anwender, seine Software auf dem neusten Stand zu halten.
...$$$...
Es gibt demnach zwei Parteien, die für die Aktualität eines Systems verantwortlich sind und dieser Umstand kann zu Verwechselungen der Verantwortlichkeiten führen. Oder zu absurden Systemkonstellationen, wenn ein Hersteller eine statische Systemumgebung, für die Lauffähigkeit seiner Produkte, verlangt. Dadurch wird eine Aktualisierung des ganzen Systems kategorisch ausgeschlossen.
Der Zwang in der Automatisierunggilde ist eklatant. Nicht nur die Entwicklungswerkzeuge zwingen zu definierten Umständen, wie z.b. das Betriebssystem, sondern auch die Ausführungsumgebungen (Runtime) sind nur lauffähig, wenn sie eine vom Hersteller definierte Umgebung vorfinden.
Worin liegt nun das Problem?
Im Anlagenbau wird gerne mit den Prädikaten "Innovationssicherheit" und "mehr als 20 Jahre Verfügbarkeit" geworben, welches den Kunden suggeriert, das sie für einen langen Zeitraum von der Pflege ihrer Produkte befreit wären. Eine Update-Strategie würde dieses idealisierte Bild zerstören.
...$$$...
Wie ideal wäre es, wenn die Steuerung von Apollo 12 noch heute ihren Dienst erledigen würde, wie ein Gusseisenventil, welches nach 40 Jahren nicht leckt. Das ist in der Informationstechnologie aber so nicht zu leisten.
Die vorgeschriebenen Umgebungen sind undynamische Gebilde und dürfen nicht auf den neusten Stand gebracht werden. Wenn man sich vergegenwärtigt, dass jegliche Software Sicherheitsschwächen aufweisen können, ist das ein gefährliches Unterfangen.
Eine konkrete Umgebung wäre: Windows XP mit Service Pack 2, aber ohne Hotfix KB319740 (o.ä.), um eine Entwicklungsumgebung zur Erstellung von Visualisierungen für Steuerungen zu betreiben.
Eine solche Grundlage verbietet das Einspielen von wichtigen Aktualisierungen, da die Software sonst nicht korrekt funktioniert.
Meines Erachtens dürfen aus diesem Grund Schlagworte, wie "Sicher" nicht verwendet werden. Weiterhin sollte eine andere Update-Politik der Hersteller betrieben werden.
Um diese Problematik zu entschärfen, wird Software kontinuierlich aktualisiert, also mit einem Update versorgt. An diesem Vorgehen ist nichts verwerfliches. Es ist sogar ein ehrliches und löbliches Verhalten des Programmierers, welches sogar bei ganzen Betriebssystemen praktiziert wird.
Es liegt also in der Verantwortung des Programmierers, seine Software auf dem neusten Stand zu halten.
Immer öfters kommt es vor, dass bekannte Schwächen von Software solange verschleiert werden, um sie erst bei der nächsten, noch besseren, noch bunteren und noch teureren Version zu beheben.
Hier liegt die Verantwortung beim Anwender, seine Software auf dem neusten Stand zu halten.
...$$$...
Es gibt demnach zwei Parteien, die für die Aktualität eines Systems verantwortlich sind und dieser Umstand kann zu Verwechselungen der Verantwortlichkeiten führen. Oder zu absurden Systemkonstellationen, wenn ein Hersteller eine statische Systemumgebung, für die Lauffähigkeit seiner Produkte, verlangt. Dadurch wird eine Aktualisierung des ganzen Systems kategorisch ausgeschlossen.
Der Zwang in der Automatisierunggilde ist eklatant. Nicht nur die Entwicklungswerkzeuge zwingen zu definierten Umständen, wie z.b. das Betriebssystem, sondern auch die Ausführungsumgebungen (Runtime) sind nur lauffähig, wenn sie eine vom Hersteller definierte Umgebung vorfinden.
Worin liegt nun das Problem?
Im Anlagenbau wird gerne mit den Prädikaten "Innovationssicherheit" und "mehr als 20 Jahre Verfügbarkeit" geworben, welches den Kunden suggeriert, das sie für einen langen Zeitraum von der Pflege ihrer Produkte befreit wären. Eine Update-Strategie würde dieses idealisierte Bild zerstören.
...$$$...
Wie ideal wäre es, wenn die Steuerung von Apollo 12 noch heute ihren Dienst erledigen würde, wie ein Gusseisenventil, welches nach 40 Jahren nicht leckt. Das ist in der Informationstechnologie aber so nicht zu leisten.
Die vorgeschriebenen Umgebungen sind undynamische Gebilde und dürfen nicht auf den neusten Stand gebracht werden. Wenn man sich vergegenwärtigt, dass jegliche Software Sicherheitsschwächen aufweisen können, ist das ein gefährliches Unterfangen.
Eine konkrete Umgebung wäre: Windows XP mit Service Pack 2, aber ohne Hotfix KB319740 (o.ä.), um eine Entwicklungsumgebung zur Erstellung von Visualisierungen für Steuerungen zu betreiben.
Eine solche Grundlage verbietet das Einspielen von wichtigen Aktualisierungen, da die Software sonst nicht korrekt funktioniert.
Meines Erachtens dürfen aus diesem Grund Schlagworte, wie "Sicher" nicht verwendet werden. Weiterhin sollte eine andere Update-Politik der Hersteller betrieben werden.
Dienstag, 30. Oktober 2012
Zu: Sicher
Technische Einrichtungen bergen immer das Risiko Fehler zu beinhalten und dadurch unkontrollierbar zu sein. Das liegt auch in der Natur der Sache, Dinge nur darauf testen zu können, worauf man eine Reaktion, ob richtig oder falsch, erwartet. Auf spontanes Verhalten kann halt nicht geprüft werden.
Gegenüber dem Kunden stehe ich aber nun, in seinen Augen, mit einem halbfertigen Produkt dar, weil ich ihm auf die Frage: "Ist das sicher?" keine ehrliche Antwort geben kann.
Denn wer weiß, wie eine Anlage sich verhält, wenn die Sonnenwinde sich drehen oder das Millenium naht?
Ein Industriezweig bietet aber nun Produkte an, denen das Etikett "Sicher" anhaftet. Ein Seegen, das ich Sicherheit delegieren kann!
...$$$...
Nun kann ich dem Kunden die Gefahrenlosigkeit bescheinigen und brauche mich für das Thema nicht mehr zu interessieren.
...$$$...
Das ist inakzeptabel!
Die oben genannten Lösungen können auch nicht erkennen, ob etwas gefährlich sein könnte. Wobei sie aber unschätzbare Hilfe leisten, ist bekannte Fehler und Schludrigkeiten von mir abzustellen und mich auf den richtigen Weg zu bringen.
Und sie überprüfen, ob das was ich schalten wollte auch wirklich geschaltet wurde - Ein Kontrollmechanismus nicht mehr!
Die Frage, die bleibt: Hätte das jetzt schalten dürfen? Eine Logik zu kontrollieren, vermag keine der Produkte.
Sicherheit ist eine Frage der Betrachtung und der konzeptionellen Auslegung.
Allein durch Kontrolle oder ein Zertifikat ist nichts sicher!
Fatal wäre die Vorstellung, die alleinige Verantwortung zur Frage der Sicherheit trüge der, der als erster "ist Sicher!" gesagt hat.
Gegenüber dem Kunden stehe ich aber nun, in seinen Augen, mit einem halbfertigen Produkt dar, weil ich ihm auf die Frage: "Ist das sicher?" keine ehrliche Antwort geben kann.
Denn wer weiß, wie eine Anlage sich verhält, wenn die Sonnenwinde sich drehen oder das Millenium naht?
Ein Industriezweig bietet aber nun Produkte an, denen das Etikett "Sicher" anhaftet. Ein Seegen, das ich Sicherheit delegieren kann!
...$$$...
Nun kann ich dem Kunden die Gefahrenlosigkeit bescheinigen und brauche mich für das Thema nicht mehr zu interessieren.
...$$$...
Das ist inakzeptabel!
Die oben genannten Lösungen können auch nicht erkennen, ob etwas gefährlich sein könnte. Wobei sie aber unschätzbare Hilfe leisten, ist bekannte Fehler und Schludrigkeiten von mir abzustellen und mich auf den richtigen Weg zu bringen.
Und sie überprüfen, ob das was ich schalten wollte auch wirklich geschaltet wurde - Ein Kontrollmechanismus nicht mehr!
Die Frage, die bleibt: Hätte das jetzt schalten dürfen? Eine Logik zu kontrollieren, vermag keine der Produkte.
Sicherheit ist eine Frage der Betrachtung und der konzeptionellen Auslegung.
Allein durch Kontrolle oder ein Zertifikat ist nichts sicher!
Fatal wäre die Vorstellung, die alleinige Verantwortung zur Frage der Sicherheit trüge der, der als erster "ist Sicher!" gesagt hat.
Freitag, 26. Oktober 2012
Ding Dong Dongel
Noch immer ist der Anlagenbau, gerade "Made in Germany", ein großes Geschäft. Und in meiner idealisierten Vorstellung, wird der Umsatz dadurch realisiert, dass eine qualitativ hochwertige und substanzielle Anlage produziert wird.
Ich habe auch vollstes Verständnis dafür, dass das Wissen, welches in der Anlage umgesetzt wurde, Wert ist geschützt zu werden.
Durch ein kleines USB-Gerät wird dieses Anliegen ad absurdum geführt.
Bei so gut wie allen Hilfsmitteln - sprich Anwendungssoftware -, zur Planung und Erstellung von Anlagen und deren Steuerungen, sind Dongel in jeglicher Ausführung notwendig.
Erstaunlicherweise ist diese Unsitte in den Alltag aller Teilnehmer getragen worden. Vom Hersteller der CAD-Anwendungen, über die Entwicklungsumgebung zur Programmierung der Steuerungen, bis hin zu den simplen Anwendungen zur Projektverwaltung.
Als Beispiel dient eine Steuerung eines Herstellers, der seine Gerätschaften für das Non-plus-Ultra für einen speziellen Anwendungsfall proklamiert. Dadurch sind diese Geräte sehr speziell und haben einen nicht unerheblichen Betrag gekostet, um sie zu beschaffen. Das sollen sie auch!
Leider ist das Produkt so noch nicht benutzbar. Zur Erfüllung von Steuerungsaufgaben ist das Gerät zu programmieren. Und dabei haben sich viele Hersteller die Mühe gemacht und das Rad neu erfunden, was faktisch für den Entwickler bedeutet, das er sich eine, vom Hersteller erfundene Entwicklungsumgebung beschaffen muss.
...$$$...
Abgesehen vom Aufwand der Einarbeitung im Umgang mit der neuen IDE, ist diese mit zusätzlichen Kosten verbunden.
Meine Frustration hält sich an diesem Punkt noch in Grenzen, weil folgende Rechnung noch aufgeht:
Alles was Recht ist, um den Wünschen des Kunden und seinem speziellen Anwendungsfall zu entsprechen, solange er die Beschaffungskosten und die Einarbeitungszeitkosten trägt.
Leider werden die Grenzen überschritten, durch den Umstand, dass die spezielle, teure Hardware im Verbund mit der speziellen, teuren Software nur nutzbar ist, wenn ich einen speziellen, teuren Dongel im Rechner stecken habe.
...$$$...
Ich habe also essentiell zwei Dinge (Gerät und IDE), deren Entwicklung aufwändig waren und die Schützendwert sind, und die jeweils ohne das Andere nicht brauchbar sind.
Selbstredend ist für diesen Schutz noch ein Dongel nötig.
Durch diesen Aktionismus wird klar, wodurch "Made in Germany" seinen Wert hat.
Ich habe auch vollstes Verständnis dafür, dass das Wissen, welches in der Anlage umgesetzt wurde, Wert ist geschützt zu werden.
Durch ein kleines USB-Gerät wird dieses Anliegen ad absurdum geführt.
Bei so gut wie allen Hilfsmitteln - sprich Anwendungssoftware -, zur Planung und Erstellung von Anlagen und deren Steuerungen, sind Dongel in jeglicher Ausführung notwendig.
Erstaunlicherweise ist diese Unsitte in den Alltag aller Teilnehmer getragen worden. Vom Hersteller der CAD-Anwendungen, über die Entwicklungsumgebung zur Programmierung der Steuerungen, bis hin zu den simplen Anwendungen zur Projektverwaltung.
Als Beispiel dient eine Steuerung eines Herstellers, der seine Gerätschaften für das Non-plus-Ultra für einen speziellen Anwendungsfall proklamiert. Dadurch sind diese Geräte sehr speziell und haben einen nicht unerheblichen Betrag gekostet, um sie zu beschaffen. Das sollen sie auch!
Leider ist das Produkt so noch nicht benutzbar. Zur Erfüllung von Steuerungsaufgaben ist das Gerät zu programmieren. Und dabei haben sich viele Hersteller die Mühe gemacht und das Rad neu erfunden, was faktisch für den Entwickler bedeutet, das er sich eine, vom Hersteller erfundene Entwicklungsumgebung beschaffen muss.
...$$$...
Abgesehen vom Aufwand der Einarbeitung im Umgang mit der neuen IDE, ist diese mit zusätzlichen Kosten verbunden.
Meine Frustration hält sich an diesem Punkt noch in Grenzen, weil folgende Rechnung noch aufgeht:
Alles was Recht ist, um den Wünschen des Kunden und seinem speziellen Anwendungsfall zu entsprechen, solange er die Beschaffungskosten und die Einarbeitungszeitkosten trägt.
Leider werden die Grenzen überschritten, durch den Umstand, dass die spezielle, teure Hardware im Verbund mit der speziellen, teuren Software nur nutzbar ist, wenn ich einen speziellen, teuren Dongel im Rechner stecken habe.
...$$$...
Ich habe also essentiell zwei Dinge (Gerät und IDE), deren Entwicklung aufwändig waren und die Schützendwert sind, und die jeweils ohne das Andere nicht brauchbar sind.
Selbstredend ist für diesen Schutz noch ein Dongel nötig.
Durch diesen Aktionismus wird klar, wodurch "Made in Germany" seinen Wert hat.
Abonnieren
Posts (Atom)