JANUS:

Trotz aller Vorteile der universellen Maschinensteuerung ROBOT, es existieren auch ein paar konzeptionelle Nachteile:

• Betriebssystem Microsoft Windows

  • auch mit Tricks kann nur eine annäherende Echtzeitfähigkeit erreicht werden
  • durch die Microsoft Produktpolitik steigen die Hardwareanforderungen mit jedem Update
  • der Datenmüll wird immer größer und damit das System instabiler

• Driverproblematik
  Um Hardwarehersteller dazu zu bringen, Treiber für ein bestimmtes System anzubieten, muß man schon ein paar Nummern größer bzw. mächtiger sein. Gängige verfügbare Treibermodelle zu integrieren, ist zu ineffizient. Damit kann sich ein Flaschenhals beim Softwarehersteller bilden.

• Investitionsschutz
  Bewiesenermaßen ist das größte Problem bei der Vermarktung die Angst des Kunden vor "propertären" Produkten (unabhängig was man darunter versteht - ich arbeite gerade an einer Programmerweiterung einer Maschine von 1986, vom "Industriestandard" hört man "da müssen Sie halt umrüsten").

So bitter es für mich auch ist (schließlich will ich ja mit meinen Programmen Geld verdienen), so sinnvoll scheint es auch zu sein, ROBOT auf eine breitere Basis zu stellen, und dieses heißt "Open Source" (GPL) auf Linux. Hier existieren ernsthafte Echtzeit- und industrielle Erweiterungen, durch "Open Source" ist keinerlei Properität vorhanden, Flaschenhälse in der Softwareerstellung können durch eine größere Entwicklungsgemeinde weitestgehend vermieden werden.

Unter Linux ist nicht alles Gold was glänzt, manche SourceCodes sind indiskutabel, aber man kann selbst Hand daran anlegen und aus mehreren Alternativen ein vernüftiges System zusammenbauen. Basierend auf meinen bisherigen Erfahrungen möchte ich die Anforderungen einer Maschinensteuerung der 4. Generation zur Diskussion stellen.

Anforderungen:

Eine SoftSPS nach IEC 61131 war lange schon vor ihrer Normierung nicht mehr zeitgemäß. Das Hauptargument der standardisierten Ausbildung kann man leicht dadurch beurteilen, wenn man einen Technikerabsolventen vor eine Maschine setzt. Außerdem ist der "Klapperatismus" einer Maschine nur eine der Aufgaben, eine echte Maschinensteuerung muß viel mehr können (siehe hierzu auch komplexe Verarbeitungsmaschine).

• Objektorientierung
  In der Verwaltungssoftware ist die objektorientierte Programmierung gang und gäbe, in der Maschinensteuerung noch weitestgehend unbekannt.
  

  • Grundlagen der maschinellen Objektorientierung
  • Beispiel eines Maschinenobjektes

• Abstraktion
  Die Ablaufprogrammierung muß einfach sein, schließlich sitzen hier anwendungsorientierte Techniker und keine informatisch ausgebildeten Programmierer. Hinzu kommen zusätzliche Streßfaktoren während der Inbetriebnahme.
  Zum Beispiel ist alles im Programm eine Variable. Wird auf eine Ventilvariable der Wert 1 geschrieben, so bewegt sich das Ventil, bei einer Visualisierungsvariable entsteht je nach eingestellter Sprache der Wert "EIN", eine Motorvariable bewegt den Motor auf die gewünschte Position.

• Datenbank
  Alles (Programme, Daten, Dokumentationen,...) wird in einer Datenbank gespeichert. Dadurch werden folgende Probleme vereinfacht:

  • Versioning
  • gleichzeitiger Zugriff
  • Datensicherung und -wiederherstellung
  • Datenkonsistenz (Transaktionen)
  • Umstiegsmöglichkeit auf andere Systeme

• Schnittstellen
  Schnittstellen sind das A & O bei der Integration von Maschinen in vorhandene Architekturen. Eine Black-Box-Sicht einer Maschine ist ein stark vereinfachter Scheuklappenblick, der sich bei der Kundenintegration furchtbar rächt. Ein zuviel an Schnittstellen gibt es nicht, hier und heute heißt dieses, auch aus Preisgründen, ein PC mit einem modernen Betriebssystem.

• Verfügbarer SourceCode
  Als Investitionsschutz für den Kunden muß der SourceCode der Steuerung und des Applikationsprogrammes verfügbar sein.

• integrierte Handvisualisierung
  Auf Basis der Objektorientierung muß jedes Objekt auch eine elementare Handvisualisierung bieten, ohne daß der Programmierer auch nur eine Zeile Code erzeugen muß. Cointainer bzw. Objektlisten können darauf aufbauend auch eigene, funktional abgegrenzte, Visualisierungsseiten automatisch erzeugen. Damit existiert zu jedem Zeitpunkt eine funktionsfähige Hand- und Inbetriebnahmevisualisierung ohne jeden Aufwand.

