Überblick

Sensorische Materialien

Sensorischen Materialien sind charakterisiert durch eine starke Kopplung von Sensorik, Datenverarbeitung, und Kommunikation und bestehen aus einem Trägerwerkstoff, der u. U. eine mechanisch tragende Struktur darstellen kann, und aus eingebetteten Sensornetzwerken, die neben Sensoren auch Elektronik für die Sensorsignalverarbeitung, Datenverarbeitung, Kommunikation, und Kommunikations- und Energieversorgungsnetzwerke integrieren.

Inhalte in diesem Kurs

Begleitet von Übungen um obige Techniken konkret anzuwenden

Vorlesung

1 SWS mit Grundlagen und Live Programming
→ Synchroner Livestream + Chat
→ Tutorial Videos

Seminar

1 SWS mit Vorträgen zu ausgewählten Themen des Kurses durch Studenten

Übung

1 SWS mit Programmierung und angewandter Vertiefung → LuaOS und LuaOS WEB mit Online Hilfe Funktion und Einreichungssystem

Voraussetzungen

Grundlegende Programmierfähigkeiten, Grundkenntnisse in Rechnerarchitektur und Netzwerken

Zielgruppen des Kurses

Systemingenieure (Systems Engineering)

Materialwissenschaftler

Produktionstechniker und Logistiker

Elektrotechniker

Informatiker, Wirtschaftsinformatiker

[tiridifilm/istockphoto.com]

Ziele/Kompetenzen

Die Studenten erwerben/gewinnen/lernen

Die Studenten sollen ein Grundverständnis von materialintegrierten intelligenten und sensorischen Systemen erwerben um wesentliche Fragestellungen beim Entwurf und der Nutzung dieser smarten Materialien beantworten zu können

Praktisch sollen Kenntnisse und Programmierfertigkeiten von verteilen Sensornetzwerken mit einem Laborprototyp erworben werden

Es soll interdisziplinäres Arbeiten und Forschen erlernt werden

Verständnis und Anwendung von Sensoren, Technologien, Elektronik, Messtechnik, Signalverarbeitung, Datenverarbeitung, Netzwerken, und Materialintegration in einem ganzheitlichen Ansatz

Zentrale Fragen der Materialintegration bezüglich Möglichkeiten und Randbedingungen sollen beantwortet werden können.

Materialien

Die Vorlesungsinhalte (Skript, Folien) werden auf http://edu-9.de unter der Rubrik Lehre zusammengestellt und angeboten. Achtung: Kürzel miss3k beachten!

Weitere Materialien (Tutorials, Übungen, Software) werden ebenfalls auf http://edu-9.de bereitgestellt

Die Videos sind über http://edu-9.de verfügbar (Video Stream Server)

Interaktion der Teilnehmer findet über einen Wiki statt! (dokuwiki). Dieser ist über http://ag-0.de erreichbar und in den jeweiligen Veranstaltungsseiten auf http://edu-9.de verlinkt.

Es wird noch einen online Chat geben.

Alle weiteren Hinweise und Einführungen (z.B. in Software) nur noch auf dem Wiki!!!

Leistungen

Folgende Möglichkeiten einer Prüfungsleistung stehen zur Auswahl:

Mündliche Prüfung

Seminarvortrag

Schriftliche Ausarbeitung zu einer Fragestellung zu dem Thema (Review/Survey)

Die Bearbeitung einer experimentellen Arbeit (Lua) mit kleiner schriftlicher Arbeit (Dokumentation)

Literatur

Vorlesungsskript und Folien

Die Inhalte der Vorlesung werden sukzessive bereitgestellt, das Vorlesungsskript steht im HTML und ebook Format zur Verfügung!

Material-Integrated Intelligent Systems: Technology and Applications

Stefan Bosse, Dirk Lehmhus, Walter Lang, Matthias Busse (Herausgeber), Wiley 2018, ISBN 9783527336067

Sensornetzwerke in Theorie und Praxis

Ansgar Meroth, Petre Sora, Springer 2018, ISBN 9783658183868

Distributed Sensor Networks

S. S. Iyengar and R. R. Brooks, CRC Press, 2005

![ width=30% scale=50% centered=true](images/iyengar.png)

Sensor Technologies - Healthcare, Wellness, and Environmental Applications

Michael J. McGrath, Cliodhna Ní Scanaill, Apress Open, 2014

Lua Scripting Language

Tutorial Points, K. K. Panigrahi, 2016.

Software

lvm

edu-9.de

LuaJit VM mit Multithreading

Ausführung von der Kommandozeile

Wird auch für Live Programming und mit Digitalen Notebooks genutzt

Einsatz auf verschiedenen Hostplattformen : PC, Smartphone, Raspberry Pi, Server, ..

Einsatz auf Betriebssystemen: Windows, Linux, Solaris, MacOS, Android

> lvm parfib.lua
Thread [fe5af458:4] released
Thread [fe5afa00:5] released
{
  1 = 9227465,
  2 = 24157817,
  3 = 63245986,
  4 = 165580141,
  5 = 14930352,
  6 = 39088169,
  7 = 102334155,
  8 = 267914296,
}
686478381
Time 6235 ms

Ausführung Kommandozeile

Konzept

Virtuelle Maschinen

Die Verwendung von virtuellen Maschinen nimmt in der Datenverarbeitung immer mehr zu (Skriptverarbeitung und Abstraktion)

Ein Schwerpunkt liegt in der Verteilung und Parallelisierung vonm Datenverarbeitung in und mit virtuellen Maschinen

Vor allem kommunizierende Systeme sollen betrachtet werden!

local R = rpc:new()
local ips = {
  "192.168.8.141",
  "192.168.8.142",
  "192.168.8.143",
}
local sensors={}
for i=1,5 do
  local err,reply=R:trans(ips[i],12345,{cmd="get"})
  if (err==nil) then
    sensors[i]=reply.sensor
  end
end

Virtuelle Maschinen und Interpreter

Abbildung 1-1. Interpreter Zyklus: Editieren → Übersetzen → Ausführen

Just-in-Time Compiler

Interpreter können im wesentlichen auf drei Arten (Architekturklassen) implementiert werden:

Direkte Ausführung des Quelltextes (die Nutzereingabe und bereits geschriebene Skripte) (Parse → Execute)

Virtuelle Maschine und Übersetzung des Quelltextes in eine Zwischenrepräsentation die von einer virtuellen Maschine ausgeführt werden kann → Bytecode

Virtuelle Maschine mit Bytecode Übersetzung, Ausführung des Bytecodes, und ausgewählter Übersetzung des Bytecodes in nativen Maschinencode → JIT Compiler!

Virtuelle Maschine: Virtualisierung ≡ Abstraktion und Automatisches Speichermanagement

Beispiele

BASIC: Klasse 1

Python: Klasse 2 (Bytecode)

JavaScript: Klasse 2 (Spidermonkey, WEB Browser) und Klasse 3 (Google Chrome/V8, nodejs)

OCaML: Klasse 2 (und native Codeerzeugung mit Compiler)

Lua: Klasse 2 (Lua) und Klasse 3 (LuaJit/lvm)

Parallelisierung der Datenverarbeitung von VM schwierig, Verteilung hingegen ist prinzipiell moglich.

Abstraktion

Was kann durch eine VM abstrahiert oder virtualisert werden?

Welche Betriebssysteme werden verwendet?

Programmiersprachen

Welche Programmiersprachen werden häufig verwendet?

Welche parallelen Programmiersprachen sind bekannt?

Parallele und Verteilte Programmierung mit Lua

In diesem Kurs soll die Programmierung mit der Skriptsprache Lua erfolgen und mit der virtuellen Maschine lvm ausgeführt werden;

Der Lua Quelltext wird durch einen Übersetzer in Bytecode übersetzt der von lvm direkt ausgeführt wird.

Besonderheit: Der Bytecode wird direkt während des Parservorgangs erzeugt (kein AST-IR)

Die LuaJit VM (lvm) unterstützt parallele sowie netzwerkbasierte Datenverarbeitung und das Konzept der Prozessblockierung

Prozesse

Threads

Coroutinen (Fibers)

Kontrollpfadparallelität benötigt i.A. Kommunikation und das Konzept der Blockierung!

Formales Ausführungsmodell: Communicating Sequential Processes (CSP)

Programmfluß = Kontrollfluß + Datenfluß

Parallele und Verteilte Datenverarbeitung: Übergang vom Shared Memory (SM) zum Distributed (Shared) Memory (DSM) Modell!

Zentral ist in diesem Kurs nachrichtenbasierte Kommunikation und verteilte Sensordatenverarbeitung!

Verteilte Programmierung mit Lua

/shelllvm

size

rpc

rpc=require('plugins/rpc');

server

local rpcA = rpc:new()
rpcA:getreq('127.0.0.1',12345, function (request)
  local y=1
  print(request)
  case request.cmd of
    "square" => y=request.x*request.x end
    "sqrt"   => y=math.sqrt(request.x) end
    else y=0 end
  end
  return {status='OK',clock=clock(),y=y}
end)
print('RPC Server started on port 12345');

client

local rpcB = rpc:new()
local err,reply = rpcB:trans('127.0.0.1',12345,
  {
    cmd='square',
    x=math.random()
  })
if err then print(err) else print(reply) end
local err,reply = rpcB:trans('127.0.0.1',12345,
  {
    cmd='sqrt',
    x=math.random()
  })
if err then print(err) else print(reply) end

Verteilte Programmierung mit LuaOS und LuaWEB

/luaweb.html"

Labor

Das Labor soll den praktischen Einstieg in verteilte Sensornetzwerke bieten und findet @home statt!

Sensorknoten können Notebooks, Smartphones, und eingebettete Rechner (Raspberry) sein!

Die Sensorknoten werden über das Internet vernetzt

Die Sensoren werden über Schnittstellen angeschlossen (I2C)

Programmierung mit Lua und LVM + LuaOS

Abbildung 1-2. Vernetzung von Rechnern über lvm/LuaOS und Aufbau eines verteilten Sensornetzwerkes

Eingebettete Systeme und Datenverarbeitung

Wie kann die Datenverarbeitung unter Randbedingungen von material-integrierten Systemen erfolgen?

Vom Mikrocomputer zum Nanocomputer

Virtualisierung auch im Material!

Programmierung

Rechnerarchitektur

Abbildung 2-1. Computersystemarchitekturen. Implementierungsebenen kommunizieren vertikal über die gezeigten Schnittstellen. (Nach Glenford Myers, 1982

Materialinformatik

Bedeutung:

Rechnen in Materialien (Verteilte Datenverarbeitung in Materialien)

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.

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

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

image-placeholder
(2-1)

A

Chipfläche in mm²

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:

image-placeholder
(2-2)

Neben der reinen Rechenleistung sind noch Speicher und Kommunikationsfähigkeit einer Rechneranlage wichtige Kenngrößen, so dass sich zwei weitere normierte Recheneffizienzen ergeben:

image-placeholder
(2-3)

image-placeholder
(2-4)

M

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

D

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

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!

Chip Fläche

A / rbe )

