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.
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.
Was der Kunde will
, ist nicht immer leicht zu erkennen. Aber schließlich werde ich dafür engagiert, eben dies heraus zu finden und Fehlinterpretationen im Nachhinein zu korrigieren.
Daran ändert auch kein V- / Wasserfall- / [toller Begriff hier] - Modell! Ohne Kenntnis über den Kundencharakter, kann man mit diesen Modellen auch ganz schnell wieder nach Hause fahren, gleich welche Größe oder Gewichtung der Kunde hat.
Für mich als Entwickler, gerade im Bereich der Softwareerstellung, ist dies ein unzumutbarer Vorgang und lässt mich in einem Zustand der völligen Orientierungslosigkeit zurück, wenn ich den Dialog und die Planung nicht über ein solches Modell kommunizieren kann. Die Orientierung kann dadurch zurück gewonnen werden, in dem ich nur Arbeitsschritte erledige, die der Kunde mir vorgibt. Womit ich einen Teil der Projektverantwortung zurückgebe und der Kunde Informations- und Kontrollkanäle offen hält.
Im neuen Jahrtausend sollte dieses Modell eigentlich nicht mehr anzutreffen sein, wird aber immer noch praktiziert und gibt beiden Parteien eine gefühlte Sicherheit, sowie klare Strukturen vor.
Sicherheit wird aber auch von einem dritten Objekt verlangt:
Zum Beispiel haben meine Betrachtung des Projekt ergeben, dass ein Gefahrenpotential durch einen Antrieb (o.ä.) besteht.
Ausgestattet mit meinem Wissen und Gewissen, halte ich es für Nötig, dass durch diese Erkenntnis, das Projekt revidiert werden muss und zusätzliche Kosten auf den Kunden zukommen werden.
... $$$ ...
Das will der Kunde nicht und habe ein Dilemma. Für viele meiner Zunft ist dies keins, da für sie gilt: Der Kunde ist König! Quantitativ eine löbliche Einstellung. Meine Einstellung bezieht sich aber auf die Qualität. Und eine gefährliche Anlage genügt keinem qualitativen Anspruch.
Auch ist es für mich kein Leichtes, noch halte ich es für erstrebenswert, dem Kunden die Verantwortung über das Gefahrenpotential voll und ganz zu übertragen, denn unerträglich die Vorstellung, ein Personenschaden wurde von mir verursacht.
Somit fällt auch der gute Rat: "Lass Dir von Kunden unterzeichnen, dass er das genau so will.", weg.
Skrupel und Ängste von Entwickler zu erörtern, gehört nicht in diesen Blog. Wohl aber meine Aufforderung zu mehr Courage im Verhältnis zum Kunden.
Meistens zahlt sich dieses mehr aus, als der wage prognostizierte Verlust von Folgeaufträgen, bei eben diesem Kunden.
Daran ändert auch kein V- / Wasserfall- / [toller Begriff hier] - Modell! Ohne Kenntnis über den Kundencharakter, kann man mit diesen Modellen auch ganz schnell wieder nach Hause fahren, gleich welche Größe oder Gewichtung der Kunde hat.
Für mich als Entwickler, gerade im Bereich der Softwareerstellung, ist dies ein unzumutbarer Vorgang und lässt mich in einem Zustand der völligen Orientierungslosigkeit zurück, wenn ich den Dialog und die Planung nicht über ein solches Modell kommunizieren kann. Die Orientierung kann dadurch zurück gewonnen werden, in dem ich nur Arbeitsschritte erledige, die der Kunde mir vorgibt. Womit ich einen Teil der Projektverantwortung zurückgebe und der Kunde Informations- und Kontrollkanäle offen hält.
Im neuen Jahrtausend sollte dieses Modell eigentlich nicht mehr anzutreffen sein, wird aber immer noch praktiziert und gibt beiden Parteien eine gefühlte Sicherheit, sowie klare Strukturen vor.
Sicherheit wird aber auch von einem dritten Objekt verlangt:
Zum Beispiel haben meine Betrachtung des Projekt ergeben, dass ein Gefahrenpotential durch einen Antrieb (o.ä.) besteht.
Ausgestattet mit meinem Wissen und Gewissen, halte ich es für Nötig, dass durch diese Erkenntnis, das Projekt revidiert werden muss und zusätzliche Kosten auf den Kunden zukommen werden.
... $$$ ...
Das will der Kunde nicht und habe ein Dilemma. Für viele meiner Zunft ist dies keins, da für sie gilt: Der Kunde ist König! Quantitativ eine löbliche Einstellung. Meine Einstellung bezieht sich aber auf die Qualität. Und eine gefährliche Anlage genügt keinem qualitativen Anspruch.
Auch ist es für mich kein Leichtes, noch halte ich es für erstrebenswert, dem Kunden die Verantwortung über das Gefahrenpotential voll und ganz zu übertragen, denn unerträglich die Vorstellung, ein Personenschaden wurde von mir verursacht.
Somit fällt auch der gute Rat: "Lass Dir von Kunden unterzeichnen, dass er das genau so will.", weg.
Skrupel und Ängste von Entwickler zu erörtern, gehört nicht in diesen Blog. Wohl aber meine Aufforderung zu mehr Courage im Verhältnis zum Kunden.
Meistens zahlt sich dieses mehr aus, als der wage prognostizierte Verlust von Folgeaufträgen, bei eben diesem Kunden.
Donnerstag, 30. August 2012
NASA und Android
Vor einiger Zeit habe ich versucht meine Android-Idee im Anlagenbau mit einem ideologischen Zirkel aus dem SPS-Lager zu diskutieren. Einige Befürchtungen haben sich als unbegründet herausgestellt, andere habe ich mir angenommen und werde sie mit Hilfe zukünftiger Projekte genauer Untersuchen und dazu Stellung nehmen.
Ein großer Vorbehalt liegt gegenüber dem Neuen ansich. "Was der Bauer nicht kennt, ..."
Vielleicht hilft mir in Zukunft das Argument: "Sogar die NASA denkt über Android in Steuerungssystemen nach."
Zum Beispiel mit dem PhoneSat 1 & 2. [Link NASA] Neben der Kostenbetrachtung spielt für diesen Versuch auch das hohe Entwicklungspotential und die vielfältige Sensorik eine entscheiden Rolle.
Ein übersetzter Artikel findet sich hier: [Link Golem]
Ein großer Vorbehalt liegt gegenüber dem Neuen ansich. "Was der Bauer nicht kennt, ..."
Vielleicht hilft mir in Zukunft das Argument: "Sogar die NASA denkt über Android in Steuerungssystemen nach."
Zum Beispiel mit dem PhoneSat 1 & 2. [Link NASA] Neben der Kostenbetrachtung spielt für diesen Versuch auch das hohe Entwicklungspotential und die vielfältige Sensorik eine entscheiden Rolle.
Ein übersetzter Artikel findet sich hier: [Link Golem]
Dienstag, 17. Juli 2012
Start
Der hier verwendete Text stammt aus meinem Aufsatz: "Konventionelle SPS vs Android".
Technisch bedingt wird in diesem Blog eine andere Version dieses Aufsatzes dargestellt.
Weiterhin ist der Text in diesem Blog eine vorläufige Version und beinhaltet einige Fehler.
Jeder ist dazu eingeladen, auf den jeweiligen Seiten, seine Kommentare und Meinungen hinzuzufügen.
Inhaltsverzeichnis:
-->
Technisch bedingt wird in diesem Blog eine andere Version dieses Aufsatzes dargestellt.
Weiterhin ist der Text in diesem Blog eine vorläufige Version und beinhaltet einige Fehler.
Jeder ist dazu eingeladen, auf den jeweiligen Seiten, seine Kommentare und Meinungen hinzuzufügen.
Inhaltsverzeichnis:
-->
Mittwoch, 4. Juli 2012
Zeitgeist
-->
An früherer Stelle in diesem Aufsatz wurde die Aussage getätigt, dass
die konventionelle Anlagensteuerung dem Zeitgeist der letzten
siebziger Jahre entspricht.
Dazu
stehe ich und das war die Motivation für diesen Text. Ein heutiges
Studium der Informatik wird obsolet, weil eine Branche sich nicht
modernisieren kann. Fast jedes Kapitel rechtfertigt eine Abhandlung
mit dem Inhalt aus einem Semester, eben jenes Studiums. Daher fallen
einige essentiellen Themen knapper aus, als sie es in diese Arbeit
verdient hätten.
Dabei
ist ein Umbruch ohne größere Schwierigkeiten möglich. Der
benötigte Lernaufwand zum Entwurf und Implementierung von Anlagen
unter Android kann durch die geringeren Beschaffungskosten gedeckelt
werden.
Besser mit ...
-->
Mit mehr Standards
Und wenn
es keinen gültigen Standard gibt, sollte einer geschaffen werden. Eleganter ist es bei
einem Paradigmenwechsel eine Umgebung , quasi als Nährboden zu
verwenden, auf die die oben genannten Problematiken nicht zutreffen.
In diesem
Aufsatz werde ich beweisen, das Android dieser Herausforderung gewachsen ist. Es bietet
mit seinem Linux-Unterbau einen erfrischenden neuen Rahmen, eigene
Steuerungen frei von Lizenzbedingungen zu implementieren und zu
testen. Da ich Lizenzen, nach meiner persönlichen Auffassung, nicht
als zukunftssicheres Geschäftsmodell erachte, widmete ich dieser
Thematik kein eigenes Kapitel unter „Kosten“. Zu vernachlässigen
ist diese Ersparnis aber bei weitem nicht.
In der
Regel entkommt man dadurch ebenfalls einer firmen-kontrollierten
Update-Politik. Dies ist ein enormer Sicherheitsgewinn. Im Ernstfall
werden Haftungsangelegenheiten so lange weitergegeben, bis eine
technische Klärung nicht mehr sinnvoll statt finden kann. Als
Unternehmer agiert man dadurch auf Messers Schneide.
Mit hochintegrierten Geräten
Heutige
Smartphones sehe ich als technologische Weiterentwicklung der
Personal Computer an. Zum Einen, weil sie mit der Tradition
des-immer-schneller brechen und zum anderen, weil sie sich einer ganz
gravierenden Schwäche angenommen haben, nämlich der Bedienbarkeit
von Computer-Systemen.
Was nützt
einem die schnellste CPU und das mühsam auf Geschwindigkeit hin
optimierte Programm, wenn der Benutzer auf die Bearbeitung seiner
Eingaben warten muss oder er zu 'langsam' für die Anlage ist.
Werden
Geräte unter der Prämisse: der guten Bedienbarkeit gebaut, werden sie zwangsläufig
kleiner und fühlen sich schneller an. Für dieses Erlebnis wurde das
Konzept Multitasking (besser: Multithreading) weiter gedacht.
Gemeint
ist mit der Überschrift der hochintegrierten Geräten, die moderne
Ganzheitlichkeit eines EDV-System auf kleinstem Raum. Schnelle
Prozessoren, unbegrenzter Speicherplatz, die Verbindungsmöglichkeiten
über mehrere Wege und die Bedienbarkeit ohne zusätzliche
Peripherie.
Eine
Zukunftsvision schon jetzt in der Hosentasche.
Ein
Alles-in-Einem bietet ein Smartphone selbstredend nicht. Die
Netzwerkfähigkeit macht es möglich das System Android zur Steuerung
von Anlagen zu verwenden. Sei es als weitere Schicht über den schon
bestehenden Anlagen oder als exklusive Baugruppe.
Eine
Variante ist die Regel- und Steuerungsmöglichkeit über das
IOIO-Board und entspricht dem oben genannten Beispiel eines
Android-Systems von ca. 200€.
 | |
