Entwicklung: Embedded Web 2.0

Bedienoberflächen für "Headless Embedded Systems"

Moderne Embedded Systeme mit Betriebssystem verfügen oft über ein TFT Display mit Touch Screen zur Bedienung. Allerdings gibt es eine Klasse von Geräten, bei denen diese Art der Benutzerführung nicht möglich ist: handelt es sich um Datenlogger oder Steuergeräte, bei denen ein Bedienvorgang nur selten stattfindet, lohnen oft die Kosten für ein Display nicht. Dies spielt gerade bei hochvolumigen Anwendungen, z.B. im Haustechnik-Bereich eine Rolle. Trotzdem besteht der Wunsch nach modernen Benutzer-Schnittstellen.

Da nahezu alle System-on-Chip Prozessoren heute einen integrierten Ethernet-Controller haben, bietet sich eine andere Art der Bedienung an: ein Web-Interface. Alle dafür notwendigen Technologien stehen für Linux zur Verfügung und somit auch für kostengünstige Prozessoren, z.B. aus der 200 MHz ARM926 bis 1 GHz Cortex-A8 Klasse.

Der Vorteil der Web-Technik: Die Backend-Applikation läuft auf dem leistungsschwachen ARM, wohingegen die unter Umständen aufwändige GUI-Technologie im Web-Browser auf einem schnellen PC abläuft. So können auch "fancy GUI" Features umgesetzt werden, ohne dass dafür teure PC-Hardware für die Embedded PCs eingesetzt werden muss.

Das Web 2.0 Prinzip

Die Konzepte von "Web 2.0", vor allem HTML, JavaScript und DOM, bieten eine optimale Plattform für "Embedded Web" Projekte. Dabei wird, im Gegensatz zur alten Web-Technologie nicht mehr jede Webseite statisch ausgeliefert, sondern die Anwendung wird in ein Applikations-Backend und ein GUI-Frontend zerteilt, die sich über einen Remote-Procedure-Call Mechanismus unterhalten.


Konventionelle Web 1.0 Anwendung		AJAX Web 2.0 Anwendung

Während in Web 1.0 Anwendungen der Browser bei Aktualisierungen (z.B. von Meßdaten) eine Seite anfordert und das Embedded System in diesem Moment die Daten für die Seite aufbereiten muß, laufen Applikation und GUI bei Web 2.0 Anwendungen unabhängig voneinander und tauschen nur "kleine" Datenmengen Asynchron aus. So werden z.B. bei aktualisierten Meßdaten nur die Daten, nicht aber die daraus generierten Elemente in der Visualisierung übertragen. Das entlastet das Embedded System merklich.

Der Linux Software Stack

Dank Linux steht für Embedded Web 2.0 Applikationen der komplette Baukasten der Open Source Technologien zur Verfügung. Wenn man auf einem Rechnersystem "Linux" installiert, ist damit in der Regel eine komplette Distribution gemeint: diese besteht aus einer Reihe von Software-Komponenten, die eine Plattform für die eigentliche Software-Entwicklung darstellen:

Die verschiedenen Ebenen abstrahieren das System auf unterschiedlichen Leveln. Im folgenden Abschnitt werden die Komponenten des Software-Stacks vorgestellt:

OS Layer: Zuallerunterst kümmert sich der Linux Kernel darum, daß die Hardware abstrahiert wird. Damit spielt es für den Anwendungsprogrammierer keine Rolle mehr, ob er sich z.B. auf einem ARM- oder x86 Prozessor befindet: der Zugriff auf die Periphierie erfolgt ausschließlich über Treiber. Die Betriebssystemebene beinhaltet weiterhin die glibc-Bibliothek, welche die APIs des POSIX Standards zur Verfügung stellt. Oberhalb der glibc können bereits einfache Anwendungen realisiert werden.

System Layer: Für moderne Anwendungen steht eine Ebene von Systemdiensten zur Verfügung, die oft vorkommende Funktionalitäten kapseln. Dazu gehört ein Parameter-Verwaltungsdienst (dconf), die Infrastruktur-Bibliothek glib sowie der Message Bus D-Bus.

Middleware Layer: Oberhalb der System-Services stellt eine Reihe weiterer Dienste High-Level-Funktionalitäten zur Verfügung:

Network Services: Verwaltung der Wired/Wireless Netzwerkports und statische oder dynamische Vergabe von IP Adressen.

Control Services: Automatisierungsgeräte können über einen Aktor-basierten Prozeßdatenservice eingebunden werden. Dieser beinhaltet sowohl Echtzeit- als auch nicht-Echtzeit Prozeßdaten sowie Feldbusse.

Internet Services: Geräte mit lokalem Display können mit einem integrierten Web-Browser ausgestattet werden.

Visual Services: Die Grundlage für native GUIs bildet Qt. Bei Web-Applikationen kommt die JSON-D-Bus-Bridge zum Einsatz.