Abbildung 2-2. Normierte Maßzahlen für die Chip Fläche ( [H]

A / rbe )

Abbildung 2-3. Normierte Maßzahlen für die Chip Fläche von Speicher ( [H]

A / rbe )

Abbildung 2-4. Normierte Maßzahlen für die Chip Fläche von Prozessoren ( [H]

A / rbe )

Abbildung 2-5. Normierte Maßzahlen für die Chip Fläche von FPGAs ( [H]

A

Abbildung 2-6. Zusammenhang der Technologiegröße -math[f] (Fertigungsauflösung/Transistordimension) mit der normierten Fläche [H]

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.

Abbildung 2-7. Es geht noch kleiner → Smart Dust reloaded (by Hitachi)

Aufgabe

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

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

Berechne die verschiedenen ε Parameter und vergleiche ...

Entwurf Eingebetteter Systeme

Softwareentwurf

Abbildung 2-8. Entwurfsebenen von Eingebetteten Systemen auf Softwareebene

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

Abbildung 2-9. Entwurfsebenen von Eingebetteten Systemen auf Hardwareebene

Rechnersysteme

Man unterscheidet folgende Kategorien von Rechnern:

Stationäre Geräte: Server

Stationäre Geräte: Desktop

Mobile Geräte: Notebook

Mobile Geräte: Smartphone

Stationäre und mobile Eingebettete Systeme: Einplatinencomputer und Microcontroller

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 10mm³ Volumen

Micro Mote M3

ELM System

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

Raspberry PI Zero

32-bit RISC ARM Prozessor

512MB RAM, 16GB ROM

1W

70x30mm

ESP8266

32-bit RISC Tensilica Xtensa Diamond Standard

128kB RAM, 16MB ROM

0.15W.15W

30x20 mm

| 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.1mm² | 9mm² | 1mm² | 4mm² | 7mm²/ROM
Memory | 3-4kB | 0.5kB/2-8kB | - | 2kB/40kB | 512MB/4GB
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., 2W peak @ 1.5GHz
Manufacturing | 180nm CMOS | - | - | - | 40nm CMOS
Package | Wire bonded | Silicon Stack | PCB | Single Chip | Single Chip , PCB
Computing Eff. εC | 150 | 0.02 | 0.6 | 4.0 | 0.53

Smart Dust

Kommunikation: Optisch, Laser, LED

Energieversorgung: Optisch, Fotozelle

Energiespeicher: Dünnfilmbatterie

Sensorik: Temperatur, Licht

Abbildung 2-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.

Abbildung 2-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

Abbildung 2-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:

Geringe Rechnenleistung pro Netzknoten

Geringe Speicherkapazität von Daten

Bei energieautarken Systemen gibt es eingeschränkte Laufzeit

Geringe Kommunikationsleistung

Fehleranfälligkeit

Schlechte Wartbarkeit (Softwareupdates usw.)

Eingeschränkte Möglichkeiten der Fehlersuche

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)

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].

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, ...

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

Abbildung 2-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]

Compiler

Abbildung 2-14. Klassischer Softwareentwurf mit Compiler und Linker (C) [http://doc.gold.ac.uk]

Interpeter

Abbildung 2-15. Edit - Compile - Execute Zyklus bei einem Interpreter

Bytecode Interpreter

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

Abbildung 2-16. Vergleich Interpreter mit Bytcode Compiler-Interpreter System

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)

Neben vollständig binär kodierten Bytecode ist Text eine Unterklasse. Beispiel: JavaScript, JSON

Abbildung 2-17. Serialisierung in einer Bytecode VM [Peter Cawley]

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)

Abbildung 2-18. Vergleich Interpreter mit JIT Compiler-Interpreter Systeme

Aufgabe

Überlegen Sie sich die Vor- und Nachteile von

Compilern

Interpretern

Bytecode Interpretern

JIT Compiler und Interpreter

Was sind die Bewertungskriterien?

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

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

Abbildung 2-19. Typische Datenverarbeitungsebenen in Eingebetteten Systemen und Virtualisiering [B]

Perfomanz von Interpretern

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

VM/OS-ARCH | Linux-i686 | Linux-armv6l (PI-3B) | Linux-armv6l (PI Zero)
python2.7¹ | 105k/s | 23k/s | 4k/s
lua 5.1² | 140k/s | 36k/s | -
luajit 2.0.5X/lvm² | 660k/s | 108k/s | 40k/s
jerryscript 1.1.7X³ | 45k/s | - | -
nodejs/V8-4³ | 6300k/s | 879k/s | 40k/s
C/gcc | 18000k/s | 3700k/s | ?

(1: Python, 2: Lua, 3: JavaScript)

Speicherbedarf von Interpretern

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

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

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

1: var o₁ = { a=1, b={1,2,3,4} }
2: var o₂ = { op = o₁, index=2 }
3: function show () print (o₂.op.a } end; show()

Beispiel 2-1. Beispiel von Objektreferenzierungen in Lua: Wo existieren Referenzen?

Abbildung 2-20. Verschiedene Objekte: Objekte die nicht mehr referenziert sind, werden freigegeben

Speicherarchitektur von Programmen

Code: Enthält nur Programmcode (aber auch mit statischen Daten)

Heap: Datenobjekte mit längerer Lebensdauer (Tabellen- oder Listenstruktur) → Benötigt Speichermanagement

Stack: Datenobjekte mit kurzer Lebensdauer (Stapelstruktur) → Benötigt kein Speichermanagement

Speicherarchitektur von Rechnern

Speicherhirarchie durch Cache Systeme

Abbildung 2-21. Speicherhierarchie von Programmen und Zusammenhang mit Maschinenanweisungen

Speicherorganisation von Virtuellen Maschinen

Speicher

Die meisten Objekte in Programmiersprachen benötigen Speicher

Lokale, temporäre, und globale Variablen

Objekte

Arrays

Zeichenketten

Funktionen (!)

Der Kontext von Speicherobjekten ist wichtig:

Modul → limitierte Programmsichtbarkeit

Lokal → stark limitierte Programmsichtbarkeit

Global → uneingeschränkte Sichtbarkeit

Beispiele: Die globale Variable Xglobal ist überall, auch außerhalb des Definitionsmoduls, sichtbar, die Variable xlokal ist im gesamtem Modul und den Funktionen f1 und f2 sichtbar, wo hingegen xlokal1 und xlokal2 jeweils nur ihrem Funktionskontext sichtbar sind.

Xglobal = 1
local xloakal = 2
function f1 ()
  local xlokal1 = 3
end
function f2 ()
  local xlokal2 = 3
end

Nur wenn Variablen bei der Ausführung sichtbar sind belegen sie Speicher!

Ein Teil des Speicher ist vorbelegt:

Globale Variablen

Funktionen, ausführbarer Code, ...

Ein anderer Teil des Speichers wird zur Laufzeit auf dem Stack und Heap belegt und benötigt Verwaltung:

Lokale und temporäre Variablen, ..

Funktionen, ausführbarer Code, ...

Achtung: Bei Programmiersprachen bei denen Funktionen Werte erster Ordnung sind befindet sich auch Code im Heap oder auf dem Stack

Speicherverwaltung

Listen

Freie und belegte Speicherbereiche werden durch Listen (einfach- oder doppelt verkettet) verwaltet

Tabellen

Tabellen (Hashtabellen) werden zur Speicherverwaltung verwendet

Manuelle Verwaltung

Speicherbelegung explizit vom Programmierer und teils vom Compiler auszuführen

Vorteile

Optimale Speicherbelegung (tatsächlich naiv und falsch) und Performanz/Effizienz

Nachteile

Speicherlecks (nicht mehr benötigter Speicher wird nicht frei gegeben)

Mehrfachfreigabe (Inkonsistenz der Speicherverwaltung)

Benutzung von Speicherobjekten nach Freigabe

Automatische Verwaltung

Die Freigabe von Speicherbereichen wird automatisch durch einen Garbage Collector durchgeführt. Dieser bestimmt auch automatisch ob Speicherobjekte noch benötigt werden.

Vorteile

Speicherlecks werden vermieden

Keine Mehrfachfreigabe (Inkonsistenz der Speicherverwaltung)

Keine Benutzung von Speicherobjekten nach Freigabe

Nachteile

Nicht optimale Speicherbelegung und schlechtere Performanz/Effizienz

Garbage Collection

Wie soll der GC heraus finden ob ein Objekt noch benötigt wird?

Referenzzähler wird jedem Objekt hinzugefügt und bei jeder neuen Referenzierung erhöht (Allokation). Ein Objekt mit Referenzwert Null kann frei gegeben werden.

Der GC rechnet Objektabhängkeiten aus und markiert Objekte die freigegeben werden können

Beispiel von Referenzen und Sichtbarkeit (Programmkontext)

 1: local o₁ = { x=100,y=200 }e₁          [e₁.ref=1(o₁)]
 2: local o₂ = { pos=o₁, color="red" }e₂  [e₁.ref=2(o₂,o₁)]
 3: function draw (o)
 4:   local o₃ = { pos=o.pos, color="white" }e₃  [e₃.ref=1(o₃), e₁.ref=4(o₃,..)]
 5:   local o₄ = { pos={x=o.pos.x,y=o.pos.y}e₄, color="black" } [e₁.ref=5(o₄,o₄,..)]
 6:   draw(o₃)
 7:   draw(o₄)
 8:   → [e₃.ref=0, e₄.ref=0, e₁.ref=3, e₂.ref=2]
 9: end
10: draw(o₂)  [e₂.ref=2(o,o₂), e₁.ref=3(o,o₂,o₁)]
11: o₂=nil    [e₂.ref=0, e₁.ref=1(o₁)]
12: o₁=nil    [e₁.ref=0]

Wichtig: Referenzzähler beziehen sich auf Werte (ei), nicht auf die Variablen selber (die nur Zeiger auf Werte besitzen)

D.h. wenn ein Wert als Referenz an eine weitere Variable zugewiesen wird erhöht sich der Referenzzähler!

GC: Referenzzählung

Wenn ein Objekt erzeugt wird, wird der Referenzzähler auf Null gesetzt

Jede weitere Referenzierung erhöht den Zähler um eins (also bereits das zuweisen eines Objektes an eine variable!)

Wird eine Referenzierung vom Objekt entfernt (explizit → =null, oder implizit durch Entfernen des referenzierenden Objektes), dann wird der Zähler um eins erniedrigt

Ist der Zähler wieder Null, dann wird der Speicher freigegeben

Nachteile

Zyklische Referenzen können nicht aufgelöst werden:

local o1 = { x=100,y=100 }
local o2 = { prev=o1 }
o1.next = o2

Daher werden u.U. nicht alle Objekte freigegeben → Speicherlecks

Der Referenzzähler belegt selber Speicher (gehört zum Objekt). Bei low-resource Plattformen wird z.B. eine Datenwortbreite von 16 Bit für den Zähler verwendet, und der maximale Referenzwert ist 65536 (jerryscript ist so ein Kandidat)!

