Verteilte Rechenkapazität durch »Remote Procedure Calls«
RPC-Middleware für Embedded Systeme
Fortsetzung des Artikels von Teil 1
RPC auf Embedded Systemen nutzen
Soll diese Form der Kommunikation über RPC auf Embedded Systemen genutzt werden, gibt es einige Punkte zu beachten. Die verschiedenen, entfernten Objekte werden erst zur Laufzeit angelegt, bearbeitet und gespeichert. Damit dies verlässlich funktioniert, ist eine dynamische Speicherverwaltung notwendig. Viele Embedded Systeme haben diese Möglichkeit aber nicht und besitzen nur einen begrenzten Arbeitsspeicher. Damit der Entwickler nicht den gesamten Prozess der Kommunikationsabwicklung neu entwickeln muss, kann eine allgemeine und unabhängige Vermittlungsschicht − die Middleware − zum Einsatz kommen. Diese Middleware wickelt den kompletten Vermittlungsaufwand ab und bewältigt viele Aufgaben, die der Entwickler zusätzlich zur Applikation behandeln müsste. Deshalb muss die Middleware gut geplant sein und wenige Ressourcen fordern, um den Entwickler und das System wenig zu belasten. Sie sollte außerdem zu möglichst vielen Plattformen und Protokollen kompatibel, in der Handhabung aber nicht unnötig kompliziert sein. Dazu muss die Middleware modulartig aufgebaut und mit Protokollen umgesetzt werden, die mit möglichst wenig Aufwand übertragbar sind. Nur so ist das Softwarepaket auf andere Systeme und Schnittstellen portierbar.
Mixed Mode hat eine RPC-Middleware entwickelt, die diese Vorgaben berücksichtigt und im Vergleich mit bekannten RPC-Bibliotheken für leistungsstarke Rechner mit nur leichten funktionalen Einschränkungen auf Embedded Systemen einsetzbar ist. So ist der Kommunikations- und Speicheraufwand bei dieser RPC-Middleware gegenüber bereits existierenden Bibliotheken wie zum Beispiel »Protocol Buffers« von Google geringer. Setzt der Entwickler diese Middleware ein, kann er sich auf seine Applikation konzentrieren und muss sich nicht um die Sicherstellung der Kommunikation mit anderen Systemen kümmern − denn Einrichtung und Betrieb der Kommunikation übernimmt die Middleware.
Embedded-RPC-Middleware
Jobangebote+ passend zum Thema
Die Experten bei Mixed Mode implementierten diese Lösung über zwei Schichten (Bild 2). Jede einzelne Schicht ist in sich abgeschlossen und hat definierte Schnittstellen nach oben und unten. Die Abstraktionsschicht der Kommunikation ist nötig, weil ein Embedded System über kein allgemeines, höheres Kommunikationsprotokoll verfügt, das gleichzeitig sehr schlank wäre, also den begrenzten Speicher und die Rechenzeit nicht belastet. Durch das Schichtenmodell werden die physikalische Kommunikation und die Applikation unabhängig von der entwickelten Middleware. Welche Übertragungsart genutzt wird, ist somit irrelevant für die Middleware, da die einfachen Treiber die Daten über die definierten Schnittstellen an die Kommunikationsschicht weiterleiten. Wenn die im System befindlichen Controller über einen TCP/IP-Stack verfügen, können sie natürlich TCP/IP statt der Kommunikationsschicht (Communication) nutzen.
Die Kommunikationsschicht nutzt ein von Mixed Mode entwickeltes Protokoll, das mit wenig Aufwand zu implementieren ist. Für lange Nachrichten unterstützt es eine Segmentierung der Nutzinformation, damit sich die verschiedenen Datenübertragungsprotokolle (zum Beispiel CAN mit Nutzdaten der Länge 8 Byte) nutzen lassen. Daher ist es möglich, das Protokoll mit wenig Aufwand auf anderen Systemen als den bisher getesteten und in anderen Sprachen zu implementieren und die Middleware dann auch dort zu nutzen. Im Gegensatz zum CAN-Transportprotokoll der ISO 15765-2:2011 ist das Mixed-Mode-Protokoll nicht auf eine bestimmte Segmentierungsgröße beschränkt und erlaubt eine Kommunikation zu mehreren Teilnehmern.
- RPC-Middleware für Embedded Systeme
- RPC auf Embedded Systemen nutzen
- Zentrale Funktionen
- Eingeschränkte Referenzen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Industrie 4.0
Legosteine mit Webtechniken sortieren
Mikroprozessor-Entwicklungstools
Neues Analysewerkzeug für Hardware/Software-Debugging
Keynote-Speaker Tyson Tuttle
embedded world Conference 2015
Embedded-Betriebssysteme
VDC sieht Wind River als Marktführer
i.MX6-Module
Yocto-Unterstützung für SMARC-Module
Echtzeit-Betriebssystem
VxWorks 7: Wind River hat aufgeräumt
Internet der Dinge
Virtualisierung, Echtzeit, Sicherheit – kein Widerspruch
