User Interfaces for Headless Embedded Systems
Modern embedded systems with operating systems often have TFT displays with touch screens. There is a class of devices though, where this type of user interface is not possible: data loggers or control devices, that are only seldom used usually do not economically warrant such a user interface. Nevertheless there is also demand for modern user interfaces in these areas.
Since almost all system-on-chip processors today offer an integrated Ethernet controller, another mode of interaction presents itself: the web interface. All necessary technologies are provided by the Linux operating system and thus also for cost-effective processors such as the 200 MHz ARM926 to 1 GHz Cortex-A8 class.
The advantage of web technologies: the back end application is run by the low-performance ARM, while the possibly much more expensive GUI technology runs in a web browser on a much faster PC. This way also fancy GUI features can be realised without having to employ costly PC-style hardware within the embedded devices.
The Web 2.0 Principle
|Conventional Web 1.0 Application||AJAX Web 2.0 Application|
In Web 1.0 applications, updates (e. g. of measuring data) require a full reload of the respective web page and all new data have to be provided and preprocessed by the embedded system exactly when the new data are requested by the client. In Web 2.0 applications, however, application and GUI are run independently and only exchange small amounts of data asynchronously. Thus, when updating measuring data, only the real data are submitted, not the visualisation elements based upon them. This will take considerable load off the embedded system.
The Linux Software Stack
Thanks to Linux, embedded Web 2.0 applications can draw on the full range of Open Source Technologies. When installing "Linux" on a PC, this usually means a complete distribution, which consists of a set of software components, which provide a platform for the actual software development.
The different layers abstract the system on different levels. The following section presents the individual components of the software stack:
OS Layer: the Linux Kernel's first and foremost task is abstracting the hardware. With this it makes no odds to the application programmer whether he works on an ARM or an x86 processor; all peripherals are exclusively accessed by means of drivers. Furthermore the OS layer includes the glibc library, which provides APIs for the POSIX standard. Given the Kernel and glibc it is already possible to develop simple applications.
System Layer: for modern applications there is a layer of system services which encapsulate recurrent functionalities. This includes a parameter management service (dconf), the infrastructure library glib as well as the message bus D-Bus.
Middleware Layer: on top of the system services a number of additional services provide different high-level functionalities:
- Network Services: management of wired/wireless network ports and static or dynamic allocation of IP addresses.
- Control Services: automation devices can be integrated by means of an actor based process data service. This includes real time as well as non-real time process data and field buses.
- Internet Services: devices with a local display can be provided with an integrated web browser.
- Visual Services: the framework for native GUIs is Qt. In web applications the JSON-D-Bus-Bridge is used.
- Media Services: if multimedia functionalities are needed these can be realised based on GStreamer (e.g. for cameras, codecs, audio, etc.).
The Linux software stack is the foundation for the development of applications, whereas, depending on requirements and resources not all components of the stack have to be installed on the embedded system. Applications without a native GUI can for instance omit QT's GUI libraries, if no multimedia functionalities are required, GStreamer is not installed and so on.
Embedded Web 2.0 Application Development
Pengutronix develops embedded Web 2.0 applications using components from the Linux software stack. These applications usually consist of one or several back ends in which the application logic is encoded. On Linux these back ends are run as daemons, which means as background processes. These back ends offer their services via the D-Bus message bus, which facilitates functional tests.
On the browser's end the GUI components are realised using a modern web tool kit. Back end and front end communicate by means of an RPC middle ware.
Connection to Process Data
Additionally to the control and logic functionalities many industrial application require access to process data. Pengutronix realises this by means of an actor-based process data model. This facilitates modular access to a number of different I/Os. In doing so, it makes no difference whether "real" field bus data are concerned, local IOs from ADCs, which are connected to the CPU, GPIOs, or peripheral chips on an SPI or I2C bus.
|Presentation Project Idea||Customer presents a rough overview of the project, Pengutronix presents possible solutions. If there is a requirement specification, preparation of a budgetary offer. If not, support in preparation of a requirement specification (Consulting).|
|Requirements Workshop||Customer presents project, discussion of all functional requirements, presentation of possible hard- and software solutions. Preparation of written minutes.|
|Requirement Specification and Functional Specification||Customer prepares requirement specification, Pengutronix prepares functional specification. Discussion of possible solutions and requirements.|
|Estimation and Order||Pengutronix prepares estimation as foundation for offer. Customer orders project.|
|Preparation Platform||Development of a BSP (boot loader, kernel, drivers, libraries and services) according to specification by Pengutronix Kernel/Platform Team.|
|Iteration 1||Realisation of work packages by Pengutronix Application Team, documentation, delivery of results (via RCS), test and initial operation, if necessary adjustment of specifications.|
|Acceptance||Joint acceptance of a release version.|
|Outlook||Discussion of further possible functionalities and development steps.|
Standard Software and
"Embedded has different requirements" - this assumption has often been claimed in earlier years and led to the development of specialised software components for embedded projects. The line of reasoning for this often went along arguments of low computing resources.
Contrary to this are requirements of quality: standard components which are also used on servers and desktop computers usually have a much better test coverage. This is why Pengutronix relies as much as possible on components, which are also used in "big" desktop and server applications.
This approach is additionally supported by recent developments on the chip market: current embedded projects already employ large DDR RAMs and NAND Flashes which make fretting over every last kilobyte of memory unnecessary.
- Kontact: Mr. Robert Schwebel