Allokation ist langsamer (verlangsamt Zuweisung)

Vorteile

Einfach zu implementieren

Freigabe ist effizient (wenig Rechenaufwand)

GC: Mark & Sweep

Bestimmte Objekte sind direkt zugänglich, und es muss herausgefunden werden welche Objekte erreichbar sind → Graphensuche

Es gibt einen Stammsatz von Speicherplätzen im Programm, dessen Objekte bekanntermaßen erreichbar sind.

Mark-and-Sweep verläuft in zwei Phasen

Markierungsphase

Erreichbare Objekte suchen:

Der Stammsatz wird zu einer Arbeitsliste hinzugefügt

Solange die Arbeitsliste nicht leer ist wird ein Objekt von der Liste entfernt. Wenn es nicht markiert ist, markiere es als erreichbar und alle Objekte die davon aus erreichbar sind werden zur Arbeitsliste hinzugefügt.

Sweepphase

Für alle belegten Objekte:

Ist das Objekt nicht markiert so lösche es (Speicher freigeben)

Ist das Objekt markiert, lösche die Markierung

Vorteile

Auch zyklische Referenzen können über die Arbeitsliste aufgelöst werden

Alle Objekte können frei gegeben werden

Allokation schnell

Nachteile

Rechenintensiv und langsam!!

Abbildung 2-22. Beispiel eines M&S Durchlaufes mit anschließender Freigabe von nicht mehr erreichbaren == benötigten Objekten

Multitasking

Auf einem Rechnerknoten gibt es eine Vielzahl von Aufgaben die bearbeitet werden müssen:

Sensorverarbeitung

Kommunikation

Steuerung

Zum Teil müssten Aufgaben parallel verarbeitet werden → Multitasking → Parallelisierung → Nur bedingt möglich → Task Scheduling

Echtzeitverarbeitung

Echtzeitverarbeitung bedeutet die Ausführung eines Tasks innerhalb eines vorgegebenen Zeitintervalls [*t*~0~,*t*~1~]

Soft Realtime: Zeitüberschreitung bei weicher Echtzeitanforderung → Tolerierbar

Hard Realtime: Zeitüberschreitung bei harter Echtzeitanforderung → Systemfehler

Abbildung 2-23. Echtzeitspektrum: Wiche und harte Echtzeitanforderungen bei unterschiedlichen Applikationen [B]

Abbildung 2-24. Periodische, sporadische, und aperiodische Tasks [B]

Preemption

Wenn schon nicht alles Tasks gleichzeitig verarbeitet werden können, dann wenigstens die wichtigsten vorrangig ausführen

Das erfordert aber:

Festlegung einer Priorität

Bei Echtzeitanforderungen die Unterbrechung von unterlegenen (kleiner Priorität) Tasks

Abbildung 2-25. Unterschied preemptive und nicht preemptive Ausführung von Tasks [B]

Parallele Datenverarbeitung und Prozesse

Abbildung 2-26. Ebenen der parallelen Datenverarbeitung

Ein Prozess ist die dynamische Ausführung eines Programms

Der Zustand (Mikrobene) eines Prozesses ist durch den Datenzustand aller (privaten) Prozessvariablen, globaler Variablen, und dem Kontrollzustand (Instruktion) bestimmt

Man unterscheidet folgende Prozessklassen:

Task

Ein Task T ist die kleinste Einheit und i.A. ein Teil einer Berechnung und eines Prozesses. Man unterscheidet fein und grob granulierte Tasks. Wenige Anweisungen und wenig Rechenlast bedeuten feine Granularität. Parallele Datenverarbeitung wird durch konkurrierende Ausführung von Tasks auf verschiedenen Prozessoren erreicht.

Prozesse

Der eigentliche Prozesse ist von allen anderen Prozessen stark entkoppelt und gesichert (lose Kopplung). Die Erzeugung eines Prozesses ist rechenintensiv → schwergewichtige Prozesse. Prozesse können parallel ausgeführt werden.

Threads

Leichtgewichtige Subprozesse eines Prozesses mit mittlerer Kopplung (Datenaustausch zwischen Threads ist direkt möglich). Die Erzeugung eines Threads ist weniger rechen- und speicherintensiv. Threads können parallel ausgeführt werden.

Fibers

Sehr leichtgewichtige Prozesse mit starker Kopplung die in Threads oder Prozessen ausgeführt werden. Die Erzeugung von Fibers ist optimal. Fibers werden i.A. nicht parallel ausgeführt und daher sequenzielle und verschachtelt ausgeführt.

Scheduling

Die Ausführung von Prozessen (Threads) kann parallel auf mehreren Datenverarbeitungseinheiten (Prozessoren) geschehen → Parallele Datenverarbeitung

Häufig ist aber die Anzahl der Prozess N größer als die Anzahl der Prozessoren P

Dann müssen Prozesse die rechenbereit sind hintereinander ausgeführt werden → Scheduling

Ein Prozess kann mittels der Operationen suspend und resume blockiert oder wieder lauffähig gemacht werden

Abbildung 2-27. Grobe Sicht des zeitlichen Ablaufs (Ein- und Multiprozessorsystem) [C]

Sequenzielle und parallele Ausführung

Abbildung 2-28. Darstellung paralleler Abläufe (Beispiele) [C]

Abbildung 2-29. Varianten der Software-Parallelität mit Prozessen, Threads, und Fibers [C]

Bei der parallelen (und verteilten) Datenverarbeitung soll es eine Beschleunigung der Rechenzeit im Vergleich zum rein sequenziellen Verarbeiten geben

Aber es gibt auch in parallelen Systemen immer sequenzielle Anteile die die Beschleunigung S reduzieren

Abbildung 2-30. Begrenzung der maximalen Beschleunigung eines parallelen Systems bei einem bestimmten sequenziellen Anteil (in %): Amdahlsches Gesetz (*N*: Anzahl der Prozesse und Prozessoren)

Prozesse

Prozesszustände

Ein Prozess kann sich in verschiedenen Ausführungszuständen (Makroebene) befinden:

New

Ein Prozess wird erzeugt und der Code und Daten aus einer Datei gelesen

Ready/Ready Suspended

Der Prozess ist rechenbereit (ausführungsbereit), aber wird noch nicht vom Prozessor ausgeführt

Running

Der Prozess wird von einem Prozessor ausgeführt (Ein Prozessor oder Prozessorkern kann immer nur einen Prozess ausführen)

Waiting/Blocked/Suspended

Der Prozess wartet auf ein Ereignis (Daten, Zeitintervall, Ressource frei, usw.). Man unterscheidet u.U. Blockierung und Suspendierung (Details: Art und Weise der Blockierung)

Abbildung 2-31. Grundmodell mit drei Zuständen [C]

Abbildung 2-32. Übergangsdiagramm von Prozesszuständen (Details)

Prozessblockierung

Ein rein sequenzielles Programm wird solange schrittweise ausgeführt bis die letzte Anweisung verarbeitet wurde

Prozessblockierung bedeutet das Anhalten eines Prozesses an einer bestimmten Stelle im Programmfluss mit späterer Ausführung an genau dieser unterbrochenen Stelle!

Parallele Datenverarbeitung und VMs

Da Virtuelle Maschine i.A. ein automatisches Speichermanagement besitzen ist schwierig oder ineffizient eine VM mit einem gemeinsamen Heap und VM Zustand zwischen Threads zu teilen

Gefahr der Dateninkonsistenz

Alternativ Schutz durch Mutualen Ausschluss bei jeglicher Art der Speicherverwaltung → Aber: Ständig wird Speicher verwaltet (in jeder Anweisung!)

Daher wird folgendes parallele Ausführungsmodell bei VMs gewählt:

Jeder Thread führt eine eigen VM aus (mit eignen GC, Heap, und Zustand)

Kommunikation zwischen Threads über einen seriallisierten gemeinsamen Speicher (Store), über den Daten ausgetauscht werden können

Abbildung 2-33. Das parallele Ausführungsmodell der LUAJIT UV VM (lvm)

Asynchrone Ereignisverarbeitung

Neben der Parallelisierung der reinen Datenverarbeitung (Berechnung) kann auch eine Partitionierung von Ein- und Ausgabe bzw. der Ereignisverarbeitung erfolgen

Bekanntes Beispiel: Geräteinterrupts mit einfachen Foreground-Background System mit zwei Prozessen:

P1: Hohe Priorität (Ereignisverarbeitung → Interrupthandler → Foreground Prozess)

P2: Niedrige Priorität (Berechnung → Hauptprogramm → Background Prozess) mit Preemption durch Ereignisverarbeitung

Ein- und Ausgabeoperationen eines Programms können synchron (blockierend) oder asynchron (im Hintergrund verarbeitet und nicht blockierend) ausgeführt werden.

Beispiel Lua

Synchrone Operationen liefern das Ergebnis in einer Datenanweisung zurück die solange blockiert wird bis das Ereignis eintritt(Ergebnisdaten verfügbar sind). Dabei werden zwei aufeinander folgende Operationen sequenziell ausgeführt, und eine folgende Berechnung (nicht ereignisabhängig) erste nach den Ereignissen ausgeführt:

x = IO1(arg1,arg2,..)
y = IO2(arg1,arg2,..)
z = f(x,y)

Bei der asynchronen (nebenläufigen) Ausführung von ereignisabhängigen Operationen wird das Ergebnis über eine Callback Funktion verarbeitet. Die IO Operation blockiert nicht. Vorteil: Folgende Berechnungen können unmittelbar ausgeführt werden.

IO1(arg1,arg2,..,function (res) x=res end)
IO2(arg1,arg2,..,function (res) y=res end)
z = f(x,y) -- Problem?

Abbildung 2-34. Ereignisbasierte Verarbeitung von asynchronen Operationen in node.js/jxcore: Ein JS Thread verbunden über die Eventloop mit *N* IO Threads

Synchronisation

Asynchrone Ereignisverarbeitung mit preemptiven Verhalten benötigt explizite Synchronisation (Locks...) zur Atomarisierung von kritischen Bereichen

Asynchrone Ereignisverarbeitung spaltet den Datenfluss auf und benötigt Daten- und Ergebnissynchronisation über Prädikatsfunktionen oder explizite Synchronisation:

local x,y,z
function P(f,x,y,z)
  if x ~= nil and y ~= nil then
    return f(x,y)
  else return z end
end
IO1(arg1,arg2,..,function (res)  x=res; z=P(f,x,y,z) end)
IO2(arg1,arg2,..,function (res)  y=res; z=P(f,x,y,z) end)

Digitale Signalverarbeitung

Digitalisierung als erste Stufe der Signalverarbeitung

Die AD-Wandlung setzt i.A. ein Frequenzfilter (Tiefpass) am Eingang voraus, mit dem der zu erfassende Spektralbereich des Signals begrenzt wird. In der sog. Sample&Hold-Schaltung wird das analoge Signal zeitdiskretisiert, und anschließend mit dem eigentlichen AD-Wandler in einen diskreten i.A. binärkodierten Digitalwert umgesetzt.

