Kapitel 5

• sichere physische (separater Server)

• logische Trennung (separat virtuelle Maschinen auf einem physischen Server)

  
  

Darüber hinaus sollte sichergestellt sein, dass Entwicklungs- und Testumgebung mit gleicher Hard- und Softwarekonfiguration betrieben werden.

Bei der Entwicklung eingebetteter Systeme spielt die zugrundeliegende Hardware jedoch eine wichtige Rolle, da diese oftmals speziell für einen definierten Anwendungszweck entwickelt wird.

Der Zugriff auf diese Hardware erfolgt entweder über maschinennahe Programmierung mit Assembler oder mittels Programmiersprachen wie C\/C++ oder Java, die einen vereinfachten Hardwarezugriff erlauben.

OSGi (Open Services Gateway initiative)

Die durch die OSGi Alliance (u. a. Oracle, Sun Microsystems, IBM) entwickelte herstellerunabhängige Softwareplattform ermöglicht die Steuerung und Vernetzung diverser Gerätearten und kommt aktuell besonders häufig bei der Vernetzung von KFZs zum Einsatz, z. B. bei der Anbindung von Infotainment-Systemen.

Der modulare und dynamische Ansatz von OSGi ist insofern besonders vorteilhaft, da in der Praxis Softwarekomponenten aus der Ferne installiert, gestartet, gestoppt und deinstalliert werden können, ohne ein Gerät neu zu starten, was Wartungs- und Aktualisierungsmaßnahmen deutlich vereinfacht.

Ein weiterer, spezieller Aspekt bei der Entwicklung verteilter eingebetteter Systeme ist die Implementierung der Echtzeitfähigkeit unter Berücksichtigung möglicher Einschränkungen durch die Kommunikation zwischen den verteilten Komponenten über Netzwerke unterschiedlichster Art.

Da je nach zugrundeliegendem Übertragungsmedium und Übertragungsprotokoll diverse Fehlerzustände zu Problemen bei der Datenübertragung führen können (z. B. Paketverlust), muss bei der Entwicklung verteilter Systeme sichergestellt werden, dass diese die Echtzeitfähigkeit und auch die Zuverlässigkeit des Gesamtsystems nicht negativ beeinflussen.

• Ausfalltoleranz

• Fehlertoleranz

• Transparenz

• Skalierbarkeit

• Offenheit

Zwischen System- und Softwarearchitekturen

• Client-Server-Architektur (Cache/Proxy)

• Peer-to-Peer-Architektur

In einer Client-Server-Architektur tauschen Client und Server Anforderung (Request) und Antwort (Response) miteinander aus.

Jeder Rechner ist entweder Server oder Client bezogen auf einen bestimmten Dienst. Ein Server kann also einen anderen Dienst auf einem entfernten Rechner wiederum als Client in Anspruch nehmen.

Sonderfälle in einer Client-Server-Architektur stellen die sogenannten Cache- oder Proxy-Server dar.

Während ein Cache-Server Daten zwischenspeichert und dadurch unnötige Anfragen über das Netzwerk vermeiden hilft, agiert ein Proxy-Server quasi als Stellvertreter zwischen Client und Server. Durch diese Stellvertreterfunktion kann – je nach Übertragungsprotokoll – eine tiefergehende Filterung und Kontrolle des Datenstroms oder auch eine zusätzliche Authentifizierung der Benutzer erfolgen (z. B. durch die Eingabe des Benutzernamens oder Passwortes vor Freischaltung eines Internetzugriffs).

Im Gegensatz zur Client-Server-Architektur übernimmt in einer Peer-to-Peer-Architektur jeder Rechner sowohl Client- als auch Server-Funktionalitäten. Man spricht hierbei oftmals auch von einem sogenannten Servent, also einer Mischung aus Client und Server, wobei sich diese Rolle dynamisch je Kommunikationsvorgang verändern kann.

Peer-to-Peer-Netzwerke stellen somit ein dezentrales, verteiltes System aus autonomen Rechnern ohne zentrale Server dar, in dem keine zentrale Koordinierung und keine zentrale Datenbasis existiert. Aus diesem Grunde sind Peer-to-Peer-Architekturen nur mit hohem Aufwand administrierbar.

• Zwei-Schichten-Architektur

• Drei-Schichten-Architektur

• Middleware

