download - SPES 2020

SPES
Software Plattform Embedded Systems 2020
Zentralprojekt
SPES-Aut / Embedded4You e.V.
Domänenübergreifende Gegenüberstellung
von
Hardware-Abstraktionskonzepten
Beginn 17.10.2011
Stand 17.10.2011

Dokumentenüberblick
Förderkennzeichen 01IS08045A
Deliverable N/A
Author (SPES-
Partner)
Author (SPES-
Partner)
Kurzdarstellung
Urs Gleim
E-Mail: urs.gleim@siemens.com
Telefon: +49 89 636-45117
Robert Schachner
E-Mail: rschachner@rst-automation.de
Telefon: +49 89 9616018-14
Dieses Dokument dient als Arbeitspapier zur Diskussion von Hardware-Abstraktionskonzepten, wie sie in Embedded-
Systemen verschiedener Domänen zu finden sind.
Die verschiedenen Konzepte sollen auf Basis der Anforderungen in Verschienen Domänen bewertet und miteinander
verglichen werden.
Diese vorliegende Version des Dokuments enthält zunächst einige grundsätzlichen Überlegungen und eine erste
Sammlung existierende Abstraktionsmodelle.
- 2 -

Inhaltsverzeichnis
Dokumentenüberblick ...................................................................................................................................................... - 2 -
Kurzdarstellung ................................................................................................................................................................ - 2 -
1 Motivation ....................................................................................................................................................................... 4
2 Wer braucht Abstraktion? ............................................................................................................................................... 4
3 Was wird abstrahiert? ..................................................................................................................................................... 5
4 Wie wird Abstrahiert? ..................................................................................................................................................... 6
4.1 Datenzentrisches Modell ....................................................................................................................................... 6
4.2 Logische Pfade ..................................................................................................................................................... 6
4.3 Service-orientierte Ansätze ................................................................................................................................... 6
5 Vorteile dieser Herangehensweise ................................................................................................................................ 7
5.1 Wiederverwendbarkeit der Komponenten innerhalb des Abstraktion Layers (Blick von unten) ........................... 7
5.2 Plattform Unabhängigkeit der Applikation (Blick von Oben) ................................................................................. 7
5.3 Verwendung von Domänenspezifischen Werkzeugen auf einer Abstraktionsschicht .......................................... 7
6 Beispiele ......................................................................................................................................................................... 7
6.1 GAMMA ................................................................................................................................................................. 7
6.1.1 Allgemein .......................................................................................................................................................... 7
6.1.2 Funktionsweise ................................................................................................................................................. 7
6.2 ACE ....................................................................................................................................................................... 9
6.3 Corba .................................................................................................................................................................. 10
6.4 ICE ...................................................................................................................................................................... 10
6.5 Epics ................................................................................................................................................................... 11
6.5.1 Allgemein ........................................................................................................................................................ 11
6.5.2 Input/Output-Controller ................................................................................................................................... 11
7 Referenzen ................................................................................................................................................................... 12
- 3 -