| Konventioneller Hardwareaufbau |
 |
| Hardwareaufbau bei Android |
Mit einer modernen Entwicklungsumgebung
Ein
Programmierer muss ständig einen Überblick über das ganze Projekt
besitzen und dieses effizient verwalten können. Weiterhin muss er
sich auf Details konzentrieren können und das Ganze bei
unterschiedlichen Programmiersprachen. Ein weiterer Pluspunkt wäre
eine optimale Bildschirmausnutzung der Arbeitsflächen.
Weiterhin
wird heutzutage von einer IDE erwartet, dass ein Debugging an der
laufenden Anlage möglich ist. Alleiniges Beobachten reicht nicht
aus.
Das
können nur Entwicklungsumgebungen mit einem Plugin-System. Sie
vereinen dadurch effizient das verteilte Arbeiten bei mehreren
Programmierern am selben Quellcode oder das Ausgliedern von Arbeit,
wie die Erstellung von Benutzeroberflächen (GUI) von geschultem
Personal.
Diese
Arbeitsteilung ist evident und sollte von Projektverantwortlichen
forciert werden! Die Realität im Anlagenbau sieht sonst so aus, dass
ein gelernter Elektriker für alles (!) Nichtmechanische zuständig
ist.
Kosten
-->
Material
Nun
kommen wir zu dem interessantesten Teil dieser Abhandlung. - Kosten.
Eine wesentliche Größe für mittelständische Unternehmen, die
nicht in großen Stückzahlen produzieren, sind die Materialkosten
die ein effektives Engineering ermöglichen.
Durch
meine Beobachtung ist mir aufgefallen, das Unternehmen ihr
Hauptaugenmerk auf den reinen Materialwert richten und die
Programmierung als ein schnelles Handwerk verstehen. - Ähnlich dem
Schweißen beim Material Stahl.
Werden
die reinen Materialkosten der Steuerung betrachtet, lässt sich diese
Aufstellung machen:
Konventionelle
Steuerung:
- CPU [1000€]
- 16x Digitale Eingänge [300€]
- 16x Digitale Ausgänge [300€]
- 8x Analoge Eingänge [500€]
- 7Zoll Anzeigegerät [1000€]
Android:
- CPU & 7Zoll Anzeigegerät [100€]
- 32x Digitale Eingänge/Ausgänge (gemischt) [100€]
- inkl. 4x Analoge Eingänge/Ausgänge (gemischt)
Diese
Ausgaben sind über einen sehr großen Daumen gemacht worden und stehen für
einen sehr einfachen Typ von Anlage und ist somit nicht
repräsentativ. Sie stellen aber sehr gut die Menge an Utensilien und
eine Größenordung der Kosten dar.
Und es
geht noch schockierender!
Bei der Programmierung
Realistisch
gesehen ist der größte Posten bei der Fertigung einer Anlage, nach
Material und Entwicklung, die Implementierung und das Testen eines
Programms.
Haefig wird bei der Auftragsvergabe der tatsächliche Aufwand hierzu klein
gerechnet. Und dies noch nicht einmal mutwillig, da hier schon
Objektorientiert gedacht wird. Soll heißen: „Die und die Teile der
Anlage haben wir schon mal gebaut“, also ist auch ein Teil des
Programms fertig. Das ist ein Trugschluß!
Wie oben
schon erwähnt sind die Programme bei einer herkömmlichen SPS
sequenziell aufgebaut. „Den Teil der Anlage“ gibt es
Programmtechnisch gar nicht.
Die
Informatik hat auch hierbei eine Entwicklung gemacht. Die
Objektorientierte Modellierung und Programmierung von Lösungen
bilden die Problemstellungen der Wirklichkeit besser nach, als es
Sequenzen könnten. Bei Sequenzieller Programmierung hat man das
Dilemma, auf ein Ereignis zum nächsten Schritt zu warten. Erscheint
dieses nicht, wird das dazugehörige Programm schnell
unübersichtlich, weil immer mehr Ausnahmen hinzugefügt werden
müssen, um weiter zu kommen.
Diese
Ausnahmen, die den Quelltext aufblähen und etwas programmieren
lassen, was eigentlich gar nicht zur Problemstellung gehört, lässt
die Implementierungskosten explodieren.
Ein
weiterer Kostenfaktor ist die Entwicklungsumgebung in der sich der
Programmierer notgedrungen bewegen muss, denn diese können ihn
unterstützen oder bremsen.
Worauf
man sich einigen kann, ist die Reduktion auf das Wesentliche bei
der Programmerstellung. Dazu gehört auch die Prämisse: keine
Medienbrüche! Dies wird aber verlangt, wenn ein einzelner Motor mit
einer SPS verbunden wird. Die von den Mitgliedern des konventinellen Systems
propagierte Versprechen der Modularität wird dadurch
eingelöst, indem es viele Insellösungen gibt, die nur properitär
erreicht werden können.
Hier
fehlt der Standard für eine einheitliche Entwicklungsumgebung.
Solange dieser, für konventionelle Steuerungen, nicht existiert darf
nicht von Innovationssicherheit gesprochen werden!
Versus
Was
macht ein anderes System, in diesem Fall Android, besser oder
schlechter? Diese Frage wird nun auf den folgenden Seiten erörtert.
-->
Aber schon droht wieder Ungemach mit der Zeit... Wollen sich andere Systeme mit der klassischen SPS messen, werden sie sehr wohl nach ihrer Echtzeitfähigkeit beurteilt. In einer späteren Ausarbeitung werde ich versuchen eine Gegenüberstellung der Echtzeitfähigkeiten der Systeme zu erarbeiten.
-->
 |
