Für Rechnermodule in der Automatisierung wird zum einen in der Regel ein möglichst einfaches Trägerboard entwickelt, auf welchem – neben dem Modulsteckplatz – das Netzteil, die E/A-Interfaceschaltungen, spezielle Feldbusanbindungen usw. zu finden sind. Zum anderen wird eine gerätespezifische Software mit zahlreichen Hardwareabhängigkeiten implementiert. Bei grafikbasierten Bedienterminals und Touch-IPCs entfallen auf die Softwareentwicklung vielfach mehr als 80% der gesamten Entwicklungskosten. Da ist es nicht weiter verwunderlich, dass hinsichtlich der Verfügbarkeit der zum Einsatz kommenden 32Bit-Modulfamilie eine besonders lange Lebensdauer erwartet wird. Schließlich muss die Investition in Hard- und Softwareentwicklung geschützt werden. Vielfach wird von dem entwickelten Produkt nur eine relativ kleine Stückzahl gefertigt, die für den jeweiligen Hersteller aber eine große wirtschaftliche Bedeutung hat, weil sie z.B. zusammen mit einer recht kostenintensiven Spezialmaschine ausgeliefert wird. Auch muss häufig eine Ersatzteilversorgung über viele Jahre gesichert werden. Maschinen leben wesentlich länger, als die Kernkomponenten eines Rechnermoduls (CPU, Speicherbausteine, Grafik-Controller usw.) verfügbar sind. Zumindest für die Software bedeutet das in der Regel, dass sie auch nach über zehn Jahren möglichst ohne Redesign auf einer Austauschbaugruppe ablaufen muss. Das klappt in der Praxis nur, wenn die zum Einsatz kommende Modulfamilie bereits nach speziellen Gesichtspunkten entwickelt wurde. Atom-basierte Modulformate nur bedingt geeignet In den letzten Monaten wurden verschiedene neue 32Bit-Embedded-Modulfamilien vorgestellt, die sich an den Eigenschaften der besonders Strom sparenden Intel-Atom-Familie orientieren. Mögliche Anwendungsbereiche solcher Module sind selbstverständlich auch Bedienterminals und Touch-IPCs in der Automatisierung. Atom-Bausteine wurden zwar für Netbooks, UMPCs (Ultra Mobile PCs) und MIDs (Mobile Internet Devices) entwickelt. Diese kompakten Rechnersysteme sind in erster Linie als portable Internet-Clients gedacht. Sie sollen – neben Webbrowser und E-Mail – auch die vom Desktop-PC vertrauten Multimedia-Anwendungen als mobile Applikationen ermöglichen. Zwischen den Benutzerschnittstellen mobiler PCs und Touchscreen-basierter Visualisierungssysteme gibt es aber zahlreiche Parallelen. Gleiches gilt für den Energiebedarf. Bei mobilen Computern soll die Batterie möglichst lange halten. Gute HMI-Baugruppen in der Automatisierung müssen mit passiver Kühlung arbeiten. Da ist eine geringe Eigenerwärmung schon hilfreich. Aufgrund der rasanten Verbreitung über Netbooks und des hohen Bekanntheitsgrades der Intel-Atom-Prozessoren ist es nicht weiter verwunderlich, dass in der letzen Zeit auch verschiedene Embedded-Modulformate auf Basis dieser Prozessoren entwickelt wurden. Zwei typische Beispiele für Atom-basierte Modulformate sind nanoETXexpress und Qseven. Auffällig ist bei beiden Formaten, dass es nur noch die typischen Schnittstellen mobiler PCs als Verbindung zur Außenwelt gibt. PCI Express, SDIO im 8Bit-Modus, Serial ATA und bis zu achtmal USB Host sind zwar sehr leistungsfähige Schnittstellen, sie verursachen aber beim Einsatz in Automatisierungsbaugruppen überflüssige Zusatzkosten, da zahlreiche zusätzliche Bausteine auf dem Trägerboard benötigt werden. Dadurch wird dieses Board komplexer. Einfache UART-Schnittstellen oder ein simples 8- oder 16Bit-Businterface mit Chip Select und Interrupt sucht man bei diesen Atom-Modulen vergeblich. Alles, was der Atom nicht bietet, wurde weggelassen, um eine möglichst kompakte Bauform und geringe Leistungsaufnahme zu erreichen. Ein weiterer Nachteil derartiger Modulkonzepte ist die Abhängigkeit von der Roadmap eines bestimmten Halbleiterherstellers, die nicht einmal auf den Embedded-Markt ausgerichtet ist. Brauchbare Verfügbarkeitskonzepte für Anwendungen in der Automatisierung gibt es nicht. Dafür ist man ja PC-kompatibel. Der Anwender kann heute und in Zukunft selbstständig alle gängigen PC-Betriebssysteme zum Einsatz bringen. Dass eine PC-Plattform inklusive der Betriebssysteme in zehn Jahren ganz anders aussehen wird als von den Entwicklern einer Automatisierungslösung erwartet, zeigen die Lehren aus der Vergangenheit. Eine Alternative für die Automatisierung Touchscreen-basierte Visualisierungsaufgaben erfordern nicht unbedingt einen Prozessor aus der PC-Welt. Die Vorteile, die solche CPUs zu bieten haben, sind in der Automatisierung vielfach zweitrangig. Verfügbarkeit, Schnittstellenvielfalt, vielfältige Hard- und Software-Integrationsmöglichkeiten sowie die einfache Handhabung sind wichtiger. Aus diesem Grund wurden für den neu entwickelten eSOM-200-Formfaktor spezielle Zielsetzungen zugrunde gelegt. Drei besonders wichtige Punkte sind: – Schnittstellenvielfalt: Um ein eSOM-200-Trägerboard so einfach wie möglich zu halten, bietet das Pinout die für Visualisierungsaufgaben in der Automatisierung wichtigsten Schnittstellen. Neben 3x UART, 1x LAN, 2x USB, 16Bit GPIO, TFT Touch LCD Interface ist ein 8/16Bit-Erweiterungsbus mit Chip Select-Ausgängen und Interrupt-Eingängen vorhanden. – 10+ Jahre Verfügbarkeitsgarantie: Beim Entwurf des Pinouts und der Abmessungen wurde darauf geachtet, dass sowohl x86/IA-32- als auch ARM- und PowerPC-CPUs, MCUs und SoCs eingesetzt werden können. Ein eSOM-200-Modul wird standardmäßig mit Linux als vorinstalliertem Betriebssystem ausgeliefert. Dieses Open-Source-Betriebssystem bildet die Softwareschnittstelle für den Anwender. Pinout, Formfaktor, elektrische Parameter und Software-Interface sind plattformunabhängig und fallen unter die Verfügbarkeitsgarantie. Hard- und Software bilden dabei ein integriertes Schichtenmodell. Fügt der Anwender die selbst entwickelte Software in dieses Modell ein, überträgt sich die Plattformunabhängigkeit automatisch auf die jeweilige Kundenapplikation. – Kostengünstiges Trägerboard: Der Einsatz schneller Bussysteme wie PCI Express zur Anbindung externer Peripheriebausteine erfordert ein aufwendiges und recht teures Trägerboard. In der Regel muss hier eine impedanzkontrollierte Leiterplatte als Modulträger entworfen werden. Aus diesem Grund wird im eSOM-200-Pinout auf derartig anspruchsvolle Schnittstellen verzichtet. PCI wird nur auf dem Modul selbst genutzt. Der Anwendungsschwerpunkt für eSOM-200-Module sind preiswerte und langzeitverfügbare Visualisierungsbaugruppen mit Display-Diagonalen bis ca. 6\“. Darüber hinaus wird die Kommunikation per Ethernet, TCP/IP, Feldbus, GSM/GPRS/UMTS sowie in drahtlosen Sensornetzwerken (LAN, WAN, PAN) besonders unterstützt. Feinabstimmung Verfügbarkeitsgarantien über Zeiträume von 10+ Jahren für Rechnermodule sind in der Praxis nur möglich, wenn Hardware und Software aus einer Hand kommen und genau aufeinander abgestimmt werden. Bei voneinander unabhängigen Hard- und Softwarepartnern wird die jeweilige Roadmap bereits innerhalb weniger Jahre nicht mehr konvergieren. Weiterhin muss ein Rechnermodul mit einem vorinstallierten Betriebssystem und den entsprechenden Laufzeitumgebungen für spezielle Programmiersprachen wie beispielsweise Java, PHP, Python usw. geliefert werden. Als Eckpunkte für die Garantien sind – neben der Architektur, dem Formfaktor und dem Pinout – die Softwareschnittstellen und Laufzeitumgebungen des Betriebssystems entscheidend. Hier kommt eigentlich nur ein Open-Source-Betriebssystem wie Linux in Frage. Da die Quellcodes vorliegen, kann auch ein zehn Jahre alter Linux-Kernel auf ein neu entwickeltes Modul portiert werden. Darüber hinaus müssen spezielle Treiber – z.B. für RS485 oder die Anbindung an Feldbusse – für das jeweilige Betriebssystem durch den Modulanbieter gepflegt oder zumindest speziell unterstützt werden. Wiederverwendbare Software spart Kosten Beim eSOM/2586 als ersten Vertreter der eSOM-200-Familie wurde in das vorinstallierte Linux eine vollständige Java 6-Laufzeitumgebung integriert, wie sie über die Webseiten von Sun zur Verfügung gestellt wird. Java steht – wie auch das Linux-Betriebssystem eines eSOM/2586 – unter einer Open-Source-Lizenz. Sun bietet gegenwärtig Java-Laufzeitumgebungen für Linux-basierte Embedded Systeme mit x86/IA-32-, ARM- und PowerPC-Architektur an. Mit anderen Worten: Durch das den eSOM-200-Modulen zugrunde liegende Schichtenmodell kann eine Java-basierte Software für ein spezielles Bedienterminal entwickelt werden, die heute auf dem x86-basierten eSOM/2586 zum Einsatz kommt. Diese Software wäre in fünf oder zehn Jahren ohne jegliche Änderungen auch noch auf einer dann aktuellen ARM-Plattform lauffähig. Der Quellcode einer solchen Java-Anwendung müsste dafür noch nicht einmal neu übersetzt werden. Java verwendet einen binären Zwischencode – den sogenannten Bytecode – als Dateiformat für ausführbare Programmdateien. Dateien im Bytecode-Format sind vollständig plattformunabhängig. Sie laufen auf jedem Rechnersystem, das eine entsprechende Java-Laufzeitumgebung besitzt. Erforderliche Anpassungen an LCD und Touchscreen erfolgen bei einem eSOM-200-Modul über die jeweils plattformabhängigen Treiber, also praktisch innerhalb des Betriebssystems. Sollte sich die Feldbusanbindung – z.B. durch den Umstieg von Profibus auf Profinet – während der Lebensdauer des Endprodukts ändern, so bleibt das dank des Schichtenmodells ebenfalls ohne Auswirkungen auf die selbst geschriebene Java-Software, da als Schnittstelle zwischen Feldbus- und Java-Anwendung eine Datei innerhalb des RAM-Disk des Betriebssystems dient. Fazit Lösungen aus dem PC-Massenmarkt sollten nicht 1:1 in die Automatisierung übertragen werden. Die Produktplanung und -pflege erfolgt vor völlig unterschiedlichen Zeithorizonten. Die beschriebene Problematik zeigt auch, dass eine wirklich plattformunabhängige Lösung nur dann erreicht werden kann, wenn der Modulhersteller die Hardware und die Betriebssystemportierung aus einer Hand liefert. Darüber hinaus sollten Betriebssystem und Laufzeitumgebung unter einer Open-Source-Lizenz stehen. Ansonsten nützt eine Verfügbarkeitsgarantie wenig.
SSV Software Systems GmbH
