SourceForge Logo

Arbeitsprinzip:

Ein lokaler Computer sammelt Meßdaten und Zustandsinformationen von der steuernden SPS oder anderen Meßgeräten über serielle Schnittstellen oder Ethernet. Diese Daten werden in bestimmte Bereiche einer Tabellenkalkulation geschrieben. Die Tabellenkalkulation speichert die jeweils aktuellsten Daten und führt Berechnungen durch, bei denen es sich vor allem um Skalierungsoperationen und Grenzwertvergleiche handelt. Um diese Daten anzuzeigen und ein Eingreifen in die Maschine zu erlauben, läuft ein zweites Programm auf demselben oder einem/mehreren weiteren Computer(n), das mit dem ersteren kommuniziert. Es zeigt die Daten auf grafischen Bildschirmseiten an, die Anzeige- und Bedienelemente enthalten.

Bestandteile:

Ich werde das zweite Programm im folgenden "HMI(human machine interface) Viewer" nennen. Ich glaube, daß seine Arbeitsweise am besten anhand einiger Bildschirmkopien und interaktiver Demos dargestellt werden kann, die auf diesen Seiten vorgestellt werden.
Demo-Version eines Bedienbildschirms

Das zuerst erwähnte Programm besteht aus einem Hauptprogramm und zwei Kategorien von ladbaren Modulen. Die erste Art dieser Module dient dazu, mit einer bestimmten SPS zu kommunizieren (SPS Treiber). Die zweite Art von Modulen will ich Datenlogger oder -recorder nennen. Ein Recorder speichert Daten auf ein nichtflüchtiges Medium; immer wenn sich die Daten verändern oder zu regelmäßen Zeitpunkten. Der Rest des Hauptprogramms besteht in der Verwaltung der Tabellenkalkulation und einer Editor/Betrachter-Komponente um die Tabellen zu erzeugen und zu verändern.

Tabellenkalkulation

Warum eine Tabellenkalkulation? Die Tabellenkalkulation selbst stellt ein verbreitetes Konzept für kaufmännische Berechnungsprogramme dar. Sie liefert einen einfachen Ansatz, um Formeln zu erstellen, zu modifizieren und zu korrigieren. Ein Vorteil gegenüber anderen Konzepten, die etwa Datenbanken in Verbindung mit speziellen Programmiersprachen und compilerähnlichen Werkzeugen einsetzen, ist, daß man die Auswirkungen von Veränderungen im gleichen Moment ansehen kann.
Im Unterschied zu typischen Büro-Tabellenkalkulationen berechnet VISUAL alle Werte regelmäßig neu. Dies weist eine Analogie zum Programmzyklus einer SPS auf:
SPSVISUAL
Einlese der ProzeßeingängeEmpfang der Daten vom SPS-Treiber
Einmalige Ausführung des ProgrammsNeuberechnung aller Formeln
Aktualisieren der ProzeßausgängeNeue Werte an Bildbetrachter und Recorder ausgeben
Zyklus wiederholenZyklus wiederholen

Datenlogger

Datenlogger können Daten auf verschiedene Weise zur Dokumentation oder zur Auswertung sichern. Ein Recordertyp schreibt den aktuellen Wert einer Koordinate der Tabellenkalkulation (Zelle) fortlaufend in eine korrespondierende Binärdatei. Dies ist nützlich, um große Datenmengen zu speichern und sie nachher nach Art eines Papierschreibers grafisch darzustellen. Ein weiterer Recorder schreibt Daten aus verschiedenen Quellen (Zellen und Kalkulationsblätter) in eine Textdatei, wobei er die Werte in einen festen Text einbettet. Dies dient zum Speichern von Alarmhistorien oder zum Protokolldruck. Ein dritter Typ von Recorder kann Daten aus verschiedenen Quellen in eine Datenbank übertragen.

Umsetzung:

Das Hauptprogramm