| Moorsches Gesetz - Rechenoperationen pro Sekunde |
Prozessor
Es ist allgemein bekannt, dass Prozessoren immer schneller
werden. Also immer mehr Operationen in einer bestimmten Zeit
erledigen können. Programmiert werden aber immer (!) eine bestimmte
Anzahl Operationen, die schnellst möglich erledigt werden sollen.
Ein Programm schrumpft oder wächst ja nicht während seiner
Abarbeitung.
Eine
speicherprogrammierbare Steuerung arbeitet Zyklusfest, das heißt: In
einer vorgegebenen Zeitspanne müssen alle gewünschten Operationen
erledigt sein, sonst handelt es sich um einen Fehler und beschreibt eine 'harte Echtzeitanforderung'. Dennoch ist dies meiner
Meinung nach ein großer Hemmschuh, da ich während der Entwicklung
nicht vorhersagen kann, ob meine gewünschte Operation in einen
Zyklus passt. Ich bin also ein Getriebener dieses 'Zeitdiktats'. Ein weiterer Nachteil dieser Strategie ist: Die CPU ist
immer beschäftigt. Wie ein Arbeiter am Fließband, welches ständig
läuft, selbst wenn es leer ist.
Ich möchte nicht in Abrede stellen, das dieses Verfahren ihren Reiz hat. Ist dies dem Entwickler einmal in 'Fleisch und Blut' übergegangen, findet er einen konsequenten Rahmen vor, in dem er seine Programme implementieren kann.
Ich möchte nicht in Abrede stellen, das dieses Verfahren ihren Reiz hat. Ist dies dem Entwickler einmal in 'Fleisch und Blut' übergegangen, findet er einen konsequenten Rahmen vor, in dem er seine Programme implementieren kann.
Im
Zuge der immer potenter werdenden Prozessoren kam man zu dem Schluss,
dass eine schnelle CPU effektiver ihre Arbeitszeit verwalten kann,
als es der Programmierer je könnte. Also nicht zu warten bis die
Zeit um ist und Energie verschwenden. Oder im anderen Fall,
überfordert sein, falls mal etwas mehr zu erledigen ist.
Das
Konstrukt des Multitasking, ist das Ergebnis. Es vermeidet, grob
gesprochen, die oben genannten Szenarien am Fließband. Weiterhin empfinde ich es Seegen nicht mehr dem Zeitdiktat zu unterliegen.
 |