1 Motivation
Bei der Entwicklung komplexer Systeme, die über viele Jahre im Einsatz sind und gepflegt werden müssen, liegt das
Know-How – auch im Embedded-Bereich – mehr und mehr in der Applikationssoftware. Die darunterliegende Hardware
wird von Generation zu Generation leistungsfähiger und kostengünstiger. Damit die Anwendungen nicht für jede Hardware-Generation
neu angepasst werden müssen, sind geeignete Abstraktionskonzepte notwendig. Bei Neuentwicklung
von Systemen kann durch Standardkomponenten auf Software-Seite, unterstützt durch Werkzeuge, Entwicklungszeit
und damit Kosten gespart werden. Darüber hinaus erhält man bessere Qualität durch Wiederverwendung getesteter
Komponenten. Um Standardkomponenten in der Breite einsetzen zu können, müssen sie gegen einen Hardwareunabhängigen
Abstraktionslayer entwickelt werden, der auf aktuelle und zukünftige Hardware-Plattformen anpassbar ist.
2 Wer braucht Abstraktion?
Betrachtet man ein System aus dem Blickwinkel der beteiligten Software-Entwickler (Abbildung 1) haben wir auf unterster
Ebene die System-Entwicklung. Diese beinhaltet Betriebssystem, Treiber und Basisdienste wie Persistenz, Diagnose,
Logging, Tracing, Debugging-Support, Software-Updates, usw.. Auf dieser Ebene wird typerscherweise in C, seltener
in C++, programmiert. Die Implementierungen sind in Teilen hardwareabhängig. Der Systemlayer stellt die unterste
Ebene der Abstraktion dar (einmal abgesehen davon, dass wir einen Compiler verwenden…). Typische Schnittstellen
sind die System-API des Betriebsysstems mit systemnahen Bibliotheken (Win32, POSIX) sowie nicht selten proprietäre
Schnittstellen für domänenspezifische Basisdienste.
Der nächste Layer implementiert die Produkt-Software bzw. die Software-Plattform, je nachdem in welcher Domäne
wir uns befinden und ob es um Produkt- oder Lösungsgeschäft geht. In der Industrie-Automatisierung wäre hier z.B. die
SIMATIC S7 Firmware angesiedelt, im Lösungsgeschäft eher eine Software-Plattform, die applikationsübergreifend
notwendige Komponenten implementiert, wie z.B. eine generische Business-Logik, ein HMI-Framework, ein Bilderkennungsframework
mit den entsprechenden Algorithmen, usw..
Den Applikationslayer implementieren OEMs, Maschinenbauer und teilweise auch Endkunden. Im Lösungsgeschäft ist
das die Kundenspezifische Software. Im Produktgeschäft enthält der Applikationslayer die Ausprägungen verschiedener
Produkte einer Produktlinie.
Darüber finden sich aus Entwicklersicht weitere Abstraktionslayer, die in der Software-Architektur allerdings vorwiegend
im Rahmen des Produkt-Software / Plattform Layers implementiert sein sollten. Zum einen kann das eine Schnittstelle
zur Erweiterung um einzelne Komponenten (Plug-Ins, Skripts) sein, zum anderen werden generische Komponenten
applikationsspezifisch parametrisiert.
Parametrisierung
Erweiterungen
(Plug-Ins, Skripts)
Applikationen
Produkt / Software-Plattform
(Firmware+Standardapps.)
System
(OS, Hardwareanbindung)
- 4 -
Komponentenentwickler,
Zulieferer
Abbildung 1: Systemsichten
OEM
Endanwender

3 Was wird abstrahiert?
Entwickler auf jedem der genannten Layer erwarten ein anderes Abstraktionsniveau. In den unteren Schichten ist es
noch relativ einfach. Der Systementwickler kennt noch die HW/SW-Schnittstelle der Hardware. Der Produkt- und Plattformentwickler
arbeitet gegen die bekannten Betriebssystem-APIs, kennt aber noch die Struktur der darunterliegenden
Hardware: mit welchen Geräten kommuniziere ich, über welche Netzwerke/Busse, welche Speichermedien habe ich zur
Verfügung, usw..
Interessant wird es an der Schnittstelle zur Applikation. Wie kann ich dem Applikationsentwicker eine genaue Kenntnis
der Hardware ersparen. Und genau hier setzten viele Abstraktionslayer an.
Anknüpfend an [1] könnte man die Schnittstelle der Applikation nach unten aus Sicht der Modellierung als Schnittstelle
zwischen Technical Layer und Logical Layer sehen (Abbildung 2). Allerdings lassen sich die anderen Layer nicht 1:1
zuordnen. Der Functional Layer ist eine Black-Box-Sicht auf das System und hilft bei der Modellierung der Applikation
sowie bei der Erstellung der Tests. Functional Layer und Logical Layer können somit bei der Modellierung aller Layer –
außer vielleicht der Parametrisierung – zum Einsatz kommen.
Abbildung 2: Abstraktionslayer aus [1].
Bleiben wir bei der Schnittstelle Plattform/Applikation. Der Abstraktionsentwickler wünscht sich eine Abstraktion der
folgenden Themen, d.h. er möchte sich nach Möglichkeit nicht beschäftigen mit:
Persistenz:
was wird wo gespeichert.
Wie erfolgt die Kommunikation zwischen Applikation und Abstractionlayer (serialisiert oder objektrelational)
I/O:
über welche Hardware-Schnittstellen ist I/O realisiert.
Netzwerk:
über welche Netzwerke sind Systemkomponenten gekoppelt.
Parallele Hardware:
Verteilung der Ausführung über mehrere CPUs oder mehrere Prozessor-Kerne.
Datenformat:
Marshalling zw. versch. Datentypen; Endianess, …
Betriebssystem Abstraktion Versionierung
5