Digitale Signalverarbeitung als zweite Stufe

Die Eingangsdaten stehen als kontinuierlicher Datenstrom für die weitere Verarbeitung zur Verfügung. Ein Eingangsdatenstrom wird in einen Ausgangsdatenstrom transformiert.

Erzeugung analoger Signale als dritte Stufe

Die DA-Wandlung kann nur ein quasi-analoges Signal (immer noch zeit- und wertdiskret!) erzeugen. Eine ”Zeit- und Wertglättung” findet hier ebenfalls unter Verwendung eines Tiefpass-Frequenzfilters statt

Abbildung 2-35. DSP Architektur

Zusammenfassung

Bei der Materialintegration von Berechnung (Materialinformatik) findet ein Übergang von Mikro- zu Nanorechnern mit starken Einschärnkung hinsichtlich Rechenleistung und Speicher statt

Bei der Bewertung von Rechnern sind jetzt auch Chipfläche und Energiebedarf zu berücksichtigen

Virtualisierung kann auf vielen Ebenen erfolgen und ist auch in einem Sensorknoten und Netzwerk wünschenswert

Aber eine Virtuelle Maschine erzeugt einen "Overhead": Erhöhter Rechenbedarf (gerade Speichermanagement) und Speicherbedarf

Ein- und Ausgabeoperationen können synchron (blockierend) oder asynchron (und parallel) ausgeführt werden. Letztere Methode bedarf besonderere Programmierung mit Prädikatfunktionen.

Architektur und Funktion von Sensorknoten

Wie ist ein Sensorknoten aufgebaut?

Welche Randbedingungen gelten bei dieser Art von Eingebetteten Systemen?

Wie werden Sensoren angebunden?

Wie kommunizieren Sensorknoten?

Sensorevolution

Intelligente Sensoren und Anstieg der Sensordichte

Entwicklung von Sensoren mit integrierten Informations- und Kommunikationstechnologien

Generation 1: Diskrete Sensoren, getrennte Sensorverarbeitung

Generation 2: Integrierte Smarte Sensoren

Generation 3: Netzwerke und Internetkonnektivität

Generation 4: Sensorclouds, IoT, MIIS

Abbildung 3-1. Exponentieller Anstieg der aktiven Sensoren entlang der Zeitachse

Eingebettetes System

Komponenten

Prozessor, i.A. RISC Architektur,

Nichtflüchtiger Programm- und Datenspeicher ROM (Read Only Memory), i.A. FLASH ROM

Flüchtiger Programm- und Datenspeicher RAM (Random Access Memory), i.A. DRAM

Timer und Clock Generator

IO

Verdrahtete serielle Kommunikation mit I2C / UART / RS232

Verdrahtete serielle Kommunikation mit Ethernet

Drahtlose serielle Kommunikation mit Bluetooth (kurzreichweitig, P2P)

Drahtlose serielle Kommunikation mit WLAN (kurzreichweitig, P2M)

Drahtlose serielle Kommunikation mit WWAN (langreichweitig, P2M)

General Purpose IO (Digitale Ports)

Analoge Eingänge mit ADC

Energieversorgung

Spannungskonverter

Spannungsüberwachung (Watchdog)

Energiegewinnung

Energiespeicher

Rapsberry PI

Abbildung 3-2. Raspberry Pi 3 Rechnerarchitektur [xdevs.com/article/rpi3\_oc]

Modellierung eines Sensorknotens

Abbildung 3-3. Komponenten eines Sensorknotens (Datenflussarchitektur)

Sensormodell: Ein Sensorknoten ist mit verschiedenen Sensoren verbunden.

Dehnungsmessstreifen (elektrische Größe)

Energiesensor (Ladezustand eines Energiespeichers ∼ Ladespannung)

Energiemodell: Jeder Sensorknoten verfügt über einen Energiespeicher, der

Über eine zeitlich fluktuierende Energiequelle (Energy Harvester) mit Energie gespeist wird, und der

Durch Berechnungs- und Kommunikationaktivität des Sensorknotens entladen wird.

image-placeholder
(3-1)

Die Bilanzierung der Energie kann vereinfacht werden: Jede elementare Berechnung des Sensorknotens benötigt die gleiche Energiemenge einstruction.

Energiemanagement muss verwendet werden, um mit der zur Verfügung stehenden Energie E(t) die Aufgaben und Ziele

Lokal (Knotenebene) und

Global (Netzwerk) zu erfüllen.

Prozessor

Tasks und Prozesse sind softwarebasierte oder virtuelle Einheiten. Ein Prozessor, oder allgemein eine Datenverarbeitungseinheit (Processing Element PE) ist eine hardwarebasierte physikalische Ressource, deren Anzahl und Eigenschaften i.A. zur Laufzeit fest (statisch) sind. Ein oder mehrere Prozesse {P₁,P₂,..} sowie Taks {T₁,T₂,..} können temporal verteilt einem Prozessor PE zugeteilt und von ihm ausgeführt werden.

Programm

Schrittweise Ablaufvorschrift von Anweisungen {A₁,A₂,..}

Datenpfad

Der Datenpfad eines Programms stellt alle funktionalen Anteile (mit arithmetischen, relationalen, und booleschen Operation) und den Datenspeicher dar (Register, Speicherblöcke).

x = (a+b)/100;
y = f(a,b-1);

Beispiel 3-1. Beispiel für Datenpfadberechnungen in Lua

Kontrollpfad

Der Kontrollpfad eines Programms beschreibt und steuert die schrittweise Berechnung, die sich mit einem Kontrollflussgraphen bzw. Zustandsgraphen darstellen lässt. Der Programmfluss kann von der Entwicklung von Daten abhängen.

for i = 1 to 20 do x = x * i; end;
if x < 0 then x := 0; end;

Beispiel 3-2. Beispiel für Kontrollpfadanweisungen in Lua

Abbildung 3-4. (Links) Programm (Mitte) Kontrollpfad als Zustandsdiagramm (Rechts) Datenpfad auf Registerebene

Softwarearchitektur und Abstraktion

Abbildung 3-5. Softwareebenen in einem Sensorknoten und Abstraktionsebenen [SNTP, Meroth, 2018]

Rechnerarchitekturen

Datenverarbeitung kann prinzipiell

Programmgesteuert mit einem generischen oder anwendungsoptimierten Prozessor [dynamisch], oder

Anwendungsspezifisch [statisch] mit Register-Transfer Logik Architekturen implementiert werden. Hier wird die Maschine zur Entwicklungszeit festgelegt.

Klassifikation von Parallelrechnerarchitekturen kann basierend auf dem Flynn’schen Modell erfolgen. Klassifikation nach

Datenstrom und

Instruktionsstrom

zwischen Speicher- und Datenverarbeitungseinheiten.

SISD

Single-Instruction Single-Data Stream

Abbildung 3-6. SISD Klassifikation nach Flynn: Von-Neumann Rechnerarchitektur [Tokhi,2003]

SIMD

Trennung von Instruktions- und Datenspeicher

Ggfs. mehrere Datenspeicher

Abbildung 3-7. Übergang von von-Neumann zu Harvard Rechnerarchitektur [Tokhi,2003]

Single-Instruction Multiple-Data Stream

Abbildung 3-8. SIMD Klassifikation nach Flynn [Tokhi,2003]

MIMD

Multiple Instruction Multiple Data Streams

Parallelrechnerarchitektur

Abbildung 3-9. MIMD Klassifikation nach Flynn [Tokhi,2003]

Shared-Memory und Distributed-Memory Multiprozessor Architektur

Abbildung 3-10. SM (stark gekoppelt) und DM Architektur (schwach gekoppelt) [Tokhi,2003]

Applikationsspezifische Prozessoren

Generische Mikroprozessoren sind limitiert durch

fehlende oder eingeschränkte Parallelität im Datenpfad - meist nur eine Berechnung, i.R. eine funktionale Operation mit maximal zwei Operanden, pro Bearbeitungszyklus möglich (Ausnahme bei Pipelining und replizierten ALUs)

eingeschränkte Unterstützung bei Parallelität im Kontrollpfad - nur Pipelining mit Ausführung von mehreren Anweisungen in verschiedenen Phasen/Modulen der Verarbeitungspipeline und einfaches Multi-Threading

Multiprozessor Betrieb ermöglicht nur grob garnulierte Parallelität

Shared-Memory als globales Objekt führt zu erhöhter sequenzieller Ausführung (Mutex Scheduler muss Wettbewerb auflösen).

zentralern Hauptspeicher.

Fazit: Schlechte Performanz in Latenz und Datendurchsatz, nur grob granulierte Parallelität.

Anwendungsspezifische Mikroprozessoren

erweitern generische Prozessoren mit zusätzlichen Registern, Maschinenbefehlen, und spezialisierten und optimierten Funktionseinheiten.

Es wird unterschieden: erweiterbar und rein applikationsspezifisch

Vorteile erweiterbar:

Mikroprozessorkern und Software-Compiler existieren

Nachteile erweiterbar:

Nur eingeschränkte Möglichkeiten der Erweiterung, keine Anpassung von Datenwortbreiten, Architekturanpassungen, etc.

Vorteile appliaktionsspezifisch:

Verbesserte Möglichkeiten der Optimierung wie Datenwortbreite, Anzahl der Bussysteme, Kommunikationsstrukturen, Architektur, usw.

Nachteile applikationsspezifisch:

Es existieren keine getesteten oder verifizierten Prozessorkerne und Software-Compiler; Entwurfsprozeß daher fehleranfällig und deutlich langwieriger als bei erweiterbaren Mikroprozessoren

Erweiterbare Mikroprozessoren können bereits gefertigt sein, und sind mit (externen) Erweiterungsschnittstellen ausgestattet, um optimierte Funktionseinheiten wie z.B. Decoder, Encoder, oder kryptographische Funktionen zu implementieren.

Kanalbasierte Datenverarbeitung

Queues und Pipelines

Parallele Systeme die aus mehreren Prozessoren oder Verarbeitungseinheiten bestehen erfordern Datenaustausch und Synchronisation.

Queues (First-In First-Out FIFO Speicher) können zum synchronisierten Datenaustausch zwischen einem Datenproduzenten und Konsumenten (zwei Prozessoren, Prozesse, oder PEs) verwendet werden.

Synchronisation:

Blockierung des Produzenten wenn die Queue vollständig gefüllt ist, und

Blockierung des Kosumenten wenn die Queue kein Datenwort enthält (leer ist).

Abbildung 3-11. Queues zum synchronem Datenaustausch zwischen Verarbeitungseinheiten und Verwendung in Pipelines

Abbildung 3-12. Verwendung von Queues in Pipelines zur Steuerung des Datenflusses

Kommunikationsschnittstellen

Es wird unterschieden zwischen interner und externer Kommunikation eines Sensorknotens

Interne Kommunikation

Anbindung von Peripheriegeräten wie Sensoren und Energiemanagement, z.B. mit I²C oder USB Verbindungen.

Externe Kommunikation