Media Services: Werden Multimedia-Funktionalitäten benötigt, stehen dieses auf Basis von GStreamer bereit (z.B. für Kameras, Codecs, Audio usw.)

Der Linux Software Stack bietet die Grundlage zur Entwicklung von Applikationen. Dabei müssen, je nach Anforderungen und Ressourcen, nicht alle Komponenten des Stacks auf dem Embedded System auch installiert werden. Anwendungen ohne native GUI können z.B. die GUI-Bibliotheken von Qt weglassen, werden keine Multimedia-Funktionen benötigt, wird GStreamer nicht installiert usw.

Embedded Web 2.0 Applikationsentwicklung

Pengutronix entwickelt Embedded Web 2.0 Applikationen unter Einsatz der Komponenten des Linux Software Stacks. Die Applikationen bestehen in aller Regel aus einem oder verschiedenen Backends, in denen die Applikationslogik entwickelt wird. Die Backends laufen unter Linux als Dämonen, d.h. als Hintergrund-Prozesse. Die Backends stellen ihre Funktionaliät auf dem D-Bus Message Bus zur Verfügung, so daß ein funktionaler Test auf einfache Art möglich ist.

Auf der Seite der GUI-Komponente im Browser (View) wird die Gegenstelle unter Verwendung eines modernen Web-Toolkits entwickelt. Backend und Frontend kommunizieren über eine RPC Middleware.

Anbindung an Prozessdaten

Neben der eigentlichen Bedien- und Logik-Funktionalität gibt es in vielen industriellen Anwendungen die Anforderung, auf Prozeßdaten zuzugreifen. Pengutronix setzt dazu ein Aktor-basiertes Prozessdaten-Modell ein. Dieses ermöglicht es, auf eine Vielzahl unterschiedlicher I/Os modular zuzugreifen. Dabei kommt es nicht darauf an, ob es sich um "echte" Feldbus-Daten oder um lokale IOs von an die CPU angeschlossenen ADCs, um GPIOs oder um Peripheriechips am SPI- oder I2C-Bus handelt.

Vorgehensmodell

Vorbereitungsphase	Aktivitäten
Vorstellung Projektidee	Kunde stellt Projekt grob vor, Pengutronix stellt Möglichkeiten vor. Falls Lastenheft vorliegt, Erstellung eines Budget-Angebots. Falls nicht, Unterstützung bei der Erstellung eines Lastenhefts (Consulting).

Planungsphase	Aktivitäten
Requirements Workshop	Kunde stellt Projekt vor, Diskussion aller funktionalen Anforderungen, Vorstellung der Möglichkeiten von Hardware und Software. Erstellung eines Protokolls.
Lastenheft+Pflichtenheft	Kunde erstellt Lastenheft, Pengutronix erstellt Pflichtenheft. Diskussion über Möglichkeiten und Anforderungen.
Abschätzung+Auftrag	Pengutronix erstellt Aufwandsabschätzung als Grundlage für Angebot. Kunde beauftragt Projekt.

Entwicklungsphase	Aktivitäten
Bereitstellung Plattform	Entwicklung eines BSPs (Bootloader, Kernel, Treiber, Bibliotheken und Services) nach Anforderungen durch das Pengutronix Kernel/Plattform Team.
Iteration 1	Umsetzung von Arbeitspunkten durch das Pengutronix Applikations-Team, Dokumentation, Auslieferung von Ergebnissen (via RCS), Test und Inbetriebnahme, ggf. Anpassung der Spezifikationen.
Iteration 2...N	...

Übergabephase	Aktivitäten
Abnahme	Gemeinsame Abnahme einer Release-Version.
Ausblick	Diskussion möglicher weiterer Funktionalitäten und Entwicklungsschritte.

Standard Software und
Embedded Anforderungen

"Embedded hat andere Anforderungen" - diese These wurde früher oft in den Raum gestellt und führte eine Zeit lang zur Entwicklung von speziellen Software-Komponenten für Embedded-Projekte. Die Argumentation ging hier oft in Richtung auf besonders geringen Ressourcen-Verbrauch.

Dem entgegen stehen Qualitäts-Anforderungen: Standard-Komponenten, die auch auf dem Desktop und Server eingesetzt werden, erreichen eine wesentlich höhere Testabdeckung. Deshalb versucht Pengutronix bei der Auswahl der Software-Komponenten so weit wie möglich auf die Komponenten zu setzen, die auch in den "großen" Desktop- und Server-Applikationen benutzt werden.

Dabei kommt uns die Entwicklung auf dem Chip-Markt entgegen: auch für Embedded Projekte werden z.B. heute schon große DDR-RAMs und NAND-Flashes eingesetzt, bei denen es nicht mehr auf das letzte Kilobyte Footprint ankommt.

Weitere Infos

Kontakt: Herr Robert Schwebel