Eingebettete Systeme und Datenverarbeitung

Rechnerarchitektur

figcomparch1

Abb. 1. Computersystemarchitekturen. Implementierungsebenen kommunizieren vertikal über die gezeigten Schnittstellen. (Nach Glenford Myers, 1982) [A]

Materialinformatik

Bedeutung:

  1. Rechnen in Materialien (Verteilte Datenverarbeitung in Materialien)
  2. Rechnen von Materialien (Data Science, KI, .., um neue Materialien zu entwickeln)

  • Normalerweise wird die Berechnung von Sensorerfassung und Steuerung getrennt

  • Smarte Materialien stellen die enge Verbindung zwischen

    • Berechnung,
    • Kommunikation,
    • Sensorerfassung und
    • Steuerung mit lose gekoppelten Nano-Computern dar.

Materialinformatik

  • Algorithmische Skalierung und Verteilung sind erforderlich

    • Verteilte Systeme können als eine große Maschine behandelt werden

  • Mooresches Gesetz sagte starke Miniaturisierung voraus

  • Jedoch die Informatik und deren Methoden konnten nicht immer folgen → Lücke zwischen Hardware und Software

figcpusclaing

Materialinformatik

Eine normalisierte Recheneffizienz eines Computers (nur unter Berücksichtigung der Datenverarbeitungseinheit) kann definiert werden durch:

\[\epsilon_C = \frac {C}{AP} \]
A

Chipfläche in mm2

C

Rechenleistung in Mega Instructions per Second (MIPS) - oder besser in Kilo Dhrystones/s (KDS)!

P

Elektrische Leistungsaufnahme in W

Die Recheneffizienz kann verwendet werden, um verschiedene Computer und Geräte zu vergleichen, d.h. einen Skalierungsfaktor anzugeben:

\[s = \frac{\epsilon_1}{\epsilon_2} \]

Materialinformatik

  • Neben der reinen Rechenleistung sind noch Speicher und Kommunikationsfähigkeit einer Rechneranlage wichtige Kenngrößen, so dass sich zwei weitere normierte Recheneffizienzen ergeben:
\[\epsilon_{CM} = \frac {CM}{AP} \]
\[\epsilon_{CMD} = \frac {CMD}{AP} \]
M

Gesamter Speicher in Mega Bytes (MB), beinhaltet RAM, ROM, Register

D

Gesamte Kommunikationsfähigkeit als Datendurchsatz (Mega Bit/s)!

Materialinformatik

Maßzahlen der Rechenleistung

  • Einfachste Maßzahl ist die Anzahl der Integer- oder Fliesskommaoperationen pro Zeiteinheit (MIPS/FLOPS)

    • Aber nur der eigentliche Kern des Mikroprozessors wird dabei erfasst - Speicher, Speicherhierarchie und Kommunikationsfähigkeit fehlen

  • Ein Programm besteht i.A. aus den folgenden High-level Operationen:

    • Berechnung (skalar, vektoriell)
    • Speicherallokation, Objekterzeugung (Code und Daten)
    • Funktionsaufrufe
    • Erzeugung, Zugriff, und Freigabe verschiedener Objekte mit unterschiedlichen “Speicherabdruck”: Arrays, Strings, Records, Funktionen, Methodische Objekte mit Prototypen (Klassen)

⇒ Dhrystone Benchmark umfasst alle oben genannten Operationen!

Materialinformatik

Chip Fläche

figchiparea1

Abb. 2. Normierte Maßzahlen für die Chip Fläche (A/rbe) [H]

Materialinformatik

Chip Fläche

figchiparea2

Abb. 3. Normierte Maßzahlen für die Chip Fläche von Speicher (A/rbe) [H]

Materialinformatik

Chip Fläche

figchiparea3

Abb. 4. Normierte Maßzahlen für die Chip Fläche von Prozessoren (A/rbe) [H]

Materialinformatik

Chip Fläche