• integrierte Visualisierung
  Diese stellt das Hauptinterface des Bedieners zur Maschine dar und sollte "schön" sein. Sie muß einfach zu erzeugen sein, alle graphischen Möglichkeiten bieten und Zugriff auf alle Maschinenelemente haben.

• Entwicklungstools
  Alle benötigten Entwicklungswerkzeuge müßen Teil des Systems sein (die Entwicklungsumgebung kann jedoch paßwortgeschützt sein). Damit können Anpassungen direkt und online erfolgen. Für den Applikationsingenieur ist es nervig, erst das alte Konfigurationstool von 1991 auf einem neuen Notebook zum Laufen bringen zu müssen, der Kunde muß nicht extra einen Techniker mit Programmiergerät von 500 km Entfernung holen, nur um eine Verzögerungszeit anzupassen.

• Dokumentationen
  Die Maschinenunterlagen, Schaltpläne, externe Dokumentation müssen Teil des Systems sein. Der übliche Projektordner ist nicht immer verfügbar, im Schaltschrank verstaute Schaltpläne sind meistens entweder veraltet, unlesbar oder verschwunden. Das Format der abgelegten Dokumentationen muß allgemein verfügbar sein, z.B. HTML, JPEG, GIF.

• Schaltpläne
  Ein wichtiger Sonderfall der Dokumentation sind die Schaltpläne. Durch den engen Zusammenhang zwischen Programmierung und Elektrik/Elektronik können diese zu einem großen Teil automatisiert erstellt werden, auch bedingen sich Elektrik/Elektronik und Ablaufprogrammierung gegenseitig.

  • Schaltpläne in komplexen Verarbeitungsmaschinen
  • Elektrische Verbindungen in ROBOT

• Protokollierung, Betriebsdatenerfassung, ISO9000
  Ausgewählte Ereignisse müssen zur Protokollierung, zur BDE oder aus Nachweispflicht in eine Protokolldatenbank geschrieben werden können. Dieses ist durch die Verkettung von Datenbank, Ablaufsteuerung und Visualisierung mit minimalem Aufwand möglich.

• Journaling
  Im Gegensatz zur Protokollierung nimmt das Journaling alle Ereignisse auf. Das Journaling arbeitet ähnlich der Blackbox eines Flugzeuges, das kontinuierlich die letzten Minuten aufzeichnet, bzw. auf Wunsch gestartet wird. Mit der Playbackfunktion können damit kritische Maschinenzustände und heikle Einstellungen beliebig nachverfolgt werden.

• Tasks, Unterprogramme, Abläufe
  Die gängige Ablaufprogrammierung mit Verriegelung und Maschinenzuständen wird deutlich einfacher, wenn nach Bedarf ein parallellaufender Task oder Ablauf gestartet werden. Bei Aktivierung führt er seine Aufgabe aus, liefert evtl. einen Status und kann bei Nichtbenötigung gestoppt werden. Die wartbaren Einheiten werden kleiner und überschaubarer, Maschinenzustände deutlich logischer programmierbar. Durch Benutzung von Unterprogrammen werden Standardaufgaben leichter wartbar und wiederverwendbar.

• Online Programmierung
  Soweit irgendwie möglich, muß die Programmierung Online erfolgen können, alle Änderungen werden sofort aktiv, das Maschinenverhalten kann direkt beeinflußt und optimiert werden. Zur Fehlersuche ist ein integrierter Online-Debugger Vorraussetzung.

• Erweiterbarkeit
  Es muß möglich sein, das System nach Wunsch erweitern zu können, sei es mit neuen Hardwaretreibern, eigenen Modulen (z.B. eine spezielle Einschaltroutine), weiteren Funktionen (z.B. Regler) oder neuen Bildelementen.

• Baumstruktur
  Die Treedarstellung, und eine davon abhängige Detaildarstellung in einem zweiten Fenster, hat sich in der Praxis bewährt. Durch die integrierte Baumstruktur ist die Übersichtlichkeit des Systemes gewährt, durch die verfügbare Funktionalität des Trees wird die Programmierung deutlich erleichtert.

• Autoadjust-Fähigkeiten
  Bei der Inbetriebnahme muß man sich recht häufig mit den einzustellenden Parametern spielen. Hier ist ein zuschaltbares AutoAdjust, das die Parameter empirisch automatisch ermittelt, gerade bei Motoren oder Heizungen, enorm zeitsparend.

• Feldbusse
  Da jeder Kunde andere Wünsche und Vorraussetzungen hat, müssen alle Feldbusse untersützt werden. Am einfachsten geht das mit einer Hilscher Feldbuskarte und Benutzung des Hilscher API. Optimalerweise dürfen jedoch keine externen Konfigurationstools notwendig werden, die an den Feldbus angeschlossenen Elemente müssen online automatisch erkannt werden können.

