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.

 
 

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]

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:
-->

Erläuterung

Speicherprogrammierbare Steuerung

Versus

Prozessor

Speicher

Kommunikation

Kosten

Material

Bei der Programmierung

Besser geht es...

Mit anderen Standards

Mit hochintegrierten Geräten

Mit einer modernen Entwicklungsumgebung

Zeitgeist

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

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.

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.

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.