Das Hauptprogramm ist in C++ geschrieben. Es wertet eine Konfigurationsdatei in dem Verzeichnis aus, in dem es gestartet wird. Die Konfigurationsdatei definiert, wo die Tabellendateien zu finden sind, wo die SPS-Treiber und die Recorder-Module liegen und welche von ihnen in der jeweiligen Anwendung benutzt werden. Gegenwärtig enthält das Hauptprogramm einen Betrachter/Editor für die Kalkulationsblätter. Dies ist eine textbasierte Anwendung die TURBOVISION und Curses nutzt.
Es ist geplant, den Tabellen-Editor vom Hauptprogramm abzutrennen, das dann als Dämon ausgeführt werden könnte. Dies würde eine Ausgabekonsole unnötig machen und den Zugriff auf autorisierte Benutzer beschränken und schließlich netzweite Bedienung via Telnet oder Web ermöglichen.
SPS-Treiber und Recorder sind als ladbare Module implementiert und verwenden shared objects.
Ein SPS Treiber started einen eigenen Thread, der die eigentliche Kommunikation durchführt. Dadurch wird erreicht, daß Wartezeiten auf die Antworten externer Geräte den Ablauf des Hauptprogramms nicht verzögern. Der Treiberthread arbeitet eine Liste "Transfer instruction list" von Befehlen ab. Diese beschreiben einen Datenblock, der von dem angeschlossenen Gerät gelesen oder dorthin geschrieben werden soll. Am Ende der Liste beginnt die Abarbeitung von neuem. Bedingte Bearbeitung kann mittels einer Bedingung pro Anweisung erfolgen. Die Bedingung besteht darin, daß der Inhalt einer angegebenen Zelle der Tabellenkalkulation nicht Null ist.
Recorder stellen dem Hauptprogramm eine "callback routine" zur Verfügung, die von diesem bei Änderung der Daten aufgerufen wird. Beim Startvorgang läßt sich der Recorder beim Hauptprogramm registrieren und markiert diejenigen Daten (Zellen), an denen er interessiert ist (sein muß?).
Das Hauptprogramm kann ein Server-Modul laden, das die Daten aus der Tabellenkalkulation über TCP/IP-Verbindungen bereitstellt oder/und von diesen annimmt. Auf diese Weise steht eine Verbindung zu Betrachtern oder weiteren Instanzen von VISUAL bereit, die auf einem entfernten Computer laufen. Diese Schnittstelle kann ebenso benutzt werden, um Daten aus einer Datenbank zu VISUAL zu übertragen z.B. zur Rezeptverwaltung. Als ein Sonderfall eines "SPS-Treibers" kann ein "Client" Treibermodul geladen werden, daß mit einer anderen Instanz von VISUAL kommuniziert.

HMI Betrachter

