Raspberry Pi und (ein wenig) Java im Produktionsumfeld
Noch im vergangenen Jahr hat sich für uns eine tolle Einsatzmöglichkeit für den Raspberry Pi im Produktionsumfeld ergeben. Das war nicht nur für mich eine schöne Möglichkeit, meine Java-Kenntnisse mal wieder aufzufrischen, sondern auch eine Gelegenheit, in Sachen Hardware etwas Neues auszuprobieren.
Die Anforderungen waren relativ überschaubar: Bisher wurden Windows-Terminals, auf denen eigentlich arbeitsplatzspezifische Anwendungen liefen, »missbraucht«, um mit Hilfe einer kleinen C#-Anwendung per USB angeschlossene RFID-Scanner anzusteuern, um auf das »Vorhalten« von passenden Karten zu reagieren. (Der Kenner wird sich schon denken können, worum es dabei ging.) In der Praxis umständlich wurde es, als nicht nur deutliches Feedback der Anwendung (Lautsprecher sind dort nicht verbaut), sondern zusätzlich einfache Interaktionsmöglichkeiten gefordert waren. Zur Erinnerung: im Normalfall liefen auf den Terminals ganz andere Anwendungen.
Der Raspberry Pi war die optimale Lösung für dieses Problem: er bietet mit Linux nicht nur ein ausgewachsenes Betriebssystem auf kleinstem Raum, er ist günstig in der Anschaffung und es gibt vom Hersteller ein passendes günstiges Touchscreen-Gehäuse in optimaler Größe (7 Zoll), das sich für die Wand-Montage eignet. Einen vergleichsweise lauten Buzzer bekommt man auch im Gehäuse untergebracht, über die GPIO-Pins lässt sich dieser ansteuern. Die Auslagerung auf ein eigenes Gerät und einen eigenen Screen verhindert, dass sich verschiedene Anwendungen und Anforderungen »in die Quere kommen«. Ganz nebenbei werden die regulären Arbeitsplatz-Terminals auch in der Produktion mindestens zum Wochenende gerne ausgeschaltet, was wir bei diesem Anforderungsprofil auch nicht gebrauchen konnten.
Entschieden haben wir uns, vor allem aus Gründen der möglichst kurzen Entwicklungszeit, für eine Java-Anwendung. Einziges Problem dabei: Außer mir hatte in meinem Team bisher niemand für den Linux-Desktop entwickelt, erst recht nicht in Java. Großer Vorteil meines tollen Teams: niemand hatte Angst davor. Ich habe das Grundgerüst und das User Interface entwickelt, um Datenbank-Schicht und anderes haben sich die Kollegen gekümmert. Nebenbei: Um Verbindungsproblemen mit dem zentralen Datenbank-Server zu begegnen, kommt hier eine eingebettete SQLite-Datenbank als Puffer zum Einsatz, so dass auch bei Netzwerk-Problemen keine Aktionen verloren gehen.
Für mich bleibt festzuhalten: Ich bin nicht nur erstaunlich schnell wieder »drin« gewesen in Java, sondern habe festgestellt, dass ich die Sprache selbst und auch die Tools darum herum immer noch toll finde. Das Dokumentationswerkzeug Javadoc war seinerzeit eine fantastische Idee und erledigt seinen Job nach wie vor hervorragend (sehr schade, dass es im PHP-Umfeld nichts gibt, das daran heranreicht oder wenigstens zuverlässig läuft und anständigen Output generiert), die Paketierung als Java-Archiv inkl. Bündelung von Ressourcen und Drittbibliotheken ist schnell und einfach erledigt. Und für unser kleines Projekt haben wir das Build-System Ant verwendet, das zwar nicht Bestandteil des JDK ist, aber für ein Projekt dieser Größenordnung genau das richtige ist. Leider wurde anscheinend über Jahrzehnte weder von Sun noch von Oracle nennenswert Zeit investiert, um ein modernes Look and Feel auch für Linux zu implementieren (Windows und MacOS sind diesbezüglich kein Problem), aber mit dem FlatLAF gibt es eine Open-Source-Implementierung, die einen sehr ordentlichen Job macht.
Alternativ wäre übrigens eine Umsetzung mit Python und Qt denkbar gewesen, was sicherlich (für mich) auch reizvoll gewesen wäre, aber aufgrund des Zeitdrucks und des immerhin vorhandenen Basis-Know-Hows war Java zumindest in diesem Moment die bessere Wahl. (Python übrigens ist ja auch so ein Phänomen: Von vielen als »junge« Programmiersprache wahrgenommen, erlebt sie seit einigen Jahren einen wahren Boom, was mich bisweilen etwas wundert. Ich habe mich tatsächlich schon zu meinen Amiga-Zeiten (oberflächlich) mit Python beschäftigt; jung ist sie nun wirklich nicht mehr. Aber nicht die Sprache ist das größte Problem von Python, sondern das große Thema »Abhängikeiten und Deployment«, aber das wäre mal einen separaten Beitrag wert.)
Generell bestehen in unserem Team keine Berührungsängste vor Technologien, die wir bisher nicht eingesetzt haben. Das ist ein Vorteil, den man nicht überall hat, und der uns flexibel macht. Und wer weiß? Vielleicht werden wir auf der gewählten Basis noch weitere Anwendungen umsetzen, vielleicht wird das nächste Projekt aber doch in Python realisiert? Beide Ansätze würden uns auch erlauben, plattformübergreifende Anwendungen zu entwickeln.
Darüber hinaus war dieses Projekt auch eine schöne Aufgabe für unseren Auszubildenden in der Fachrichtung Systemintegration (für den ich nicht persönlich zuständig bin), der sich um Hardware-Zusammenbau und Betriebssystem-Einrichtung inkl. Fernwartungsmöglichkeiten kümmern konnte. Win-Win, würde ich sagen.