Wie viele von Euch sicher schon wissen, hat HeiReS eine App mit dem großen Namen – Industrial Measurement And Control Engine (zugegeben der Name ist nicht von mir aber macht was her) im Windows Store veröffentlicht.
Kurz zur Entstehungsgeschichte der App, bevor auf ein paar technische Details eingegangen wird. Angefangen hat alles mit der Diplomarbeit von Alex (Alexander Witkowski) am Institut für Automatisierungstechnik der TU-Dresden. Um den trockenem Thema (Untersuchungen zur aspektorientierten Umsetzung von Modell-zu-Text-Transformationen für Benutzungsschnittstellen) mit einem praktischen Zusatz etwas Pepp zu verleihen, wurde als Fallstudie eine kleine Windows 8 App generiert.
Nach erfolgreich abgeschlossener Arbeit konnte Alex uns alle bei HeiReS davon überzeugen, die App weiter zu entwickeln. Mit der Hilfe und Einwilligung der TU-Dresden wurde aus der einfachen Fallstudie eine vorzeigbare Anwendung die einen Blick darauf zulässt, wie zukünftige Systeme zum Bedienen und Beobachten von Industrieanlagen aussehen könnten. Weiterhin dient sie der Technischen Universität Dresden als Lehrobjekt, wodurch die Einstufung im Store unter “Education” begründet ist.
Aus technischer Sicht wird ein grober Überblick darüber geben, wie die App Daten mit der Anlage austauscht. Auf weitere Details wie den Einsatz von Portable Class Libraries und damit verbunden der portablen Version von MVVM Light, gehen wir bei Interesse gern in einem späteren Blogpost ein.
Welche Möglichkeiten bietet WinRT uns um mit einer Industriellen Anlage zu kommunizieren?
Nun, die Möglichkeiten sind vielfältig, lassen sich aber eingrenzen. So ist eine direkte Anbindung über eine serielle Kommunikation oder eine Hardware-Erweiterungskarte recht aufwendig, da aus Store Apps heraus nur mit einem extra für die App entwickeltem und signiertem Treiber auf die Hardware zugegriffen werden kann.
Leichter wird die Sache, wenn man über Schnittstellen einer “höheren Ebene” auf die Prozessdaten zugreifen kann. Mit HTTP und TCP Sockets gibt einem WinRT in diesem Bereich viele Möglichkeiten an die Hand. Aber wie kann man diese im Industrieumfeld nutzen? Dazu nennen wir einige recht verbreitete Kommunikationsstandards und gehen kurz darauf ein, wie man diese auch mit WinRT umsetzt.
- Modbus TCP – der Zugriff ist mit den TCP Sockets grundsätzlich möglich, eine Anbindung aber trotzdem mit etwas Aufwand verbunden, da die Kommunikation selbst implementiert werden muss.
- OPC (DA, A&E, HDA) – Ähnlich wie Modbus TCP ist auch eine Kommunikation mit OPC theoretisch möglich. Hier ist die notwendige Eigenimplementierung aber wesentlich umfangreicher, so dass es günstiger ist einen Gateway zwischen zu schalten (z.B. OPC DA -> OPC XML DA) oder einen eigenen Proxy ( z.B. OPC -> WCF) zu entwickeln.
- OPC XML DA – OPC XML DA ist mit einer Kommunikation über HTTP und der XML-Struktur der Daten sehr gut geeignet um eine Prozesskommunikation für WinRT zu implementieren. Mit OPC XML DA wurden die Prozessdaten in den Fallstudien Apps (es waren zwei Apps, die mit unterschiedlichen Aspekten generiert wurden) übertragen.
- OPC UA – Bei OPC UA gilt es, die einzelnen Versionen zu unterscheiden. Die reine Binary-Ausführung dürfte einiges an Implementierungsaufwand mit sich bringen, dank TCP Sockets aber grundsätzlich möglich sein. Am leichtesten zu implementieren sollte die SOAP Variante sein, so diese denn zur Verfügung steht (was ein festes Vorhandensein im Standard voraussetzt 😉 ). Ebenfalls mit überschaubarem Aufwand kann der Hybridmodus implementiert werden, da hier die Daten und Befehle im Binärformat über HTTP übertragen werden. Dies hat auch einen Vorteil bezüglich des bei SOAP (XML) nicht zu unterschätzendem Overhead.
- Eigene Proxydienste (Stichwort WS*) – Wie bereits unter dem Punkt OPC erwähnt, ist es in manchen Situationen sowohl technisch als auch wirtschaftlich von Vorteil, eigene Proxydienste zu implementieren. Die Komplexität fällt meist recht gering aus und sie ermöglichen es, ursprünglich fehlende Funktionalität nachzurüsten. So kommt auch bei der im Store veröffentlichten App ein Proxy-Webservice der Technischen Universität zum Einsatz. Dieser stell sowohl einen Datencache bereit, als auch eine Authentifizierung der Nutzer, welche bei OPC XML DA leider nicht direkt vorgesehen ist.
Mit der Kommunikation ist auch schon der in diesem Post wichtige Teil an technischem Hintergrund besprochen. Für die Darstellung des Livebilds der Kleinversuchsanlage wird der MJPEG Decoder von Gerg Duncan verwendet (ursprünglich habe ich ihn von Silverlight zu WinRT portiert, mittlerweile gibt es eine fertige WinRT-Version).
Um auch Nicht-Studenten einen Einblick zu gewähren, wie die Steuerung der Anlage von statten geht, wird ein Simulationsmodus bereitgestellt, mit dem einige Funktionen ohne Zugriff auf die Anlage ausprobiert werden können.
Screenshot der aktuellen Version im Windows Store |