figchiparea4

Abb. 5. Normierte Maßzahlen für die Chip Fläche von FPGAs (A/rbe) [H]

figchiparea5

Abb. 6. Zusammenhang der Technologiegröße f (Fertigungsauflösung/Transistordimension) mit der normierten Fläche A [H]

Materialinformatik

  • Hitachi entwickelte bereits 2006 einen 0.15 x 0.15 Millimeter großen, 7.5 μm dicken Microchip der:
    • Drahtlose Kommunikation und Energieversorgung via RFID → (2.45 GHz Mikrowelle) ermöglichtet, einen
    • 128 Bit ROM Speicher, und einen
    • einfachen Mikroprozessor enthielt.

figsmartdust3

Abb. 7. Es geht noch kleiner → Smart Dust reloaded (by Hitachi)

Materialinformatik

Aufgabe

  1. Mache eigene Messungen mit dem dhrstone benchmark Test auf verschiedenen Rechnern und Virtuellen Maschinen.

  2. Stelle eine Tabelle zusammen mit gängigen Computern (mobil, Desktop, Server, eingebettete Rechner, Nanorechner) mit den Daten MIPS/DPS, Speicher, Kommunikation (abgeschätzt) sowie Chip Fläche und el. Leistungsbedarf

  3. Berechne die verschiedenen ε Parameter und vergleiche …

Entwurf Eingebetteter Systeme

Softwareentwurf

figembsoftdes1

Abb. 8. Entwurfsebenen von Eingebetteten Systemen auf Softwareebene

Entwurf Eingebetteter Systeme

  • Der Entwurf Eingebetteter Systeme geht immer mehr Richtung Hardware-Software Co-Design und System-on-Chip Architekturen

fighwdesign1

Abb. 9. Entwurfsebenen von Eingebetteten Systemen auf Hardwareebene

Rechnersysteme

  • Man unterscheidet folgende Kategorien von Rechnern:
    1. Stationäre Geräte: Server
    2. Stationäre Geräte: Desktop
    3. Mobile Geräte: Notebook
    4. Mobile Geräte: Smartphone
    5. Stationäre und mobile Eingebettete Systeme: Einplatinencomputer und Microcontroller
    6. System-on-Chip Geräte: Einchipcomputer und Microcontroller

Rechnertechnologien

Existierende “Nano”-Computer:

  • Smart Dust → Vision Millionen lose gekoppelter Nano-Computer
    • Eingebettet in Materialien
    • Auf Oberflächen verstreut
    • Dispergiert in Flüssigkeiten, Folien, ..
    • ungefähr 10mm3 Volumen

Micro Mote M3

figm3

ELM System

figelm

Rechnertechnologien

Existierende Kleinstrechner für Sensornetzwerke mit Drahtloskommunikation (WLAN, Bluetooth)

Raspberry PI Zero

  • 32-bit RISC ARM Prozessor
  • 512MB RAM, 16GB ROM
  • 1W
  • 70x30mm

figpizero

ESP8266

  • 32-bit RISC Tensilica Xtensa Diamond Standard
  • 128kB RAM, 16MB ROM
  • 0.15W
  • 30x20 mm figesp8266

Rechnertechnologien

Micro Mote (M3 ) ELM System Atmel Tiny 20 Freescale KL03 ARM Cortex Smart Phone
Processor Arm Cortex M0 C8051F990 (SL) AVR Arm Cotex M0+ Arm Cortex A9
Clock 740kHz max. 32kHz - 48MHz 1GHz
CPU Chip Area 0.1mm2 9mm2 1mm2 4mm2 7mm2/ROM
Sensors Temperature - - - Temp, Light, Sound, Accel., Press., Magn.
Communication 900MHz radio, optical optical electrical - 3G/4G, WLAN, USB, Bluetooth, NFC
Harvester, Battery Solar cell, Thin film Solar cell, Coin - - -
Power Consumption 70mW / CPU 160mW / CPU 20mW 3mW @ 48MHz 100mW avg.,
Manufacturing 180nm CMOS - - - 40nm CMOS
Package Wire bonded Silicon Stack PCB Single Chip Single Chip
Computing Eff. εC 150 0.02 0.6 4.0 0.53

