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!