Interoperables IoT
Koppeln von Echtzeitelementen
Fortsetzung des Artikels von Teil 1
Unabhängige Prozesse
Stewart argumentiert in seinem Beitrag [10], dass eingebettete Echtzeitsysteme unabhängige Prozesse einschließen, die untereinander mit relativ hoher Häufigkeit relativ kleine Datenmengen austauschen müssen. Diese Häufigkeiten sind mit Sicherheit höher als vom Internet realisierbar. Auch wenn die heutigen Internet-Bitraten Hunderte von Megabit pro Sekunde betragen, machen die Nutzlastgröße und die Notwendigkeit von Handshakes die internetbasierte Kommunikation in den meisten modernen, eingebetteten Echtzeitsystemen unmöglich. Die Kommunikationsdichte für Echtzeit-IoT-Geräte ist beeinträchtigt. Möglicherweise können Kommunikationsnutzlasten aus mehreren Prozessen gebündelt werden, um die Nutzlasteffizienz zu erhöhen und die Anzahl der Übertragungsinstanzen zu minimieren.
Aufgrund der Verarbeitungslast der TCP/IP-Kommunikation muss eine Anwendung, die sonst nur einen 8-Bit-Host-Prozessor benötigt, in der Regel eine 32-Bit-Lösung sein. Glücklicherweise kostet ein 32-bit-Controller weniger als 0,50 Dollar. Daher gehe ich davon aus, dass IoT-Geräte 32-Bit-Kerne enthalten.
Bindung zwischen unabhängigen Prozessen
Diese unabhängigen Prozesse müssen miteinander verbunden werden, um einen Ausgangswert aus verschiedenen Eingängen zu ermitteln, und mehrere Ausgangswerte könnten erforderlich sein, um noch weitere Ausgänge zu verarbeiten. Stewart argumentiert, dass diese Bindungen vorzugsweise so aussehen, dass sie dynamisch rekonfigurierbar sind und innerhalb bestimmter Fristen miteinander gekoppelt werden können. Beispielsweise könnte ein Gerät online gehen oder erkannt werden, das in der Lage ist, die Kommunikationslast eines vorgeschalteten Gerätes zu reduzieren und dadurch eine nachgeschaltete Senke dynamisch zu trennen und mit einer neuen vorgeschalteten Quelle erneut zu verbinden. Es wäre vorteilhaft, dem in unserem Standard Rechnung zu tragen. Geräte sollten die Möglichkeit bieten, Daten zu analysieren, zu puffern und zu verteilen/umzuverteilen. Das bedeutet, dass wir neben der Definition von verteilten Gerätetypen wahrscheinlich auch verteilte Funktionen und Rollen spezifizieren müssen. Diese Funktionen und Rollen können als »virtuelle« oder »abstrakte« IoT-Geräte betrachtet werden.
Erste USB-basierte Entwicklungstools hatten ein Problem, wenn der Host beschäftigt war. Sie hatten keine Möglichkeit, den Host zu zwingen, sie zur Kenntnis zu nehmen. Das hatte zur Folge, dass sie sporadische Aussetzer hatten und »buggy« waren. Erst als diese Tools intelligenter wurden (z. B. mehr Arbeitsspeicher hatten, für eine zeitnahe Antwort weniger abhängig von einer Remote-CPU waren), wurde dieses Problem minimiert. IoT-Geräte müssen intelligent sein.
Mehrere CPUs
Häufig wird zum Erreichen der Leistungsziele bei Echtzeit-Embedded-Systemen mindestens eine CPU genutzt. Das kann in Form von mehreren Mikroprozessoren, FPGAs oder beidem realisiert werden. Es muss eine Multiplizitätszuordnung von CPUs zu IoT-Geräten geben.
Die Koordination zwischen mehreren CPUs sollte es jeder CPU ermöglichen, unabhängig von anderen CPUs zu arbeiten. Wie bei der Verarbeitung von Threads in den CPUs moderner PCs könnte jede verfügbare CPU möglicherweise dazu beitragen, die Kommunikationsbandbreite zu reduzieren, indem sie Informationen aus Rohdaten komprimiert bzw. extrahiert. Oder sie könnte ein gewisses Maß an Fehlertoleranz bieten. Unabhängig von der Anwendung sollte das System tolerant gegenüber verschiedenen Betriebsfrequenzen und unterschiedlichen Kommunikationsraten sein – wie Stewart es nennt –, damit mehrere CPUs (Knoten) unterstützt werden.
- Koppeln von Echtzeitelementen
- Unabhängige Prozesse
- Verschiedene Frameworks
- Weitere Forschungsprojekte und Protokolle
Lesen Sie mehr zum Thema