Rechnertechnologien

Smart Dust

  • Kommunikation: Optisch, Laser, LED
  • Energieversorgung: Optisch, Fotozelle
  • Energiespeicher: Dünnfilmbatterie
  • Sensorik: Temperatur, Licht

figsmartdust1

Abb. 10. Aufbau einer Smart Dust Mote [Smart Dust: Warneke et al., 2001]

Rechnernetzwerke

Von großen Computern zu großen Netzwerken …

  • Ursprünglich wurden Software- und Betriebssysteme auf Computern mit hoher Rechenleistung und Speicherkapazität ausgeführt.
  • Die Integration von Berechnung in technische Strukturen oder Geräte erfordert das Herunterskalieren von Algorithmen und Methoden in Richtung auf verteilte Verarbeitungsnetzwerke mit Plattformen mit geringen Ressourcen.

figsmartdust2

Abb. 11. Skalierung und Miniaturisierung [Smart Dust: Warneke et al., 2001]

Rechnertypen

  • Rechner und Mikroprozessoren unterscheiden sich u.A. durch die Art und Weise der Maschinenbefehlsausführung

  • Man unterscheidet: Reduced Instruction Set Computer (RISC) und Complex Instruction Set Computer (CISC)

    • RISC: Maschinenbefehle arbeiten häufig mit Registern (Anzahl Register groß)
    • CISC: Maschinenbefehle arbeiten häufig mit dem Speicher (Anzahl der Register klein)
    • Eingebettete Systeme verwenden i.A. RISC (Aufgabe: Warum?)

  • Es gibt Maschinenbefehle mit einer unterschiedlicher Anzahl von Operanden (0,1,2,3,..)

  • Neben register- und speicherbasierten Rechnern gibt es reine stackbasierte Rechner (Nulloperandenbefehle)

    • Alle Operationen werden über den Stapelspeicher ausgeführt

Rechnertypen

figcpuopaddr1

Abb. 12. Rechnereinteilung nach Adressanzahl: gezählt wird die Anzahl Operanden eines dyadischen Operators (z.B. einer Addition) [C].

Programmierung

Randbedingungen

Die Programmierung eingebetteter Systeme stellt aufgrund folgender Randbedingung eine Herausforderung dar:

  1. Geringe Rechnenleistung pro Netzknoten

  2. Geringe Speicherkapazität von Daten

  3. Bei energieautarken Systemen gibt es eingeschränkte Laufzeit

  4. Geringe Kommunikationsleistung

  5. Fehleranfälligkeit

  6. Schlechte Wartbarkeit (Softwareupdates usw.)

  7. Eingeschränkte Möglichkeiten der Fehlersuche

Programmierung

Programmiersprachen

  • Assembler → Maximale Performanz, minimalste Zuverlässigkeit/Korrektheit (Fehler), minimalster Speicherbedarf, kein automatisches Speichermanagement

  • C/C++ → Sehr gute Performanz, geringer Speicherbedarf, und mittlere Zuverlässigkeit/Korrektheit (Fehler), kein oder minimales automatisches Speichermanagement → Prozedurale Programmierung

  • JAVA → Mittlere Performanz, hoher Speicherbedarf, gute Zuverlässigkeit/Korrekheit (Fehler), automatisches Speichermanagement → Objektorientierte Programmierung

  • Skriptsprachen → Unterschiedliche Performanz, wird durch Interpreter bestimmt, automatisches Speichermanagement

    • Python (schlechte Performanz)
    • JavaScript (mittlere oder gute Performanz, evtl. hoher Speicherbedarf)
    • Lua (mittlere oder gute Performanz, niedriger Speicherbedarf)

