Viele Erweiterungen existieren bereits, doch werden Raspberry Pi und Arduino vor allem in der ernsthaften Automatisierungswelt immer noch als Bastelplattform gesehen und nicht als vollwertige Systeme im Sinne einer klassischen SPS. Oft findet man auf einschlägigen Websites und Foren pfiffige Lösungen von Hobbyelektronikern mit auf Holzplatten geschraubten Platinen, die fliegend auf einen Raspberry Pi verdrahtet sind und ihre Aufgabe erfüllen. Sehr oft mit viel Enthusiasmus, Klebeband, Kabelbindern und handgestrickten Python Scripts, C Code oder selbst geschriebenen Websites. Wie gesagt, alles pfiffige und oft auch funktionierende Lösungen, aber von gewohnten Automatisierungsstandards meist weit entfernt und fast unmöglich zu warten. Dies soll jetzt anders werden. Ein dem Open-Source-Geist verschriebenes Team, das mitten in der Automatisierungstechnik steht, hat es sich zum Ziel gemacht, den Raspberry Pi von seinem Bastelimage zu lösen und zu einem ernsthaften Automatisierungsgerät zu machen. Ein industrietaugliches Gerät, bestehend aus Hardware und integrierter Software, sind eine ernstzunehmende Alternative geworden und das nicht nur für Bastler und Heimanwender.
Technische Merkmale
Der Raspberry Pi, auf den wir uns hier konzentrieren wollen, hat seit seiner Markteinführung Anfang 2012 eine rasante Entwicklung durchgemacht. War das Modell A noch mit einer Singlecore 32Bit ARM11 CPU mit 700Mhz-Taktrate ausgestattet, so bietet der jüngste Spross das Model 3 B bereits eine mit 1.2GHz getaktete 64 Bit Quadcore ARM Cortex-A Architektur. Auf dieser Plattform lassen sich bereits leistungsfähige Betriebssysteme vernünftig nutzen und so gibt es neben verschiedenen Linux-Distributionen (Raspbian, eine Debian basierte Distribution, ist hier wohl die am weitesten verbreitete) zum Beispiel eine Microsoft Windows 10 IoT Core Implementierung für den ‚Himbeerkuchen‘. Auf der Schnittstellenseite bietet der Raspberry Pi sehr viele Möglichkeiten über sein GPIO (General Purpose IO) Interface. Hier stehen bereits Busse, wie SPI oder I2C zur Verfügung, die für Erweiterungen genutzt werden können. Die GPIO Pins des Raspberry Pi arbeiten allerdings mit einem Spannungspegel von 3,3V und verfügen aus Kostengründen über keinerlei Schutzbeschaltung. Diese Erweiterungsmöglichkeiten und fehlenden Schutzfunktionen haben in den letzten Jahren zu einer wahren Flut an Erweiterungsboards geführt. Es werden u.a. Analog-Digital-Wandler Boards, GPIO-Erweiterungen, Schrittmotortreiber bis hin zu Touchscreens angeboten. Eines der ersten Produkte in diesem Bereich war und ist das sogenannte PiFace des Briten Dr. Andrew Robinson, dessen Ziel es war, den Anschluss des Raspberry Pi an die Aussenwelt deutlich zu vereinfachen.
Anforderungen aus der Automatisierungstechnik
Warum wurde jahrelang der Raspberry Pi trotz seiner Möglichkeiten in der Automatisierungswelt nicht ernstgenommen? So passt doch der Raspberry Pi eigentlich gar nicht so schlecht zu den (meist spezialisierteren) Embedded-Systemen, die als Basis für Geräte im Industrieumfeld eingesetzt werden. In der Automatisierungstechnik liegt jedoch der Fokus nicht auf Embedded-Computern, sondern bei Geräten, die weit mehr sind als nur der bloße Rechenknecht im Inneren. Das typische Automatisierungsgerät besteht aus einer CPU (-Platine) mit zur Anwendung passenden industrietauglichen Ein- und Ausgängen. Je nach Anwendung ist das Automatisierungsgerät mit einer festen I/O-Konfiguration ausgestattet (z.B. für Seriengeräte) und/oder mit einer Feldbusschnittstelle ausgestattet, sodass Ein- und Ausgangsmodule projektspezifisch angepasst werden können. Generell gilt, dass die höhere Flexibilität meist auch mit einem höheren Preis erkauft wird. Je ‚einzigartiger‘ das Projekt (die Maschine) ist, desto sinnvoller ist der Einsatz von Feldbusmodulen. Je höher die Stückzahlen an Geräten mit gleicher I/O-Konfiguration, desto sinnvoller ist eine feste I/O-Struktur, die projektangepasst entwickelt und gefertigt wird. Die Waschmaschine mit Feldbus-Modulen wäre wirtschaftlich gesehen genauso unsinnig wie das Einzelstück einer Sondermaschine, für die speziell eine I/O-Baugruppe aus Standard-I/O entwickelt und gefertigt werden muss. Genauso verhält es sich wieder bei der Softwareentwicklung für Automatisierungsgeräte. Für die bereits zitierte Waschmaschine sind geringste Stückkosten oberste Priorität, das rechtfertigt auch höhere Entwicklungskosten für Hard- aber auch Software, wenn dadurch der Einsatz günstigerer Komponenten möglich wird. Eine ‚kleinere‘ CPU, also eine günstigere Recheneinheit mit eventuell weniger Speicher oder geringerer Taktfrequenz, verringert die Stückkosten in einem höheren Maß als die höheren Entwicklungskosten. Je geringer die Anzahl softwaretechnisch gleicher Automatisierungsgeräte ist, desto lauter wird auch die Forderung nach einfacheren Programmiermethoden. Programmiermethoden, die nicht unbedingt einen hochqualifizierten Softwarentwickler erfordern, der von der Domäne des Projekts meist wenig Ahnung hat, sondern es auch dem Experten für die Projektlösung (die Maschine, die technologische Regelung, der chemische Prozess) erlauben, die Software selbst zu erstellen. Heute wird oftmals der Begriff SPS für diese Kombination aus Hard- und Software eingesetzt. Eine Kombination aus (industrietauglichen) Ein- und Ausgängen, die die Sensorik und Aktorik mit der CPU verbinden, und eine entsprechende Entwicklungsumgebung, die ein einfaches und standardisiertes Erstellen der Automatisierungsapplikation ermöglicht. Der meist eingesetzte Standard ist hier die IEC 61131, deren Teil 3 die Programmiersprachen für Automatisierungssysteme normiert. Der Automatisierer benötigt ein Gerät, dass neben ausreichender Rechenleistung für die Aufgabe auch entsprechende (anwendungstaugliche) Ein- und Ausgänge und Schnittstellen zur Verfügung stellt. Dieses Gerät sollte für eine Schaltschrankmontage geeignet sein und die (gängigen) Vorschriften im Einsatzbereich erfüllen. Dazu zählt auch der wichtige Punkt der CE-Konformität, die zum Beispiel mit einem Raspberry Pi gar nicht so einfach umzusetzen ist. Neben der Programmierung muss ggf. das System konfiguriert und parametriert werden (z.B. Feldbus und Kommunikationsverbindungen). Die entsprechende Programmieroberfläche muss ein Verwenden der konfigurierten Elemente (Ein- und Ausgänge, Kommunikationsverbindungen) erlauben, und die Software muss entsprechend getestet werden können. Wünschenswert ist ein Online-Debugger, der in Quellcodeansicht (was bei der IEC61131-Programmierung auch eine grafische Ansicht bedeutet) erlaubt, die Programme zu inspizieren, den Zustand von SPS und Programm zu sehen und auch zu verändern. Dieser Cross-Debugger (Programm und Debugger laufen üblicherweise auf unterschiedlichen Geräten) soll die Fehlerfindung und -behebung genauso unterstützen, wie dies herkömmliche Entwicklungsumgebungen für Standardsoftware tun. Zusätzlich ist gerade für eine Analyse von zeitlich abhängigen Verläufen (z.B. in der Regelungstechnik) eine Aufzeichnung von Laufzeitdaten und eine Analyse nötig, die im Idealfall im Rahmen des Debuggers zur Verfügung steht. Das Gesamtsystem der SPS muss auch eine schmerzlose Inbetriebnahme ermöglichen. Ein Automatisierungstechniker möchte sich nicht mit Betriebssysteminstallation herumschlagen und soll auf einfache Art und Weise das Gerät im Projektumfeld installieren können. Im Idealfall beschränkt sich die Installation auf mechanische und elektrische Installation. Nach einer meist nötigen Netzwerkkonfiguration sollte die SPS als ebensolche bereits im (IoT)-Netzwerk zur Verfügung stehen und vom Programmiergerät aus verwendet werden können. Im Idealfall ist hier keine weitere Installation von Konfigurations- oder Programmiersoftware nötig und der Automatisierer kann sich auf seine Kernkompetenzen konzentrieren.
Neue Anforderungen durch IoT und Industrie 4.0
IoT (‚Internet of Things‘) und ‚Industrie 4.0‘ sind seit Jahren schon in aller Munde. Jeder kennt es, und jeder hat das ideale Produkt für IoT. Mit einer kleinen Einschränkung: Fragt man zwei Leute, was IoT ist, so erhält man zumindestens drei (unterschiedliche) Meinungen zum Thema. Für unsere einfache Betrachtungsweise ist IoT einfach ein vernetztes System, in dem (aus Automatisierungssicht) mehrere Automatisierungssysteme (teil)autonome Aufgaben ausführen und hierzu über das IoT Daten untereinander und mit Sensorik und Aktorik austauschen. Zusätzlich können Dienste aus dem ‚echten‘ Internet verwendet werden (z.B. Wetterdaten, Datenlogging,…), was natürlich wieder eine Verbindung zwischen den Geräten im IoT und dem Internet voraussetzt. Der Raspberry Pi fügt sich hervorragend in ein Netzwerk von (teil)autonomen Automatisierungssystemen ein. Eine Netzwerkschnittstelle erlaubt die Kommunikation mit anderen Teilnehmern des IoT-Netzwerks. Das zumeist eingesetzte Linux-Betriebssystem bringt Client- und Server-Software für viele offene und De-Facto-Standards bereits mit sich, allem voran einen stabilen TCP/IP-Stack, sowie Kommunikationsdienste für z.B. http. Durch die Verfügbarkeit von GPIO und weiteren Schnittstellen, wie z.B. I²C oder SPI ist eine kostengünstige Anbindung auch industrietauglicher Ein- und Ausgänge (z.B. nach IEC61131-2) möglich. Für einfache Steuerungsaufgaben reicht meist bereits die Verfügbarkeit robuster Digitalein- und ausgänge. Die Software (das ‚Programmiergerät‘) soll sich ins IoT nahtlos einfügen und unter Ausnutzung offener Standards die Programmierung und Parametrierung des Raspberry Pi als Automatisierungssystem erlauben. Im folgenden beschreiben wir ein reales Automatisierungssystem auf Basis Raspberry Pi, das diese Anforderungen erfüllt.
Conmeleon C1 PLC
Das hier betrachtete System ist die Conmeleon C1 PLC Komplettlösung (siehe Abbildung 1 www.conmeleon.org. Es besteht aus einem Raspberry Pi 3, einem industrietauglichen I/O-Board Conmeleon C1, sowie einem dazu passenden für die Hutschienenmontage geeigneten Gehäuse. Als Stromversorgung werden industrieübliche 24V vorausgesetzt. Das I/O-Board bietet vier optisch entkoppelte Digitaleingänge, vier Relais-Ausgänge mit 250V/2A und vier Analogeingänge (0..10V) mit einer Auflösung von 12Bit. Das Thema CE-Konformität wird bei Conmeleon C1 zukünftig durch ein Metallgehäuse sichergestellt. Interessantes Detail am Rande: Sowohl das I/O-Board als auch das Gehäuse sind ‚Open Source‘, d.h., dass auch wenn die Komponenten von Conmeleon bezogen werden können, doch alle nötigen Informationen, um selbst eine Fertigung durchzuführen (oder durchführen zu lassen) kostenfrei zur Verfügung gestellt werden. Die Conmeleon C1 PLC wird mit einer SD-Karte mit vorinstalliertem Betriebssystem Linux und der SPS-Software q4PLC von qmd4 geliefert. Die Programmiersoftware q4Logix fügt sich nahtlos in das Bild des IoT-Devices ein und wird direkt im Webbrowser ausgeführt. Sie benötigt einen HTML5-Browser (z.B. Internet Explorer, Chrome, Firefox, Safari), ist unabhängig vom verwendeten Betriebssystem (Windows, MacOS X, Linux) und läuft auch auf mobilen Geräten z.B. unter iOS und Android. Neben der Projektverwaltung bietet q4Logix einen vollgrafischen IEC61131-3 konformen Funktionsplaneditor (siehe Abbildung 2), der genauso im Webbrowser läuft wie auch die zugehörige Visualisierungssoftware q4Viz zum Erstellen von Bedienoberflächen (Abbildung 3). Im Fall der Visualisierung laufen sowohl der Editor, als auch die Runtime im Web-Browser. Eine Installation der Software ist nicht nötig. Der Conmeleon-Anwender greift mit seinem Webbrowser auf das Gerät selbst zu und die nötige Software wird automatisch geladen. Projekt- und Programmdateien (also auch der Quellcode der SPS-Programme) werden direkt auf dem Gerät gespeichert. Die Anwendung selbst wird automatisch vom qmd4-Webserver geladen. Dort werden q4Logix und q4Viz in der jeweils aktuellen Version bereitstellt. Einziger Nachteil ist, dass hier ein Internetzugang für das Programmiergerät benötigt wird. Dennoch erweckt diese transparente Vorgehensweise den Anschein, als wäre die gesamte Programmiersoftware auf dem Conmeleon-System installiert. Als Installationsoption ist auch dies möglich, bedingt jedoch, dass die Softwareversion verwendet wird, die auf dem Gerät installiert ist. Dafür ist dann ein Betrieb auch vollständig ohne Internetverbindung möglich. Die eingeschränkte feste I/O-Konfiguration der Conmeleon C1 PLC eignet sich nicht für jede Anwendung, aber für viele einfache dezentrale Aufgaben im intelligenten IoT ist es bereits ausreichend. Die PLC kann jederzeit um Ethernet-basierte Feldbusse, wie z.B. Ethercat erweitert werden, was für das Raspberry-Pi-basierte Automatisierungssystem die Brücke zur herkömmlichen Automatisierungswelt schlägt. Softwareseitige Unterstützung durch entsprechende Feldbusstacks im Betriebssystem und in der SPS-Software sind verfügbar. Abbildung 4 zeigt die Bedienoberfläche eines Heizungssystems für ein Mehrfamilienhaus, das auf eine Erweiterung der I/O-Möglichkeiten der C1 PLC durch Ethercat setzt.
Fazit
Mit geeigneten Hardware- und Softwarekomponenten eignet sich der Raspberry Pi zur Automatisierung sowohl im IoT-Umfeld als auch in der herkömmlichen Automatisierungswelt. Durch Hersteller oder Projekte wie Conmeleon ist es einfach – ohne selbst ‚basteln‘ zu müssen – auch ein funktionierendes Gesamtsystem bestehend aus Hardware (mit Gehäuse) und Software zu erhalten, und das Ergebnis ist auch keine Bastellösung für Enthusiasten sondern ein ernsthaft einsetzbares Automatisierungsgerät.