Verbindung von Sensorknoten über drahtgebundene oder drahtlose Verbindungen, z.B. mit WLAN, Bluetooth, oder RFID.

Universelle Digitale Ein- und Ausgänge

Abbildung 3-13. Universelle Ein- und Ausgänge müssen die Signalrichtung, den Spannungspegel, und ggfs. eine Isolation (bei Bussystemen) schlatbar ermöglichen. Häufig sind die Schnittstellen mit digitalen Registern verbunden. [SNTP, meroth, 2018]

Ein- und Ausgänge können unterschiedliche elektronisch beschaltet werden

Abbildung 3-14. (Oben) Beschaltung von Eingängen (Unten) Beschaltung von Ausgängen [SNTP, meroth, 2018]

Nachrichtenbasierte Kommunikation

Abbildung 3-15. Vertikale und horizontale Kommunikation im Schichtenmodell: Nachrichtenbasierte Kommunikation kann über verschiedene technische Schnittstellen und Protokolle stattfinden [SNTP, Meroth, 2018]

Übertragungsarten

Abbildung 3-16. (Links) Übertragungsarten Simplex, Vollduplex und Halbduplex (Rechts) Unsymmetrische und symmetrische Übertragung [SNTP, Meroth, 2018]

I2C

Häufig verwendete Zweidraht Kommunikationstechnologie und Protokoll für die Anbindung von Sensoren, Aktuatoren, und Schnittstellengeräten

Der I2C-Bus (oder I2C) wurde von der Firma Philips (heute NXP) [7–9] entwickelt und ermöglicht die Vernetzung von Mikrocontrollern, Sensoren und anderen Bausteinen wie: RAM- und EEPROM-Speicher, A/D-, D/A-Wandler, Port Erweiterungen, LCD- und LED-Display Ansteuerungen, Echtzeituhren, Radio- und TV-Empfänger, I2C-Bus Erweiterungen und vielen anderen.

Der I2C-Bus funktioniert nach dem Master-Slave Prinzip.

Master ist derjenige Busknoten, der die I2C-Kommunikation initiiert und beendet, den Takt für die Synchronisation der Datenübertragung bereitstellt und entsprechend der einprogrammierten Software Kom- munikationsprobleme erkennt und löst. Jeder Slave besitzt eine Adresse, die ihn in einem Bus eindeutig identifiziert. Die Adresse kann 7 oder 10 Bit groß sein und ermöglicht die Adressierung von 128 bzw. 1024 unterschiedlichen Slaves im selben Bus.