Programmierung

Performanz und Speicherbedarf bei Skriptsprachen hängen vom Interpreter ab!

  • JavaScript: Google V8 (Bytecode+Just-in-time native code Compiler), Jerryscript (Bytecode)
  • Lua (Bytecode) und Luajit (Bytecode+Just-in-time native code Compiler)

Bytecode. Der Bytecode ist eine Sammlung von Befehlen für eine virtuelle Maschine.

  • Bei der Kompilierung eines Quelltextes mancher Programmiersprachen oder Umgebungen, wie beispielsweise Java, wird nicht direkt Maschinencode, sondern ein Zwischencode, der Bytecode, erstellt.
  • Dieser Code ist in der Regel unabhängig von realer Hardware. Er entsteht als Resultat einer semantischen Analyse des Quelltexts und ist im Vergleich zu diesem oft relativ kompakt und wesentlich effizienter interpretierbar als der originale Quelltext [Wikipedia].

Programmierung

  • Reine Bytecode Interpreter haben geringe oder mittlere Performanz bei niedrigen Speicherbedarf

    • Der Bytecode wird entweder vollständig aus dem Quelltext beim Start eines Programms erzeugt, oder
    • Der Bytecode wird stückweise nach Bedarf aus dem Quelltext zur Laufzeit erzeugt

  • Ein JIT Compiler übersetzt häufig vorkommende Bytecode Abschnitte zur Ausführungszeit in nativen Maschinencode

    • Das ergibt erhöhte Ausführungsperformanz, benötigt aber mehr Speicher

  • Vorteile von Skriptsprachen gegenüber kompilierten Programmen: Schneller Test, ausführliche und genaue Rückmeldung vom Interpreter bei Fehlern, bessere Laufzeitüberwachung von Fehlern, …

Programmierung

Ausführungsplattform für Eingebettete Systeme

  • Daher ist eine zweistufige Architektur sinnvoll:

    • Virtuelle Maschine programmiert in C (hohe Portabilität) und ggfs. Assembler, mit integrierten Compiler, die Bytecode ausführt und bei Bedarf Bytecode in nativen Maschinenkode umwandelt (JIT)
    • Skriptsprache (in diesem Kurs Lua) die im Quelltext von der virtuellen Maschine ausgeführt wird

  • Virtualisierung durch die VM von:

    • Prozessor (Instruction Set Architecture, ISA)
    • Speicher, automatisches Speichermanagement
    • Ein- und Ausgabegeräten (Geräte)
    • Kommunikation

  • Warum nicht JAVA?

    • Hoher Speicherbeadarf
    • Nur objektorientierte Programmierung, nicht immer effizient
    • Kein Interpreter: Compiler und VM sind getrennt

Virtualisierung

figvm1

Abb. 13. Eine prozessvirtuelle Maschine, die Programme ausführen kann, die für ein anderes Betriebssystem und eine andere ISA entwickelt wurden: Die Virtualisierungssoftware bildet eine Plattform auf eine andere ab, und übersetzt eine Reihe von Betriebssystem- und Benutzerebenenbefehlen. [A]

Virtualisierung

Compiler