• Real Ethernet
  Ethernet scheint die Zukunft auch in der Automatisierungstechnik werden zu wollen. TCP/IP kann wahrscheinlich nicht echtzeitfähig werden, aber IP und UDP sind bereits verfügbar.

• Fernwartung, Multiuserfähigkeit
  Das System muß gleichzeitig von verschiedenen Stellen gewartet werden können. Während der eine die Visualisierung verschönert, kann der andere einzelne Baugruppen optimieren. Die verschiedenen Änderungen müssen online einfließen, und damit online testbar sein (Durch den Einsatz einer TCP/IP fähigen Datenbank fast schon als Abfallprodukt verfügbar).

• Prototyping
  Gerade im Sondermaschinenbau ist eine schnelle Validierung der Verfahrenstechnik und der Mechaniklösungen notwendig. Wenn neue Teile in einen Maschinenteil eingebaut werden, so müssen diese schnellstmöglich in Betrieb genommen werden können, auch wenn nachher noch Änderungen oder vielleicht sogar eine komplett neue Konzeption nötig werden sollten.
  Hier ist ROBOT mit einem WAGO oder Beckhoff System unschlagbar. Jedes Element muß nur einmal angefaßt werden, Abhängigkeiten werden automatisch berechnet, die Handvisualisierung ist automatisch erzeugt, Standardfunktionalitäten sind bereits vorhanden, Anweisungen für die Elektrik automatisch generiert.
  Eine Vorgehensweise, daß erst die Mechanik fertiggebaut, dann die Elektrik eingebaut und zum Schluß die Steuerungstechnik kommt, können sich nur noch große Firmen leisten ;-)

• Datenhandling
  Im Zuges des LOS Projektes und dessen Nachfolger BBS / BOD kommen die Maschinendaten von externen Eingabestationen (lokal, Netzwerk, Modem), diese müssen komplex umgerechnet und ausgeführt werden. Die resultierenden Produktionsdaten dienen wiederum als Eingabedaten der nachfolgenden Maschinen.
  Der Trend, daß sich Maschinen nach externen Daten einzustellen haben und Betriebsdaten liefern müssen, wird sich weiter fortsetzen, da die Losgrößen immer kleiner werden.
  ROBOT hat als C++ Bibliothek ein integriertes Datenhandling, als Stand-Alone Produkt ist eine geeignet schnelle und flexible Schnittstelle zu implementieren.

• Fehlerhandling
  Eine sinnvolle und angepaßte Reaktion auf auftretende Maschinenfehler ist nicht so einfach. Ausschalten und dann wieder Einschalten und Neusynchronisieren hat meistens den Verlust der bisherigen Halbprodukte in der Maschine zur Folge (Bei einem NotAus ist dieses nicht zu vermeiden). Beim Einsatz einer objektorientierten Exceptionstechnik können Fehler automatisch erkannt, visualisiert und protokolliert werden. Der Ablauf, der den Fehler generiert hat (throw), wartet auf eine entsprechende Reaktion, diese kann automatisch (catch) oder durch einen Benutzereingriff erfolgen. Durch eine geeignete Ablaufprogrammierung warten auch die abhängigen Abläufe auf die Fehlerreaktion, d.h. der Maschinenzustand ist stabil, er kann, falls gewünscht, nach der Fehlerbehebung direkt weiterlaufen.

• Hardwareunabhängigkeit, Preis
  Die Unabhängigkeit von der jeweils verwendeten Hardware ist aufgrund Verfügbarkeit, Ersatzteilhaltung und Einkaufskosten notwendig. Ziel wäre es also, einen Aldi-PC mit Netzwerkkarte als Steuerung zu verwenden :-)

Status ROBOT Anfang 2002:

Der ROBOT-Kernel existiert in dieser Form seit 1991, die Datenbankanbindung, und damit auch die Verlagerung der Ablaufprogramme in die Datenbank, seit 1995. Die Interfaces reichen bis ins Jahr 1984 zurück. Das bis dato vorhandene Scripteingabeverfahren wurde ab 2000 durch eine graphische Eingabemöglichkeit erweitert, allerdings mußte diese recht schnell implementiert werden, so daß hier eine komplette Überarbeitung ansteht.

Ein großer Teil der gestellten Anforderungen ist mit ROBOT bereits gelöst, manche Lösungen müssen jedoch überarbeitet, andere zusätzlich implementiert werden. Durch die Freigabe der ROBOT SourceCodes wäre die erste Hauptarbeit die Portierung vom Windows 32 Bit API auf Linux zu einem, noch zu wählendem, Graphikinterface.

Eine eigene Hardwareentwicklung ist nicht mehr geplant, es wird industrieübliche Elektronik verwendet. Da "industrieüblich" zeitabhängig ist, hat die Software die Kompatibilitätsprobleme abzufangen.