4 Wie wird Abstrahiert?
4.1 Datenzentrisches Modell
Das datenzentrische Modell entspricht einem Abstraction Layer, der sich zwischen der Anwendung und der darunter
Hardware befindet.
Damit entspricht es in etwa dem Interface zwischen dem logical- und technical Layer. Zur Applikation hin werden folgende
Funktionen abstrahiert.
- Prozessvariablen mit entsprechenden Zugriffsrechten im lokalen System
- Prozessvariablen verteilt in einem Multicore- Multiprozessing und vernetzten Betrieb
- I/O Funktionen über lokale I/O Karten und Feldbusse
- Betriebssystem Funktionen
All diese Funktionen werden über einheitliche Methoden erreichbar:
- Zugriffsfunktionen auf Prozessvariablen
- Message Kommunikation über Ports
- Synchronisationsmechanismen
- Subscribe Funktionen (Signale, Semaphoren)
Unterstützt wird die Applikationsentwicklung durch eine Simulationsschnittstelle, und Datenlogging. Sie dient bereits
einigen Testsystem Umgebungen als Basis Schnittstelle.
Anwendung findet Gamma vorwiegend im Echtzeit Umfeld. Damit eignet sich die Software für Leistungsfähige Automatisierungsaufgaben
auch im sicherheitskritischen Umfeld.
4.2 Logische Pfade
Ressourcenzugriff über URLs: Dateien, Netzwerke, etc.
Über eine separate Konfiguration (z.B. Konfigurationsdateien oder explizite Anmeldung einzelner Komponenten) werden
die logischen Pfade auf physikalische abgebildet.
Beispiele:
POSIX
J2ME Generic Connection Framework
Persistenzmechanismen mit Baumstruktur bei den Teilbäume an verschiedenen Stellen abgelegt werden
(z.B. eine Registry mit Teilbereichen in RAM, NAND Flash, oder NOR Flash)
4.3 Service-orientierte Ansätze
Kapselung von Funktionalität in Diensten. Dienste werden nicht absolut adressiert, sondern anhand ihrer Eigenschaften
bei einer Service-Registry angefragt, die dann eine direkte Referenz auf den konkreten Dienst zurückgibt.
Abstrahiert wird hier …
Beispiele:
Web-Services
UPnP
CORBA
Epics
6