| Zyklische EDV |
 |
| Multitasking: Abwechselnd wird immer kurz ein anderer Prozess bedient |
Aber schon droht wieder Ungemach mit der Zeit... Wollen sich andere Systeme mit der klassischen SPS messen, werden sie sehr wohl nach ihrer Echtzeitfähigkeit beurteilt. In einer späteren Ausarbeitung werde ich versuchen eine Gegenüberstellung der Echtzeitfähigkeiten der Systeme zu erarbeiten.
Speicher
Wie
der Name „Speicherprogrammierbare Steuerung“ vermuten lässt, ist
der Speicher der Dreh- und Angelpunkt einer Steuerung. Dieser Dreh- und Angelpunkt findet sich bei jedem EDV-System wieder und ist kein Alleinstellungsmerkmal von SPSen. Jeder
herkömmliche Computer bildet ein Speicherabbild aus den
Eingangszuständen, manipuliert dieses Speicherbild und setzt danach
bedingt die Ausgangszustände.
Die Speicherverwaltung ist ebenso modernisiert worden wie die Prozessorverwaltung. Große
Datenmengen effizient zu verwalten, ist keine Aufgabe für den Programmierer,
beziehungsweise sollte es meiner Meinung nach nicht sein. Für ein reguläres Programm
ist es völlig unerheblich, ob die Daten zur Manipulation sich an
dieser oder jener Stelle im verfügbaren Speicher befinden. Noch
konsequenter: Es muss sogar unerheblich sein, in welchem Speicher
(RAM/ROM/FLASH/Datenträger/...) das Lesen und/oder Schreiben statt
findet.
Es ist mühseelig das eine Bit aus 1000 Bits eines Datenbausteins herauszusuchen. Zumal es sich, bei einer Änderung dieses DB, auch noch verschieben kann.
Es ist mühseelig das eine Bit aus 1000 Bits eines Datenbausteins herauszusuchen. Zumal es sich, bei einer Änderung dieses DB, auch noch verschieben kann.
Eine
große Anzahl Technologien wenden sich diesem Lösungsansatz zu,
darunter: Paging und Swaping, um einige Stichworte fallen zu lassen.
Kommunikation
Bei
dem Stichwort: Kommunikation, wird meistens die Assoziation zum Schlagwort "Vernetzung" hergestellt. Es lässt sich nur schwer eine Prognose treffen, wie sich Geräte in Zukunft miteinander verbinden werden. Stand der Dinge ist eine
möglichst dezentrale und drahtlose Verbindung. Weiterhin geht man
dazu über, dass die Endgeräte selber die Robustheit ihrer
Verbindungen überwachen.
Der größte Umbruch geschieht aktuell mit der Umstellung des IP-Protokolls auf IPv6 und wird sich wahrscheinlich in allen Bereichen große Auswirkungen haben.
Der größte Umbruch geschieht aktuell mit der Umstellung des IP-Protokolls auf IPv6 und wird sich wahrscheinlich in allen Bereichen große Auswirkungen haben.
Speicherprogrammierbare Steuerungen
-->
Sollten die ersten Speicherprogrammierbaren Steuerungen die Relais im Schaltschrank ersetzen, so entspricht der Aufbau der Programmierstile: Anweisungsliste
(AWL), Kontaktplan (KOP) und Funktionsplan (FUP), der Ersetzung von Schaltplänen. So wird das Schaltersymbol auch noch immer so in Form eines
Symbols im FUP dargestellt. Und genauso wie das Lesen von
althergebrachten Schaltplänen vom Menschen sequenziell erfolgt, wird
ein SPS-Programm sequenziell abgearbeitet.
 |