Abbildung 3-17. (verschiedene I2C Modi und deren maximale Übertragungsraten [SNTP, Meroth, 2018]

Serial Peripheral Interface (SPI)

Die getaktete serielle Schnittstelle SPI (Serial Peripheral Interface), bisweilen auch Clocked Serial Interface (CSI) genannt, die in vielen Prozessortypen zur Verfügung steht, bietet einen der populärsten Wege, auf Sensoren auf der Leiterplatte oder außer- halb des Gehäuses zuzugreifen.

Durch die Übertragung des Taktes auf einer getrennten Takt- leitung (CLK, zuweilen auch SCK genannt) erlaubt sie die Synchronisation zwischen Sender und Empfänger bei wesentlich höheren Datenraten als bei asynchronen Schnitt- stellen.

Abbildung 3-18. SPI verwendet Schieberegister um Daten seriell zu übertragen

Abbildung 3-19. (Links) Multigerätevebrindung als Bussystem (Rechts) Ablauf einer SPI Sequenz mit Befehlsbyte [SNTP, Meroth, 2018]

Zusammenfassung

Ein Sensorknoten besteht aus:

Datenverarbeitung (Mikroprozessor)

Datenspeicher (RAM, DRAM, SRAM, ROM, EEPROM)

Energie (Speicherung, Gewinnung, Management)

Kommunikation

intern (intrinsisch)

extern (extrinsisch)

Sensoren

Aktuatoren und Mensch-Maschine Schnittstellengeräte (optional)

Sensornetzwerke

Wie können Sensorknoten vernetzt werden?

Welche Randbedingungen gelten in Kommunikationsnetzwerken?

Was ist besonders and materialintegrierten Netzwerken?

Sensoraggregation

In sensorischen Systemen werden Sensordaten in verschiedenen Ebenen verarbeitet:

Vertikale Ebenen

Perzeption (Erfassung)

Hier findet die Akquisition der rohen Sensordaten statt. Die Sensoren sind räumlich verteilt und werden lokal vorverarbeitet.

Aggregation

Einzelne Sensordaten werden zeitlich und räumlich zusammengeführt und gesammelt (Sensorfusion)

Applikation

Die gesammelten Daten werden nutzbar gemacht: Weitere Datenverarbeitung, Aufbereitung, Eigenschaftsselektion, Informationsgewinnung, Visualisierung

Horizontale Ebenen

Die horizontalen Ebenen durchziehen alle vertikalen Ebenen:

Sicherheit

Datenverarbeitung

Kommunikation

Datenspeicherung

Nachrichtenvermittlung

Management

Abbildung 4-1. Grundlegender Zusammenhang der horizontalen und vertikalen Ebenen in Sensorischen Systemen

Abbildung 4-2. Räumliche Abbildung der vertikalen Ebenen auf Cloud Computing

Sensorfusion

Sensor Fusion: viele Sensoren helfen viel?

Sensorfusion bedeutet in verteilten Sensornetzwerken häufig Aggregation durch Kommunikation zwischen Sensorknoten

Die Genauigkeit einer Messung bzw. das Vertrauen in einen Messwert lässt sich durch Zusammenschluss und Korrelation mehrerer verschiedener Sensoren R₁,R₂, ... und Sensorsignale erhöhen sr1,sr2,.. ⇒ Sensordatenfusion

So kann z.B. gleichzeitig die Dehnung mit einem Dehnungssensor (Wandlung in elektrische Widerstandsänderung) und die Temperatur mit einem Temperaturssensor gemessen werden, um auch systematischer Fehler durch Temperaturdrift der Übertragungsfunktion kompensieren zu können.

Durch die Spannungsversorgung und ein Stromfluss I=U/R erwärmt sich ein Dehnungsmessstreifen gegenüber dem Messkörper. Je nach Wärmeleitfähigkeit des Messkörpers wird die Wärmeleistung mehr oder weniger an den Messkörper abgegeben. Bei schlecht wärmeleitenden Messkörpern kann es somit zu einem Temperaturunterschied zwischen Messkörper und Dehnungsmessstreifen kommen.

Abbildung 4-3. Gleichzeitige Messung von Temperatur und Dehnung führt zu einer Korrekturfunktion [www.hbm.com]

Relative Widerstandsänderung des Dehnungsmesstreifens mit Temperaturkorrektur:

image-placeholder
(4-1)

Abbildung 4-4. Multisensorfusion

Klassifizierung Fusion

Redundanz

Mehrere Sensoren messen parallel die gleiche Messgröße (Eigenschaft), z. B. mehrere Temperatursensoren messen die Temperatur eines Körpers

Vielfältigkeit

Mehrere Sensoren messen verschiedene aber korrelierte Messgrößen, z. B. gleichzeitige Messung von Temperatur, Druck und Feuchtigkeit.

Bereich

Mehrere Sensoren messen die gleiche Meßgröße aber in verschiedenen Messbereichen, z. B. mehrer Temperatursensoren messen am gleichen Ort verschiedene Temperaturbereiche.

Zeit

Aktuelle Messungen von Signalen von Sensoren werden zeitlich mit historischen Informationen korreliert, z. B. von einer früheren Kalibration.

Sensor System Konfigurationen

Komplementär

Die Sensoren sind unabhängig voneinander und vervollständigen Informationen

Konkurrierend

Jeder Sensor liefert unabhängig eine Messung der gleichen Messgröße

Kooperativ

Sensoren liefern zusammen Informationen die einzelnen nicht verfügbar wären

Schätzung (Estimation)

Mit Schätzungstechniken lässt sich die Präzision von Messungen schlechter Qualität verbessern:

Mittelwertbildung (Minderung der statistischen Fluktuation)

Tiefpassfilter

Wiener Filter

Kalmann Filter

Modelbasierte Filter

Verteilte Sensornetzwerke

(Distributed Sensor Networks DSN)

Ein verteiltes Sensornetzwerk besteht aus einer Menge von Sensor Knoten N={n₁,n₂,...}, die in einem Kommunikationsnetzwerk miteinander verbunden sind.

Ein Sensorknoten besteht aus:

Einer Menge von Sensoren S={s₁,s₂,...}, wenigstens einem Sensor s (inkl. virtuellen),

Analoger Signalverarbeitung inkl. ADC A={a₁,a₂,...}

Digitale Signal- und Datenverarbeitungeinheiten P={p₁,p₂,..} und Speicher M={m₁,..}

Kommunikationsmodule C={c₁,c₂,...},

Energieversorgung und Managementmodule E={e₁,e₂,..}

Abbildung 4-5. Aufbau und Konnektivität eines Sensorknotens

Verteilte Sensornetzwerke unterscheiden sich von klasschischer Datenverarbeitung

DSN können räumlich und zeitlich verteilt sein - ohne zentralen Rechner

Das Netzwerk selber ist der Rechner - eine virtuelle Maschine

Abbildung 4-6. Von zentraler Nutzer-Applikations-orientierter (a) zu dezentraler Sensor-orientierter Datenverarbeitung (b) [miss2k.G]

Anforderungen an und Fähigkeiten von DSN

niedrige Kosten

zuverlässig und robust gegen Störungen (Kommunikation, Energie, Ausfall von Knoten)

Autonomie eines Sensorknotens

schnelle Antwortzeit (Latenz)

Eignung für echtzeitfähige datenstrombasierte Verarbeitung

lange Betriebszeiträume

Kombination von verschiedenen senorischen Größen zu neuen Informationen, die durch einen einzlnen Sensor bzw. Sensorknoten nicht verfügbar wären → Daten- und Sensorfusion

Erhöhter Datendurchsatz durch nebenläufige Datenverarbeitung der einzelnen Sensorknoten

Redundanz und Fehlertoleranz durch komplimentäre Gruppenbildung und Wettbewerb sowie Kooperation von Sensorknoten

Zeitliche Synchronität → Synchronisation von Uhren

Kommunikation in DSN

Nachrichtenbasierte Vermittlungsnetzwerke

Ein Knoten eines Netzwerkes ist

Quelle von Nachrichten, die Daten und somit Sensoren kapseln,

Empfänger von Nachrichten, und

Vermittler (Router) von Nachrichten (Zwischenknoten)

Ad-hoc Netzwerke

Ad-hoc Netzwerke deren Struktur und Verbindungen sich erst zur Laufzeit bilden.

Dabei kann sich die Struktur (Netzwerktopologie) dynamisch ändern.

Es können Knoten und Verbindungen zwischen Knoten hinzukommen und verschwinden.

Selbstorganisation und Selbstkonfiguration können wesentliche Prinzipien wärend der Bildung und danach sein.

Sensorknoten (aka motes)

Übliches Designziel: klein und gunstig

Mikroprozessor

wenige MHz bis einige hundert MHz

energiesparende Zustande

Speicher

haufig nur wenige KB Arbeitsspeicher

teils zusatzlich Flashspeicher fur Code und Daten

Sensorik

Temperatur, Licht, Druck, Beschleunigung, Ultraschall uvm.

Drahtlose Kommunikation

Reichweiten von wenigen Metern bis einige hundert Meter

Erste Standards, z. B. IEEE 802.15.4 (WPAN) und ZigBee

Energieversorgung

heute meist Batterien

in Zukunft: Solarzellen und anderes Energy Harvesting

Ausbringung

Keine zentrale Infrastruktur

Initiale Position haufig unbekannt

Multihop-Kommunikation

Aufgaben

Erkennen / Melden von Ereignissen

Beantworten von Anfragen

Abbildung 4-7. (Links) Technologien von Sensorknoten für Ad-hoc Netzwerk (Rechts) Dynamische Netzwerkstrukturen [KIT]

Herausforderungen

Geringes Energiebudget

geringe Leistung ↔ (jahre-)lange Bereitschaft

Lastbalancierung, Aufteilung von Aufgaben

Geringer Speicher, geringe Rechenleistung

verteilte Losungen ↔ komplexe Selbstorganisation

Viele Sensorknoten

Algorithmen müssen gut mit Größe des Netzes skalieren

Geometrie

enger Zusammenhang zwischen Positionen und Daten/Aufgaben

gemeinsame Nutzung und Störung der Funkkanäle

Redundanz, Unzuverlässigkeit und Dynamik

Knoten können ausfallen, sich bewegen

viele Knoten können Aufgaben redundant ausführen

Anwendungen

Umweltüberwachung

Waldbrände, Gletscherbewegungen

Bewässerung von Agrarflachen

Schadstoffe (chemisch, radioaktiv)

Beobachtung von Tieren

Überwachung von Brutstätten, Bewegungen

Intelligente Zäune

Internet of Things

Smart Cities, Smart Homes

Vernetzung alltäglicher Produkte

Medizinische Überwachung

Patienten im Krankenhaus

Sicherheit

Grenzüberwachung

Überwachung von Gebäuden

Verkehrsoptimierung

Stauwarnungen

Materialintegrierte Sensorsysteme

Strukturüberwachung

Smart Things

Artificial Skin

E-Textiles

IP Kommunikation

Internet Kommunikation mit dem Internet Protocol (IP)

Netzwerkknoten benötigen eindeutige IP Adresse (nicht für MISS geeignet!)

IP-4

IP-6

Das Internet ist ein Netz aus Netzen (hierarchisch und verteilt)

Netzwerkadressen werden in räumlichen Domains zusammengefasst (IP4)

Geräte benötigen daher lokale IP Adressen (u.U. wechselnd)

IP6 ordnet Geräten eindeutige Adressen zu (mobil)

Abbildung 4-8. Domainen im Internet und Netze aus Netzen

Private Netzwerke und die immer größer werdende Anzahl von Geräten erfordern bei IP4 NAT (nicht bei IP6)

NAT: Netwrok Address Translation

Abbildung 4-9. Kommunikation zwichen privaten IP Netzwerken über NAT

Remote Procedure Call

Der RPC dient der Klienten-Server Kommunikation, wobei anders als bei HTTP Servern die Rolle von Klient und Server beliebig getauscht werden kann

Es gibt drei Operationen:

Get Request (port)

Der Serverprozess gibt die Verarbeitung von RPC Anfragen auf einem bestimmten Port bekannt.

PutReply (client)

Der Serverprozess sendet eine Antwort auf eine RPC Anfrage

Transaction (port,data)

Der Klientenprozess sendet eine RPC Anfrage an einen Server (port) und wartet auf die Antwort

RPC ist Interprozesskommunikation!

Neben Datenübertragung dient RPC zur Ausführung von Prozeduren (Funktionen) mit Daten!

LUAOS

rpc = rpc:new()

rpc:getreq

function (host:string,port:number,handler: function (data:table) → table|nil)
Ein Server wird gestartet. Die benutzerdefinierte Handlerfunktion wird bei jedem Request aufgerufen und muss einen Datenrekord zurückgegben (oder nil)

rpc:putrep

function (client:userdata, data:table)
Der Server sendet die Rückantwort (implizit in rpc:getreq enthalten)

rpc:trans

function (host:string,port:number,data:table) → error:nil|string,table|nil
Ein Servertransktion durch einen Klienten.

local rpc = rpc:new()
rpc:getreq('127.0.0.1',12345, function (request)
  local reply = {}
  print(request)
  case request.cmd of
    "square" => y=request.x*request.x;  reply = { status = "OK", y = y } end
    "sqrt"   => y=math.sqrt(request.x); reply = { status = "OK", y = y } end
    else reply = {status = "EINVALIDMCD" } end
  end
  return reply
end)

Beispiel 4-1. LUAOS Serverprozess

local rpc = rpc:new()
local err,reply = rpc:trans('127.0.0.1',12345,
  {
    cmd='square',
    x=math.random()
  })
if err then print(err) else print(reply) end

Beispiel 4-2. LUAOS Klientenanfrage

LUAOS

Konzept

LUAOS: Lua Operating System

LUAOS wird auf einem Rechner (Netzwerkknoten) durch eine Lua VM ausgeführt (lvm)

LUAOS bietet einen WEB basierten Zugriff auf Rechnerknoten

Skriptausführung über eine Shell mit Monitoring

LUAOS:

Ausführung von Skripten in einem Sandkasten

Scheduling und Multithreading

Einfache Sensor und Geräte API

Ein Skript wird in einem eigenen gekapselten Thread ausgeführt (mit jeweils eigenen Ausführungszustand und VM)

Ein Skript kann weitere Fibers erzeugen

Ein Skript hat einem maximale durchgehende Laufzeit von einer Sekunde (danach wird das Skript abgebrochen)

Die Ausführung muss daher durch blockierende IO, der yield, oder der sleep Funktionen unterbrochen werden

WEB Interface

Das LUAOS ist über ein WEB Interface erreichbar

Abbildung 5-1. Typische Schnappschuss der LUAOS WEBAPI mit Netzwerkübersicht (links oben) und verschiedenen Fenstern

LUAOS Architektur

Abbildung 5-2. Verteiltes LUAOS System mit WEB API

LUVM Architektur

Die LUAOS VM (LUVM) besteht aus:

LUA Parser → Skripttext wird direkt in Bytecode Instruktionen übersetzt (kein Parserbaum und AST)

LUA Bytecode Interpreter (BC Loop ist in Assembler programmiert!)

LUA JIT Compiler der zur Laufzeit BC in nativen Maschinencode übersetzt

LUA-C API für native Erweiterungen

Automatisches Speichermanagement mit Garabage Collector (Nicht inkrementeller Mark & Sweep Algorithmus)

Asynchrone IO mit einer UV Loop (libuv, wird auch in node.js verwendet)

LUV: LUA-UV API Interface

LUV Module: Thread, Fiber, State, Filesystem (FS), Network (Net), Timer, Process, Pipe, Codec (Serialisierung)

Abbildung 5-3. Aufbau der LUAOS VM

Skript API

function clock() → number

Gibt die aktuelle Systemzeit in Millisekunden zurück

function print(...)

Ausgabe von Text oder Werten auf der virtuellen Konsole

function sleep(millisec)

Der aufrufende Prozess wird für die angegebene Zeit blockiert

function yield()

Blockierender Aufruf des Schedulers und Abgabe der Ausführung (an andere Prozesse) mit späterer Fortführung

Fiber (koroutinen)

Leichtgewichtige Tasks (werden geschachtelt sequenziell ausgeführt)

function fiber.create (function(args...), args...) → fiber

Erzeugt einen neuen leichtgewichtigen Prozess. Der Prozess ist sofort ausführungsbereit.

function fiber:join()

Der aufrufende Prozess wird blockiert bis der Subprozess terminiert ist

HTTP

HTTP Server und Klienten

function http:new() → http

Erzeugt eine neue HTTP Instanz

function http:get(url, function (data,error))

Ausführung einer HTTP GET Anfrage. Das Ergebnis (Fehler oder Daten) wird durch eine asynchrone Rückruffunktion bearbeitet.

function http:put(url, data, function (data,error))

Ausführung einer HTTP OUT Anfrage. Das Ergebnis (Fehler oder Daten) wird durch eine asynchrone Rückruffunktion bearbeitet.

function http:service(ipport, function (url,address,params,body) → string)

Installation eines HTTP Service (IP Port ipport). Eingehende GET/PUT Anfragen werden durch eine Rückruffunktion bearbeitet. Das Ergebnis der Anfrage wird von dieser Funktion als Text zurück gegeben.

HTML

Ein HTML Text Formattierer

function html:new() → html

Erzeugt eine neue HTML Formattierungssnstanz

function html:html(head:html string,body: html string) → string

Erzeugt den Rahmen einer HTML Seite

function html:head() → string

Erzeugt den Kopf einer HTML Seite

function html:body(html string table) → string

Erzeugt den Inhalt einer HTML Seite

function html:table(head table, body table table) → string

Weitere Funktionen: h1, h2, h3, ol, ul, li, dl, dt, dd

Timer

Intervalltimer die in Fibers und Skripten benutzt werden können um periodisch Tasks auszuführen

function timer:new() → timer

Erzeugt einen neuen Timer.

function timer:start(interval:number,period:number)

Startet den Timer mit dem angegebenen Intervall und der Periodenzeit (oder 0). Nach Ablauf des Intervalls wird ein Ereignis signalisiert, auf welches mit der await Operation gewartet werden kann.

function timer:stop()

Stoppt den Timer. Es werden keine weiteren Ereignisse mehr signalisiert.

function timer:wait()

Auf ein Timerereignis warten. Der aufrufende Prozess wird blockiert.

Sensor

Zugriff auf und Implementierung von Sensoren

function sensor:all() → table

Gibt eine Liste alle verfügbaren Sensoren zurück (Liste der Namen)

function sensor:new(sensorclass:string,...) → sensor

Erzeugt eine neue Sensorinstanz vom Typ sensorclass. Mögliche Klassen sind: "temperature", "cpu".

function sensor:read() → number|string|table|nil

Gibt den aktuellen Sensorwert zurück.

function sensor:calibrate?(...)

Kalibriert den Sensor oder die Sensorfunktion.

Actor

function actor:all() → table

Gibt eine Liste alle verfügbaren Aktuatoren zurück (Liste der Namen)

function actor:new(actorclass:string,...) → actor

Erzeugt eine neue Aktuatorinstanz vom Typ actorclass. Mögliche Klassen sind: "dotdisp"".

function actor:reset(...)

Setzt den Aktuator in einen definierten Anfangszustanf.

function actor:set(...)

Setzt eine Steuervariable mit einem neuen Aktuatorwert.

function actor:get?(string) → number|string|table|nil

Gibt den Wert einer Aktuatorvariable zurück.

function actor:control?(...)

Ausführung eines Steuerkommandos.

Punktmatrix Ausgabegerät

8 rows and 8 cols LED matrix

Driven by HT16K33 chip

Access to I2C communication pins

Beispiele

-- Actor DOTS Matrix
local dot = actor:new('dots')
dot:reset()
-- dot:set(on,row,col)
dot:set(1,4,4)
sleep(1000)
dot:set(0,4,4)

-- Sensor CPU Temperatur
local s = sensor:new('temperature')
print(s:read())

Asynchrone Ereignisverarbeitung

Synchrone Verarbeitung

Die aufrufende Operation, z.B. das Lesen aus einer Datei, wird solange "blockiert"/wartet (genauer die Prozessausführung), bis das Ereignis eingetreten ist, d.h. im Beispiel die Daten gelesen wurde.

Eine synchrone Operation (Prozedur) gibt das Ergebnis der Operation direkt zurück

Asynchrone Verarbeitung

Die aufrufende Operation wartet nicht auf das Eintreten des Ereignisses (keine Blockierung), und der Prozesse fährt unmittelbar danach in der Ausführung folgender Operationen fort.

Jetzt wird eine Rückruffunktion verwendet, um beim Eintreten des Ereignisses die Daten (oder das Ereignis) verarbeiten zu können.

In JavaScript werden i.A. alle Ein- und Ausgabeoperation asynchron ausgeführt. In Lua gibt es eine ausgewogene Mischung, bzw. die synchrone Variante ist vorherrschend.

1: result = ioop₁synchron(arg₁,arg₂,..)
2: result = ioop₂synchron(arg₁,arg₂,..)
3: ..

Process=ioop₁synchron→ioop₂synchron→next

Synchrone Ereignisverabeitung

1: ioop₁asynchron(arg₁,arg₂,..,function₁ (p₁,p₂,..) processing end)
2: ioop₂asynchron(arg₁,arg₂,..,function₂ (p₁,p₂,..) processing end)
3: ..

Process=ioop₁asynchron→ioop₂asynchron→next..→function₁→function₂ |
ioop₁asynchron→ioop₂asynchron→next..→function₂→function₁ |
ioop₁asynchron→function₁→ioop₂synchron→next.. | ..

Asynchrone Ereignisverabeitung

Beispiele in Lua

Die sleep Operation kann verwendet um den aktuellen Programmfluss für eine bestimmte Zeit (Millisekunden) anzuhalten

local s = sensor:new('temperature')
local doit = true
while doit do
  local v = s:read()
  print ('The current temperature is '..v)
  sleep (1000)
end

Beispiel 5-1. Synchrone Verzögerung einer Serviceschleife

Alternativ kann auch ein Timer erzeugt werden. Nach dem Start des Timers (mittels der start Methode und der Angabe des Zeitintervalls bis ein Timerereignis ausgelöst wird und dem Zeitintervall zwischen zwei Ereignissen) kann mittels der wait Methode der Prozessfluss angehalten werden bis ein Timerereignis eintritt

local s = sensor:new('temperature')
local t = timer:new()
local doit = true
t:start(1000,1000)
while doit @do
  local v = s:read()
  print ('The current temperature is '..v)
  t:wait()
end

Beispiel 5-2. Synchrone Verzögerung einer Serviceschleife mit einem Timer

local s = sensor:new('temperature')
setInterval(1000, function ()
  local v = s:read()
  print ('The current temperature is '..v)
end)

Beispiel 5-3. Periodische asynchrone Ausführung einer Serviceschleife

local H = html:new({})
local s = sensor:new("temperature")
http:service(8080,function (req,url,remote,params)
  return H:html(H:head(),H:body({
     H:h1("Temperature"),
     H:p(s:read())
   }))
end)

Beispiel 5-4. Asynchrone Implementierung eines HTTP WEB Servers

Abbildung 5-4. Ereignisbasierte Verarbeitung von asynchronen Operationen in *lvm*: Ein Lua Thread verbunden über die Eventloop mit *N* IO Threads

Lua - Ausführungsmodelle

Threads

Es werden parallele Prozesse auf Threads abgebildet die bestenfalls 1:1 auf den CPUs / Cores ausgeführt werden, ansonsten durch einen Scheduler im Zeitmultiplexverfahren ausgeführt werden → Kontrollpfadparallelität

Prozesse können synchronisiert auf geteilte Objekte (konkurrierend) zugreifen:

Channel

Semaphore, Mutex

Event, Timer

Shared Memory Store

Prozessblockierung blockiert den gesamten Thread (somit auch alle Fibers)

Jeder parallele Prozess in einem Thread läuft in eigener VM Instanz

Daten können nicht zwischen VMs ausgetauscht werden (Automatsisches Speichermanagement und GC) → nur Austausch über Serialisierung und Kopie von Daten oder geteilte Byte Datenspeicher (Shared Buffer)!

Fibers und Koroutinen

Es werden konkurrierende (aber nicht notwendig nebenläufige) Prozesse (Koroutinen) auf Fibers abgebildet die grundsätzlich in Lua nur sequenziell durch einen Scheduler im Zeitmultiplexverfahren ausgeführt werden.

Diese Prozesse können synchronisiert auf geteilte Objekte (nicht nebeläufig) zugreifen:

Channel

Semaphore

Event, Barriere, Timer

Prozessblockierung blockiert nur eine Koroutine

Alle quasi-parallelen Prozesse mit Fibers laufen in einer VM Instanz und teilen sich den VM Datenkontext sowie besitzen den gleichen Programmkontext (direkte Teilung von Variablen und Funktionen)

Abbildung 5-5. Threadmodell und Kommunikation der Prozesse mit geteilten Objekten

IO Paralellisierung

Neben Threads, Fibers, und Prozessen kann auch die Parallelisierung von Ein- und Ausgabeoperation genutzt werden → Kontrollpfadparallelität

Asynchrone IO wird sowohl in nodejs (JavaScript) als auch in Lua (lvm) mittels der libuv Bibliothek implementiert

Verwendung von Callback Funktionen für die Daten- und Ereignisverarbeitung

Anders als in JavaScript (nodejs) wird asynchrone IO in Lua eher seltener verwendet

Fibers (Koroutinen) werden in Lua direkt durch die Lua VM verarbeitet

Threads werden über die libuv einzelnen VM Instanzen zugeordnet

Verbindung der Instanzen über libuv

Jede VM Instanz hat ihre eigene Event Loop!

Abbildung 5-6. Asynchrone IO mit der *libuv* Architektur [docs.libuv.org/en/v1.x/design.html]

Aufgabe

Was ist der Nachteil bei der Verwendung eines Timers mit explizitem Warten auf das Ereignis im Vergleich zur sleep Operation oder der asynchronen Ausführung mittels setInterval?

Was sind Vorteile und Nachteile der synchronen gegenüber der asynchronen Ereignis- und Datenverarbeitung?

Sensoren

Ziele

Verständnins der Definition und Klassifikation von Sensoren, Fokus mechanische Sensoren

Rolle im Material-integrierten Sensorsystem erkennen

Fähigkeit zur Abgrenzung: Material- vs. Struktureffekte

Sensormaterialien und direkt materialbasierte Sensoren

Mikrosystemtechnische Sensoren (Struktureffekte)

Anwendung von Optischen Sensoren

Definition Sensor

Was ist ein Sensor? [D]

Ein Sensor ist eine Einheit, die ein Signal oder einen Stimulus empfängt und darauf reagiert.

Ein physikalischer Sensor ist eine Einheit, die ein Signal oder einen Stimulus empfängt und darauf mit einem elektrischen Signal reagiert.

"Natürlicher Sensor"

Der Sensor besteht aus zwei Teilen: (1) Füllstandanzeige (2) Menschliches Auge, das ein Signal an das Gehirn sendet.

[D]

Elemente, die eine im Allgemeinen nichtelektrische Messgröße in ein elektrisches Ausgangssignal umwandeln, heißen Sensoren. Dabei kann eine aktive nachgeschaltete analoge und digitale Sensorsignalverabeitung erfolgen.

[Weinrich, Grundlagen und Messprinzipien der Sensorik, Universität Hamburg]

Veränderung und Unschärfe des Sensorbegriffs: Im ursprünglichen Sinne ist der Sensor nur der Meßfühler/Aufnehmer, heute oft alles, was im Gehäuse der "Sensoreinheit" mit verpackt ist.

Stimulus

Ein Stimulus ist eine Größe, Eigenschaft oder Beschaffenheit, die wahrgenommen und in ein elektrisches Signal umgewandelt wird.

Ein- und Ausgangssignal

Eingangssignal

Ein Sensor wandelt ein (generell) nicht-elektrisches Signal in ein elektrisches um.

Ausgangssignal

Das Ausgangssignal kann eine elektrische Spannung (Ladungen), ein Strom, ein Lichtfeld, ein Magnetfeld sein.

Messgrößen

Dass Messsignal kann weiter unterscheidbar sein durch

Amplitude,

Frequenz,

Phase,

Energiedichte (Integral).

Welcher Sensor liefert direkt ein Spannungssignal (aktiver Sensor)?

???

Sensorelement

Ein Sensorelement (einfacher Sensor) oder Messfühler wandelt die Messgröße in eine primäre elektrische Größe um.

Integrierter Sensor

Ein integrierter Sensor setzt die Messgröße in ein standardisiertes Signal um.

Intelligenter Sensor

Ein intelligenter Sensor ist ein integrierter Sensor mit rechner- gesteuerter Auswertung und digitalisierter Ausgabe.

Sensormodell

Der Sensor als "Black Box": Fasst man den Sensor als "Black Box" auf, kann er unabhängig von Prinzip und Aufbau u. a. über folgende Merkmale beschrieben werden:

Transferfunktion

Messbereichsumfang

Ausgabebereich

Genauigkeit

Kalibrierungsfehler

Hysterese

Sättigung

Wiederholgenauigkeit

Verlässlichkeit

dynamische Eigenschaften

Sensormetrik

Metrikklassen

Einteilung nach

Art der Messgröße/des Stimulus

Art der Erfassung der Messgröße/Messprinzip

Art der Umwandlung von der Messgröße zum Ausgangssignal

Material des Sensors

Einsatzgebiet des Sensors

Eigenschaften, Spezifikationen, Parametern (Empfindlichkeit etc.)

Einteilung nach Messgröße

Wegsensoren

Dehnungssensoren

Beschleunigungssensoren

Kraftsensoren

Gassensoren

Feuchtesensoren

Temperatursensoren

Lichtsensoren

Magnet(feld)sensoren

etc.

Einteilung nach Messprinzip

resistive Sensoren (primäre elektrische Größe: Widerstand)

induktive Sensoren (Induktivität)

kapazitive Sensoren (Kapazität)

piezoelektrische Sensoren (Ladung)

thermoelektrische Sensoren (Spannung)

optische Sensoren (z. B. Lichtintensität, weitere Wandlung erf.)

etc.

Sensortypen

Ein System kann verschiedene Sensortypen beinhalten:

Extrinsisch

Ermitteln von Informationen über die Systemumgebung

Intrinsisch

Ermitteln von Informationen über den internen Systemzustand

Teilweise ist der Übergang fliessend. Liefert der Beschleunigungssensor eines Smartphone eine intrinische oder extrinische Wahrnehmung?

Weiterhin Unterteilung in:

Aktive Sensoren

Erzeugen aufgrund des Messprinzips ein elektrisches Signal (z.B. Thermoelement, Lichtsensor), d.h. variieren elektrisches Signal bei Veränderung des Stimulus

Passive Sensoren

Enthalten passive Bauteile, deren Parameter durch die Messgröße verändert werden, d.h. bei Veränderung des Stimulus (z.B. resistive Thermometer oder Dehnungsmessstreifen)

Erfassungsverfahren

Die Differenzierung nach aktiven und passiven Sensoren kann nach dem Energiebedarf der Sensoren erfolgen:

Passive Sensoren modulieren ein Signal unter dem Einfluss der Messgröße und benötigen daher Hilfsenergie.

Aktive Sensoren erzeugen aufgrund des Messprinzips direkt ein elektrisches Signal.

Aktive Sensoren können häufig in Umkehrung des Messeffektes auch als Aktoren genutzt werden. Sie liefern dafür häufig lediglich bei einer Änderung der Messgröße ein Signal (Ausnahme u. a. Thermoelem.).

Teilweise wird die Perspektive auch umgekehrt - Sensorelemente, die keine Energiezufuhr benötigen, werden dann als "passiv" bezeichnet.

Messverfahren

Neben der Sensorerfassung kann auch das Messverfahren mit dem Sensor unterteilt werden:

Aktives Messverfahren

Es wird ein Aktuator benötigt der einen Stimulus erzeugt der dann vom Sensor gemessen wird (Beispiel Ultraschallmesstechnik)

Passives Messverfahren

Der Sensor erfasst direkt einen in der Umgebung vorhandenen Stimulus (Beispiel: Temperatur, Dehnung)

Beipiele:

| Aktiver Sensor | Passiver Sensor
Aktives Messverfahren | Piezoelektrisch, Anregung von Wellen | Kapazitiv, Anregung von Wellen
Passives Messverfahren | Piezoelektrisch, Körperschall | Kapazitiv, Körperschall

Abbildung 6-1. Aktive, passive, intrinsisische, und extrinsische Sensoren in einem Messsystem [D]

Sensormodell

Eigenschaften von Sensoren

Ein Eingangssignal muss eventuell mehrmals konvertiert werden, bis der Sensor ein elektrisches Ausgangssignal ausgibt.

Im folgenden Abschnitt wird der Sensor als ’Black Box’ betrachtet.

Es interessiert uns im Folgenden nur die Beziehung zwischen Eingangs- und Ausgangssignal.

Transferfunktion

Jeder Sensor besitzt eine ideale bzw. theoretische Beziehung zwischen Eingangs- und Ausgangssignal.

Das Ausgangssignal S repräsentiert dabei den wahren Wert des Eingangssignals s.

Die ideale Beziehung zwischen Eingangs- und Ausgangssignal eines Sensors wird beschrieben durch die Transferfunktion S = f(s).

Lineare Transferfunktion: S = a+bs

Logarithmische Transferfunktion: S = a + k ln s

Exponentiale Transferfunktion: S = a · eks

beliebige Polynome höherer Ordnung: S = a₀ + a₁ s¹ + a₂ s² ..

mit

k ist eine Konstante

a ist das Ausgangssignal bei einem Eingangssignal von 0

b ist die Steigung

b wird in diesem Zusammenhang oft als Sensitivität bezeichnet.

Sensitivität

Für nicht-lineare Transferfunktionen ist die Sensitivität für jeden Eingangswert si wie folgt definiert:

image-placeholder
(6-1)

Approximation einer Transferfunktion

Einige nicht-lineare Transferfunktionen sind linear in einem eingeschränkten Bereich.

Nicht-lineare Transferfunktionen können durch mehrere lineare Funktionen approximiert werden.

Die Differenz zwischen wahrem und linear approximiertem Ausgangssignal sollte unter einem zu spezifizierenden Limit liegen.

Mehrdimensionale Transferfunktionen

Die Transferfunktion kann von mehr als einem Stimulus abhängen.

Beispiel: Infrarot-Wärmestrahlungssensor (Stefan-Boltzmann Gesetz)

image-placeholder
(6-2)

mit

G: Konstante

Tb: absolute Temperatur des gemessenen Objektes

Ts: absolute Temperatur der Sensoroberfläche

U: Ausgangsspannung

Sensitivität in Bezug auf die Temperatur des gemessenen Objektes:

image-placeholder
(6-3)

Beispiel: Dehnungsmessstreifen (Metallstreifen)

image-placeholder
(6-4)

mit:

ε:Dehnung

T

Temperatur

k,m

Material- und Strukturkonstanten

Messbereichsumfang

Der dynamische Bereich eines Stimulus, der von einem Sensor erfasst wird, wird Messbereichsumfang (engl. Span oder Full Scale Input) genannt.

beziffert den kleinsten und höchsten für einen Sensor zulässigen Stimuluswert

größere Stimuli können den Sensor beschädigen

kleiner oder größere Stimuli können zu einer Sättigung des Ausgangssignals führen

Ausgabebereich

Der Ausgabebereich (endl. Full Scale Output) eines Sensors ist das Intervall zwischen dem Ausgangssignal bei kleinstem und größtem angelegten Stimulus.

Reale Transferfunktion

Im Vergleich zur idealen Transferfunktion sind reale Sensoren immer ungenau.

Die Transferfunktion eines realen Sensors heißt daher: reale Transferfunktion.

[D]

Abweichung der realen Transferfunktion von der idealisierten Modellfunktion innerhalb von Ober- und Untergrenzen

Kalibration

Kalibration ist eine Korrektur der Transferfunktion (Anpassung der Parametrisierung)

Kalibration soll die reale Transferfunktion der idealen Transferfunktion anpassen

Abbildung 6-2. Vergleich der realen und kalibrierten Transferfunktion eines Sensors

Hysterese

Hysterese beschreibt ein zeit- und historienabhängiges Verhalten der Transferfunktion.

D.h. der Stimulus wird erst in eine Richtung verändert (vergrößert) und dann wieder in die andere Richtung auf den ursprünglichen Wert geändert (verkleinert) . Dabei ist das Ausgangssignal des Sensors aber nicht mehr gleich.

[D]

Hysteresverhalten der Sensortransferfunktion

Sättigung

Fast jeder Sensor hat Arbeitsbereichsgrenzen.

Viele Sensoren haben eine lineare Transferfunktion, . . .

aber: Ab einem bestimmten Stimuluswert wird nicht mehr die gewünschten Ausgabe erzeugt.

Es tritt eine Sättigung der realen Transferfunktion ein.

Sättigung der Transferfunktion

Antwortverhalten

→ Zeitliches Verhalten

Es kann eine verzögerte Stimulusantwort auftreten

Es kann zeitliches Über- und Unterschwingen auftreten

Es kann Oszillation auftreten

Umwelteinflüsse

minimal und maximal zulässige Umgebungstemperatur

minimal und maximal zulässige Luftfeuchtigkeit

Kurz- und Langzeitstabilität (Drift) (Hilfe bei Langzeitdrift: Pre-aging erhöht Stabilität)

statische und dynamische Änderungen von elektromagnetischen Feldern, Gravitationskräften, Vibrationen, Strahlung , etc.

Selbsterwärmung z.B. durch Stromfluss

Mechanischer Stress im Material durch Integration!

Energieversorgung

Sensoren in mobilen Geräten

Mobile Geräte stellen häufig low-cost Sensorik zur Verfügung mit der sich Sensornetzwerke (Umgebung und Umwelt) aufbauen lassen

Mögliche Messaufgaben:

Longitudinale Flächendeckende Seismische Erfassung (bei Erdbeben)

Longitudinale Flächendeckende Aufnahme von Umweltdaten wie Lufttemperatur (Smart City)

Mobile Longitudinale Flächendeckende Lärmerfassung (Lärmkartierung)

Bewegungsprofile (Verkehrsflüsse und Verkehrsmanagement)

Raum- und zeitaufgelöste Strukturüberwachung von Flugzeugen über Smartphones der Passagiere

Smartphone

Sensor | Art | Technologie | Messgröße | Messbereich | Einheit | Genauigkeit
Temperatur 1 | Intrinsisch | Halbleiter PN | Gerätetemperatur (CPU/Gehäuse) | 0-150°C | °C | ±3°C
Temperatur 2 | Extrinsisch | Halbleiter PN | Lufttemperatur | -20-100°C | °C | ±1°C
Beschleunigung | Extrinsisch | MEMS | Dreiachsige Beschleunigung | 0-40m/s² | m/s² | 1m/s²
Lage | Extrinisch | MEMS | Dreiachsige Lage (Winkel) | -180..180 ° | ° / Grad | ± 10 °
Position | Extrinisch | Radio, Synch. Uhren und TOF | Geometrische Raumposition, Winkel | -180..180°, -90..90° | ° | 1m
Licht 1 | Extrinsisch | Halbleiter PN | Lichtintensität Umgebung | 1-1000 Lux | Lux | 10 (rand.) 100 (syst.) Lux
Mikrofon | Extrinisch | Kondensator/Piezo | Umgebungsschallamplitude (zeitaufgelöst) | 0-60 dB | arb. units | 1dB random, 10dB system.
Gerätekennung | In- und Extrinisch | IP | MAC/IMEI, Öffentliche IP | - | Nummer | ± 500km Geoposition (IP), ID weltweit eindeutig

Experimente

Schall

https://mascil.ph-freiburg.de/aufgabensammlung/experimente-mit-dem-smartphone/gruppe-1-experimente-mit-dem-schallsensor-mikrofon

Beschleunigung

https://mascil.ph-freiburg.de/aufgabensammlung/experimente-mit-dem-smartphone/gruppe-2-experimente-mit-dem-beschleunigungssensor

Zusammenfassung

Referenzen

Bücher

]ames E. Smith and R. Nair, Virtual Machines - Versatile Platforms for Systems and Processes. Elsevier Inc., 2005.

R. Zurawski, Ed., Embedded systems handbook : Embedded systems design and verification. CRC Press, 2009.

Eduard Glatz, Betriebssysteme - Grundlagen, Konzepte, Systemprogrammierung. dpunkt, 2015.

Vorlesung: Angewandte Sensorik, J. Zhang, Universität Hamburg, 2003

D. Balageas, C. Fritzen, and A. Güemes, Structural health monitoring. ISTE, 2006.

L. J. Gauckler, K. Conder Skript zur Vorlesung Ceramics II, ETH Zürich

Chapmann, Distributed Sesnor networks (DSN), 2005

Michael J. Flynn Wayne Luk, Computer System Design: System‐on‐Chip, Wiley, 2011