Eine Zwei-Schichten-Architektur repräsentiert eine klassische Client-Server-Architektur und erfordert auf der Client-Seite einen sogenannten Fat Client (Betriebssystem plus umfangreiche lokal installierte Anwendungssoftware), um z. B. von diesem mittels eines Datenbank-Clients über ein Datenbankzugriffsprotokoll auf einen entfernten Datenbankserver zugreifen zu können.

Zwei-Schichten-Architekturen sind zwar einfach zu realisieren, erfordern jedoch einen hohen Installations- und Administrationsaufwand auf der Client-Seite.

Eine Drei-Schichten-Architektur ist eine Softwarearchitektur, die drei unterschiedliche Schichten implementiert.

Die GUI-Schicht (Graphical User Interface-Schicht) implementiert eine graphische Benutzeroberfläche, über die mittels diverser Schnittstellen der Fachkonzeptschicht (z. B. Applikationsserver) auf die in der Datenhaltungsschicht liegenden Datenbestände (z. B. in einer Datenbank) zugegriffen werden kann. Je nach Ausprägung des Architekturmodells können diese drei Schichten strikt voneinander separiert sein (jede Schicht darf nur auf die Funktionalitäten der direkt darunterliegenden Schicht zugreifen) oder es besteht die Möglichkeit, dass die GUI-Schicht auch direkt auf die Datenhaltungsschicht zugreifen kann.

Die logische Trennung der drei Schichten hat den Vorteil, dass diese auch unabhängig voneinander verändert werden können, was Wartbarkeit und Portabilität stark erhöht und insbesondere ermöglicht, Komponenten der Fachkonzeptschicht leicht wiederzuverwenden.

Aus diesen Gründen ist die Drei-Schichten-Architektur ideal für den Einsatz in verteilten Systemen.

Middleware ist eine Bezeichnung für anwendungsneutrale Software, die als zusätzliche Schicht zwischen Betriebssystem und Anwendung vermittelt und die Kommunikation zwischen Prozessen unterstützt.

Durch den Einsatz von Middleware können die Vorteile von verteilten Betriebssystemen (Transparenz, einfache Nutzung) und Netzwerkbetriebssystemen (Skalierbarkeit, Offenheit) miteinander kombiniert werden.

Durch den Einsatz von Sensoren und Aktoren im IoT kann die Datenqualität erhöht werden, da menschliche Fehler und subjektive Bewertungen bei dieser Datenerfassung ausgeschlossen werden können und die Datenübertragung darüber hinaus auch in Echtzeit erfolgt. Voraussetzung ist natürlich, dass die Sensoren selbst eine entsprechende Güte aufweisen. Weil eine manuelle Erfassung hierdurch entfällt, oder zumindest stark reduziert wird, können auch Personalkosten gesenkt werden.

Intelligente Gegenstände kommunizieren über Sensoren und Aktoren mit ihrer Umwelt und nutzen Übertragungstechnologien wie z. B. ZigBee oder Bluetooth, um idealerweise drahtlos mit einem Gateway zu kommunizieren, dass sie an ein Zentralsystem anbindet. Die Kommunikation des Gateways mit dem Zentralsystem erfolgt über Protokolle wie HTTP oder MQTT (Message Queue Telemetry Transport) über eine sogenannte Messaging Infrastruktur. Daten werden in einem Datenspeicher abgelegt, wo sie über APIs (Application Programming Interface) an Intelligence-Anwendungen angebunden werden, mit deren Hilfe diese Daten analysiert und visualisiert werden können.

• Mikroprozessor

• Arbeitsspeicher

• Schnittstellen für Peripheriegeräte und anderen Komponenten

Es handelt sich also um kleine Rechner, die alle zum Betrieb erforderlichen Komponenten auf einer einzigen Platine vereinen.

Einsatzfelder für SoC-Systeme finden sich in der Mobilfunk-, der Medizin- oder auch der Automobiltechnologie. SoC-Systeme bieten sich aber auch insbesondere aufgrund ihrer kompakten Bauweise und integrierter WLAN-Funktionalität für den Einsatz in intelligenten Gegenständen im Internet of Things an. Sowohl Mikrocontroller als auch SoC-Systeme werden überwiegend mit dem Open-Source-Betriebssystem Linux betrieben, welches keine Lizenzkosten verursacht und zum anderen in der Lage ist, die begrenzten Hardware-Ressourcen der Minirechner optimal auszunutzen. Das Betriebssystem von Mikrocontrollern oder SoC-Systemen wird auch als „Firmware“ bezeichnet.