| Gegenüberstellung ausgewählter Programmiersprachen |
Die
bis hier hin angesprochenen Eigenschaften der konventionellen
Anlagensteuerung bieten im Grunde eine ordentliche Darstellung von
gewünschten Abläufen, sind aber sehr beschränkt bei größeren
Projekten und spiegeln nicht die Möglichkeiten der heutigen
Informationstechnik wider.
Heutige Technologien bieten einen viel größeren
Mehrwert, der nicht allein auf reine
Rechenleistung beschränkt ist! In den letzten Jahren hatte es
Fortschritte in den Bereichen: Prozesszeitverwaltung,
Speicherplatznutzung und Konektivität gegeben, die jeweils für sich genommen genug Anlass für
eine Überarbeitung der oben genannten Normen gegeben hätten. Einigen Innovationen möchte ich der klassischen Speicherprogrammierbaren Steuerung nicht absprechen. Nur bleibt das Gefühl, daß man mehr draus hätte machen können.
Bei den Programmierparadigmen ist die Sachlage entsprechend. Aus Erfahrung weiß
ich, dass die Objektorientierte Programmierung (oder besser
Architektur) in einigen Jahren obsolet sein kann, bis dahin ist sie
in der Abbildung der Realität (was Softwareentwicklung ausmacht) das
beste Modell.
Die
Abarbeitung einer Vorgabe nach dem Muster:
„Tue
das, wenn das und danach tue das, wenn das“, entspricht einem
Computerverständnis einer längst vergangenen Epoche.
Die
lange Halbwertszeit konventioneller Steuerungen wird gerne als
Argument für ihre technische Überlegenheit und Robustheit
herangezogen. Und fürwahr leisten einige Entwickler wirklich robuste Steuerungen. De facto sind sie es aber nicht und es hängt vielmehr von dem Geschick des Programmierers ab, was er aus den Gegebenheiten macht.
Der
durch die Medien bekannte Schädling „Stuxnet“
hat im Jahre 2010 die Grenzen der Robustheit aufgezeigt. Ergo sind
alle Speicherprogrammierbare Steuerungen genauso robust wie
vergleichbare Systeme, aber nicht so flexibel wie diese, die sich
schon seit geraumer Zeit mit eben dieser Thematik beschäftigen.
Warum sind diese Systeme also so etabliert und unantastbar? Darüber lässt sich nur mutmaßen. Meine Einschätzung ist die Macht des Faktischen, wenn ein Unternehmen nur die Begrifflichkeiten des Marktführers kennt und diese bei allen ausführenden Organen benennen kann. Zusätzlich gehört zu jedem gutem Marketing eine Geschichte, die sich gut erzählen lässt und auf eine einfache Formel herunter gebrochen werden kann, wie zum Beispiel: "Kontinuität = Stabilität + Sicherheit".
Warum sind diese Systeme also so etabliert und unantastbar? Darüber lässt sich nur mutmaßen. Meine Einschätzung ist die Macht des Faktischen, wenn ein Unternehmen nur die Begrifflichkeiten des Marktführers kennt und diese bei allen ausführenden Organen benennen kann. Zusätzlich gehört zu jedem gutem Marketing eine Geschichte, die sich gut erzählen lässt und auf eine einfache Formel herunter gebrochen werden kann, wie zum Beispiel: "Kontinuität = Stabilität + Sicherheit".
Erläuterung
-->
Als gelernter Elektroinstallateur und studierter Ingenieur der technischen Informatik sind mir in meiner beruflichen Laufbahn immer wiederkehrende Aussagen aufgefallen, die während der Planung und der Ausführung eines Projektes gemacht werden.
Um es deutlicher zu sagen:
Von diesem Aufsatz geht keine Rebellion gegen Markenhersteller aus, noch ist es in meinem Interesse gestandenen Programmierer ihre gewohnte Arbeitsumgebung weg zu nehmen.
Ich glaube aber, das viele gute Steuerungen einen zweiten Frühling in einem anderen System erleben und Entwicklungsprozesse optimiert werden könnten.
Ein
Titel wie: „Konventionelle Anlagensteuerung vs Android“, ist erst
einmal sehr reißerisch gewählt. Auf dem zweiten Blick lässt sich
daraus ablesen, dass das System „Android“ sich diesen
Vergleich stellen kann.
Als gelernter Elektroinstallateur und studierter Ingenieur der technischen Informatik sind mir in meiner beruflichen Laufbahn immer wiederkehrende Aussagen aufgefallen, die während der Planung und der Ausführung eines Projektes gemacht werden.
Diese
Aussagen betreffen ein Produkt welches sich als Standard seit 30 Jahren
nicht stark weiterentwickelt hat. Die Normen EN 61131 bzw. IEC 61131 (als
Nachfolger der DIN 19239) haben zweifelsohne ihre Berechtigung,
stehen sie doch für Planungs- und Innovationssicherheit im
steuerbaren Anlagenbau.
Das System aus Prozessoren, Bussystemen und mit ihnen verbundenen
Sensoren und Aktoren arrangieren sich starr um diesen Standard. Zusätzlich orientieren sich die Entwicklungsumgebungen zur Programmerstellung,
sowie die Geschäfts- und Entwicklungsprozesse an diese Normen,
obwohl diese das gar nicht hergeben.
Es gibt jedoch Lösungen und Standards, die diese konservative Sichtweise vielleicht ablösen könnten. Einige davon werde ich in diesem Aufsatz vorstellen.Um es deutlicher zu sagen:
Von diesem Aufsatz geht keine Rebellion gegen Markenhersteller aus, noch ist es in meinem Interesse gestandenen Programmierer ihre gewohnte Arbeitsumgebung weg zu nehmen.
Ich glaube aber, das viele gute Steuerungen einen zweiten Frühling in einem anderen System erleben und Entwicklungsprozesse optimiert werden könnten.
Abonnieren
Posts (Atom)