figcc[http://doc.gold.ac.uk]

Abb. 14. Klassischer Softwareentwurf mit Compiler und Linker (C)

Virtualisierung

Interpeter

figinterpreter

Abb. 15. Edit - Compile - Execute Zyklus bei einem Interpreter

Virtualisierung

Bytecode Interpreter

  • Die Übersetzung des Quelltextes in Bytecode kann vor und während der Ausführung des Programms erfolgen!

figbytecode1[Python]

Abb. 16. Vergleich Interpreter mit Bytcode Compiler-Interpreter System

Virtualisierung

Serialisierung

  • Da Bytecode unabhängig von der Hostplattform sein sollte, kann Bytecode einfach von einer Maschine zu einer anderen übertragen und ausgeführt werden
  • Dazu ist eine Serialisierung von Daten und Code erforderlich (Flache Liste von Bytes), mit anschließender Deserialisierung (Wiederherstellung der Daten- und Codestruktur)

figbytecode2[Peter Cawley]

Virtualisierung

JIT Compiler

  • Neben der Bytecode Ausführung kann während der Laufzeit des Programms der Bytecode stückweise optimiert werden → Erzeugung von Maschinencode durch einen Just-in-Time Compiler (JIT)

figjit1[King Fahd University of Petroleum and Minerals]

Abb. 17. Vergleich Interpreter mit JIT Compiler-Interpreter Systeme

Virtualisierung

Aufgabe:

  1. Überlegen Sie sich die Vor- und Nachteile von

    • Compilern
    • Interpretern
    • Bytecode Interpretern
    • JIT Compiler und Interpreter

  2. Was sind die Bewertungskriterien?

  3. Welche Ausführungsarchitekturen könnten für Eingebettete Systeme geeignet sein?

Virtualisierung

  • Rechenleistung, Speicherbedarf, und Ein-Ausgabe Durchsatz/Latenz sind wichtige Metriken für den Einsatz in Eingebetteten Systemen

figembarch1[B]

Abb. 18. Typische Datenverarbeitungsebenen in Eingebetteten Systemen und Virtualisiering

Virtualisierung

Perfomanz von Interpretern

Dhrystone Benchmark (Kombination aus Berechnung, Objekten, Arrays, Strings, Funktionen)

VM/OS-ARCH Linux-i686 Linux-armv6l (PI-3) Linux-armv6l (PI Zero)
python2.7 105k/s 10k/s 4k/s
lua 5.1 140k/s - -
luajit 2.0.5X 660k/s 71k/s 40k/s
jerryscript 1.1.7X 45k/s - -
nodejs 4 6300k/s 350k/s 40k/s
C/gcc ? ? ?

Virtualisierung

Speicherbedarf von Interpretern

Dhrystone Benchmark (Kombination aus Berechnung, Objekten, Arrays, Strings, Funktionen)

VM/OS-ARCH Linux-i686 Linux-armv6l (PI-3) Linux-armv6l (PI Zero)
python2.7 - - -
lua 5.1 - - -
luajit 2.0.5X 2MB - -
jerryscript 1.1.7X 2MB
nodejs 4 24MB - -
C/gcc ? ? ?

Virtualisierung

Automatisches Speichermanagement

  • In C/C++ muss für jedes zur Laufzeit dynamisch erzeugte Datenobjekt (Array, String, Record, ..) immer explizit Speicherplatz im Hauptspeicher angefragt werden (malloc) und wieder frei gegeben werden wenn das Datenobjket nicht mehr benötigt wird (free)

  • In Skriptsprachen gibt es i.A. ein automatisches Speichermanagement mit einem sog. Garbage Collector und Objektreferenzierung

  • Jedes Datenobjekt welches verwendet wird (z.B. in Variablen oder Funktionen) besitzt eine Referenz

  • Es muss eine Wurzeltabelle geben von der aus alle Referenzen auf verwendete Objekte auffindbar sind

Beispiel 1. (Beispiel von Objektreferenzierungen in Lua: Wo existieren Referenzen?)

\[\begin{mdmathpre}%mdk \mathkw{var}~\mathid{o}_{1}~=~\{~\mathid{a}=1,~\mathid{b}=\{1,2,3,4\}~\}\\ \mathkw{var}~\mathid{o}_{2}~=~\{~\mathid{op}~=~\mathid{o}_{1},~\mathid{index}=2~\}\\ \mathkw{function}~\mathid{show}~()~\mathid{print}~(\mathid{o}_{2}.\mathid{op}.\mathid{a}~\}~\mathkw{end};~\mathid{show}() \end{mdmathpre}%mdk \]

Virtualisierung