5 Vorteile dieser Herangehensweise
5.1 Wiederverwendbarkeit der Komponenten innerhalb des Abstraktion Layers (Blick von
unten)
Bei einer konsequenten Umsetzung der gesamten Applikation mit Hilfe eines Abstraction layers befinden sich im
technical Layer keine applikationsspezifischen Software Funktionen mehr. Damit wird dieser Layer universal für
unterschiedlichste Anwendungen wieder verwertbar.
5.2 Plattform Unabhängigkeit der Applikation (Blick von Oben)
Die Abstraktionsschicht reduziert Aufrufe an den technical Layer mit einheitlichen Funktionen, die sich nicht mehr
auf die Hardware Gegebenheiten abstützen müssen. Die Applikation reduziert sich auf den reinen logischen
Code. Dies bietet folgende Vorteile:
- Der Code wird wesentlich einfacher und damit verständlicher, kürzer und billiger
- Die Portierung auf neue Hardware kann ohne Änderungen erfolgen
- Die Anforderungen an das Know How des Entwicklers reduziert sich dramatisch
5.3 Verwendung von Domänenspezifischen Werkzeugen auf einer Abstraktionsschicht
Gerade bei Modellbasierter Entwicklung war es notwendig die Abstraktionsschicht manuell in das Tool zu implementieren.
Dies kann jetzt entfallen. Durch die Verwendung von Application Layern wird die modellbasierte Entwicklung
durchgängig.
Geht man noch einen Schritt weiter und passt domänenübergreifend die Werkzeuge auf den Abstraction Layer
an. So können unterschiedlichste Werkzeuge (Applikationsentwicklung und Test) ohne spezifische Anpassung
auf einer Hardware arbeiten ohne sich zu behindern, Einheitliche Tools wären dann nicht mehr nötig. Je nach Anforderung
werden die Tools kombiniert. Damit wäre das vorrangige Entwicklungsziel von SPES2020 erfüllt.
6 Beispiele
In diesem Abschnitt werden beispielhaft einige konkrete Implementierung von Abstraktionslayern gelistet. Die Aufzählung
erhebt (in dieser Fassung des Dokuments) keinen Anspruch auf Vollständigkeit und stellt eine erste Sammlung dar,
auf deren Basis zu einem späteren Zeitpunkt ein detaillierter Vergleich folgen soll.
6.1 GAMMA
6.1.1 Allgemein
GAMMA ist ein Framework der RST-Automation GmbH, das es ermöglicht, plattformübergreifende Applikationen für
Test- und Steuersysteme in einer Entwicklungsumgebung zu erstellen und auf verschiedensten Zielsystemen – auch
über Architekturgrenzen hinweg – einzusetzen. Im Gegensatz zu allen anderen Methoden erfolgt bei Gamma nur teilweise
die Kommunikation über eine Client Server Architektur. Dadurch ist die Software extrem schnell (

Betriebssystem
Simulation von Variablen
Logging
6.1.2.1 Das Datenmodell
Im Zentrum der Betrachtung steht das datenzentrische Modell. Es ist hierarchisch organisiert und verfügt über eine
symbolische Adressierungsmethode. Die Variable selbst kann mit verschiedenen Methoden angesprochen werden und
verfügt über konfigurierbare Eigenschaften:
- Unterschiedliche Datentypen
- Grenzbetrachtung
- Simulation
- Logging
6.1.2.2 I/O
- Verlinkung mit Hardware
- Metadaten (Beschreibungstexte)
- Versionierung
Bereits vorgefertigte Hardware kann grafische zusammengesteckt und verlinkt werden. Fehlende Hardware wird einfach
über die Hardware Integrationsschnittstelle erweitert. I/O Bibliotheken können einfach Firmenübergreifend gemeinsam
verwendet werden. Durch die Verlinkung mit einer Variable erhält diese die zusätzliche Hardware Funktionalität. Dies
ermöglicht den Aufbau von Bibliotheken, die Firmenübergreifend genutzt werden können.
6.1.2.2.1 Betriebssystem Abstraktion
Zur Vereinheitlichung der Software können (nicht müssen) die wichtigsten Funktionen der jeweiligen Betriebssysteme
abstrahiert werden. Das erleichtert die Software Pflege in heterogenen Rechner Architekturen.
6.1.2.3 Multitasking, Multiprozessing, Vernetzung
Datenmodelle können so gebaut werden, dass für die Applikation eine einheitliche Zugriffsmethodik entsteht. Das Datenmodell
wählt intern je nach Hardware Struktur die optimale Zugriffsmethode. Multiprozessing, Multicore, Vernetzte
Systeme mit unterschiedlichen Betriebssystemen werden dabei berücksichtigt.
6.1.2.4 Applikationsentwicklung und Test
Gamma eignet sich hervorragend für Applikationsentwicklung und Test. Damit wird es möglich eine Applikation, die mit
einem beliebigen Werkzeug erstellt wurde, durch ein anderes Werkzeug zu testen. Austauschformate entfallen. Tests
können im laufenden Betrieb statt finden.
8

6.2 ACE
ACE besitzt eine Client Server Architektur. Das bietet hohe Sicherheit aber relativ langsame Reaktionszeiten.
ACE bietet folgende APIs (siehe auch Abbildung 3):
OS Adaption Layer
Nebenläufigkeit und Synchronisation
Interprozess Kommunikation, Shared Memory
Synchrone und Asynchrone Ereignis Handler
Dateisystem Zugriffe
OS Adaption Layer
C++ Wrapper Fassaden
Framework zu Netzwerkprogrammierung
Distributed Services and Components
Higher-level Distributed Computing Middleware Components
9

6.3 Corba
Abbildung 3 – ACE Schlüsselkomponenten
Laut Wikipedia ist Corba ist ein relativ abstraktes Konzept, was den intuitiven Zugang erschwert. Das Konzept selbst ist
innovativ und hat großes Potential. Von den konzipierten Methoden wurde leider nur wenig umgesetzt. Deshalb bleibt
man häufig an die Programmiersprachen Java und C# gebunden. Ebenso wie ACE und ICE funktioniert Corba nur über
ein Client Server Modell, was die Zugriffsgeschwindigkeit erheblich reduziert. Die Reaktionszeiten von Zugriffsmethoden
bewegen sich im Bereich von mehr als 200µs.
Corba abstrahiert:
Betriebsystem
Programmiersprache (der Kommunikationspartner)
Deployment, Verteilung der Komponenten auf verschiedenen Knoten
Typische Latency Zeiten sind bei Corba etwa bei 25µs für lokale Kommunikation und etwa 1 µs bei Kommunikation über
TCP/IP.
6.4 ICE
Neuentwicklung auf Basis der Erfahrungen mit CORBA. Heraus stechende Unterschiede sind geringere Komplexität,
bessere Performance (etwa Faktor 2 gegenüber Corba), Durch die Client Server Architektur ist das System sehr sicher.
Im Gegensatz zu Corba unterstützt das Framework auch Versionierung.
10

6.5 Epics
6.5.1 Allgemein
EPICS (für Experimental Physics and Industrial Control System) ist eine Softwareumgebung, um verteilte Kontrollsysteme
für Großexperimente wie Teilchenbeschleuniger oder Teleskope zu entwickeln und zu realisieren.
EPICS verwendet Client-Server- und Publish-Subscribe-Methoden für die Kommunikation zwischen den verschiedenen
verwendeten Computern. Eine Sorte von Computern, die Input/Output-Controller (IOC), sammelt dabei in Echtzeit über
die angeschlossenen Messinstrumente Experiment- und Kontrolldaten. Über ein spezielles Netzwerkprotokoll namens
Channel Access (CA) werden diese Informationen an eine weitere Rechnersorte, die Clients, weitergegeben. CA unterstützt
dabei weiche Echtzeit-Anforderungen, wie sie in wissenschaftlichen Experimenten anfallen.
6.5.2 Input/Output-Controller
Bei den IOCs handelt es sich entweder um handelsübliche PC‘s oder Standard-VME-Prozessoren, die bestimmte Module
(etwa GPIB oder RS232) verwalten, die wiederum mit Kontrollsystem-Instrumenten (Oszilloskope, Netzwerkanalysatoren)
und -Geräten (Motoren, Thermoelemente, Schalter und so weiter) in Verbindung stehen.
Auf dem IOC läuft eine Datenbank mit Records, die entweder Geräte oder Eigenschaften der zu steuernden Geräte
repräsentieren. IOC-Software für harte Echtzeitbedingungen verwendet normalerweise RTEMS oder VxWorks, wenngleich
an einer Portierung auf weitere Systeme gearbeitet wird. IOC-Software für weiche Echtzeitbedingungen läuft
manchmal auf Linux- oder Windows-Systemen.
Weitere Rechner im Netzwerk können mit den IOC über das Konzept der Channels kommunizieren. Als Beispiel diene
ein Teilchenbeschleuniger mit Ventilen zwischen einzelnen Abschnitten. Zu einem Ventil gäbe es typischerweise mehrere
Channels: Einen Ausgabe-Channel, um das Ventil ferngesteuert zu öffnen oder zu schließen; einen Eingabe-
Channel, um den Zustand des Ventils abzufragen (z. B. geschlossen, offen, in Bewegung); und vielleicht weitere analoge
Eingabe-Channels, die Druck und Temperatur auf jeder Seite des Ventils repräsentieren.
Häufig wird auf den Clients ein GUI-Paket wie EDM (Editor/Display Manager) oder MEDM (Motif EDM) eingesetzt. Diese
ermöglichen die Erzeugung und Verwendung von Skalen, Zeigern, Textboxen, einfachen Animationen usw.
11

7 Referenzen
1. Feilkas et al. 2009
Martin Feilkas, Alexander Harhurin, Judith Hartmann, Daniel Ratui und Wolfgang Schweizer. Abstraction Layers –
Motivation and Introduction of a System of Abstraction Layers for Embedded Systems. TU München im Rahmen von
SPES 2020, 2009, Wikipedia
12