Eine HMI-Seite besteht aus einem feststehenden Hintergrundbild und dynamischen Elementen wie Anzeigen, Potentiometer, Schalter u.s.w.. Der feste Hintergrund dient der schematischen Dastellung einer Maschine, Anlage, Produktionstätte oder des Prozeßablaufs.
Der HTML-Betrachter
Zurzeit existiert ein Betrachter in Form eines JAVA-Applets. Es verbindet sich mit dem Server_Modul des Hauptprogramms, holt die benötigten Daten und stellt sie dar. Änderungen der Daten durch Bedienereingriff werden in derselben Weise über diese Verbindung weitergereicht. Das Betrachter-Applet entnimmt die Definitionen der dynamischen Elemente aus seinen Parametern. HTML-Seiten, die dieses Applet einbinden, können durch PHP- oder andere CGI Programme generiert werden, die Parameter ensprechend der Maschinenbezeichnung oder Grenzwerte aus einer Rezeptdatenbank bereitstellen. Seitenwechsel können entweder durch Verweise im umgebenden HTML oder durch dynamische Elemente im Applet selbst erfolgen. So kann man z.B. eine Detaildarstellung durch Klick auf ein Symbol in einer Übersichtsdarstellung erhalten.
Der JAVA Betrachter ist einfach durch neue Klassen erweiterbar. Am Beginn jedes "value tags" steht der Name einer Klasse. Dieser wird mittels JAVAs "class for name"-Methode ausgewertet.
Weitere Anzeigeelemente für spezielle Anforderungen sind leicht durch eigene Klassen realisierbar.
Weitere HMI-Betrachter
Ein auf der SVGAlib basierender Betrachter befindet sich in Entwicklung. Dieser Betrachter wird genau dieselbe Anzeige liefern wie die Applet-Variante, aber im Vollbild-Modus. HTML-Verweise (Links) stehen nicht zur Verfügung. Der SVGA-Betrachter versteht dieselben Parameterzeilen wie das JAVA-Applet. Er ist in C++ geschrieben, wobei versucht wurde, die Struktur der JAVA-Implementation so möglichst genau nachzubilden. Ein Mechanismus, um Erweiterungen wie mittels JAVAs "class.forName" einzubinden, ist verfügbar. Leider wird es damit erforderlich, für jede Erweiterung einen JAVA und einen C++ Quelltext zu schreiben, um sie in beiden Betrachtern zu nutzen. Aber bei einem Blick auf existierenden Quellcode zeigt sich, daß ein neues Element in 20 bis 80 Zeilen Quellcode realisiert werden kann und nicht so viele Unterschiede zwischen JAVA- und C++ -Implementation bestehen. Dies ist nach meiner Meinung besser, als eine umfangreiche JVM zu implementieren, die eine AWT-Emulation auf SVGA bereitstellt.
Sobald der SVGA-Betrachter benutzbar ist, wird er auf den LINUX-Framebuffer portiert. Dies sollte eine minimale Codegröße für "embedded systems" ergeben.
Und was ist mit X11?
Meine jetzige Meinung (mag sich mit guten Gegenargumenten ändern): Um eine Maschine zu bedienen braucht man den ganzen Bildschirm und keine Fenster. Wenn man schnell reagieren muß soll man nicht erst in einem Stapel von Fenstern nach einem Schalter oder Potentiometer suchen müssen. Außerdem sollte man ein rotes Anzeigefeld z.B. in immer derselben oberen rechten Ecke sehen, so daß schon aus der Entfernung deutlich wird, daß hier eingegriffen werden muß. Kein anderes Fenster sollte so etwas verdecken. Das JAVA/Web-Interface ist für Überwachungszwecke vorgesehen, wenn man im Büro sitzt und etwas über einee Maschine wissen will. Der Vollbild-SVGA-Betrachter sollte dagegen auf einem lokalen Computer nahe bei der Maschine laufen und zur Bedienung dienen. Dort braucht man keine konkurrierenden Fenster auf demselben Bildschirm. Man kann vielleicht einen Standard-PC als lokalen Computer an der Maschine einsetzen. Der wird ausreichende Resourcen für X11 oder SVGAlib bieten. Aber um ein Vollbild für den Bedienbildschirm zu erhalten, müßte X11 ohne Windowmanager laufen. Wenn jemand doch Fenster möchte und die nötigen Resourcen hat, so mag er X11 und einen Web-Browser benutzen. Wenn der lokale Rechner beschränkte Resourcen hat (embedded system) wird der Framebuffer die bessere Wahl sein.
Andere Web-Betrachter
Ein Betrachter für Trenddiagramme wird als JAVA-Applet realisiert. Er kann ein oder mehrere Trendlinien anzeigen. Er wird in eine HTML-Seite eingefügt, welche durch ein PHP-Skript generiert wird. PHP kann die nötigen Daten aus den Binärdateine extrahieren und sie dem Applet als Parameter übergeben. Ein Betrachter für Protokolldruckk oder Alarm-Historien läßt sich als PHP-Skripte realisieren, die reine Textzeilen aus den jeweiligen Files entnehmen und in HTML einfügen.
Weitere lokale Betrachter
Die Funktion zum Anzeigen von Trendgrafiken wird als eigenständiges C++ Programm erfolgen, welches die Werte aus den binären Dateien entnimmt und sie auf dem VGA- oder Framebuffer-Bildschirm zeigt. Ein text Betrachter für Protokolldruck könnte mittels SVGAlib/Framebuffer oder als Text/Curses-Anwendung realisiert werden.