-
Stand der Technik
-
Die Erfindung geht aus von einem Sensorsystem mit einem Sensordatenpuffer, wobei der Sensordatenpuffer derart konfiguriert ist, dass Sensordaten in Frames organisiert sind.
-
Sensorsubsysteme in Mobile Compute Devices (MCD) müssen energieeffizient implementiert werden, um beispielsweise lange Akkulaufzeiten zu gewährleisten. Häufig sind im MCD die Sensoren mit dem Applikationsprozessor über eine digitale Schnittstelle verbunden. Das Aufwecken des Applikationsprozessors zum Auslesen jedes Ergebnis einer Messung eines Sensors ist nicht energieeffizient genug für dauerhaft laufende Anwendungen wie z.B. Schrittzähler für Fitnessanwendungen. Heute implementieren Sensoren daher Sensordatenpuffer, beispielsweise in Form eines FIFO Speichers, die Messdaten zwischenspeichern. Der Applikationsprozessor liest in einem Aufweckzyklus die gesammelten Messdaten aus. Misst ein Sensor mehr als eine Messgröße, werden diese vorzugsweise in einem gemeinsamen Sensordatenpuffer gespeichert, damit Informationen wie Reihenfolge und ggf. Zeitgleichheit von Daten verschiedener Sensoren erhalten bleiben. Beispielsweise können in einem Sensor Beschleunigung und Drehrate gemessen werden. 1 zeigt ein derartiges Sensorsystem in einem MCD.
-
In einem Sensor der mehrere Messgrößen messen kann, wird häufig nur eine Teilmenge der verfügbaren Messgrößen benötigt. Deshalb wird häufig nur eine Teilmenge der Messgrößen ermittelt und im Sensordatenpuffer abgelegt. Es ist möglich, dass sich die Teilmenge der ermittelten und abzuspeichernden Messgrößen deterministisch ändert, wie beispielsweise bei Messgrößen mit verschiedener Samplingfrequenz. Es ist möglich, dass sich die Teilmenge der ermittelten und abzuspeichernden Messgrößen nicht deterministisch ändert, wie beispielsweise in dem Fall, dass das MCD eine Sensorgröße für einen gewissen Zeitraum gar nicht benötigt.
-
Um die variierende Teilmenge der Messgröße abzudecken, halten einige der heutigen Lösungen Speicherplatz für alle möglichen Messgrößen im Sensordatenpuffer vor. Ein Beispiel dafür zeigt die 2A als Typ A. Es ist eine Sensordatenpuffer-Struktur dargestellt, die jeweils 6 Byte für Gyroskop- und Accelerometer-Daten reserviert. Die Messdaten sind mit einer fortlaufenden Nummer gekennzeichnet, z.B. bedeutet G5(6) das 5. Sample vom Gyroskop mit einer Länge von 6 Byte. Die mit U gekennzeichneten Speicherstellen sind nicht benutzt. Das Beispiel stellt einen Sensordatenpuffer-Inhalt mit 8 Samples des Gyroskopes und 2 Samples des Accelerometer dar. Das Gyroskop hat in dem Beispiel die vierfache Datenrate des Accelerometers.
-
Andere Lösungen im Stand der Technik optimieren die Speicherplatznutzung, indem Sie eine Konvention festlegen, wie Daten im Speicher abgelegt werden. Dasselbe Beispiel ist in der 2B für diesen Typ B dargestellt. Hier muss das MCD die Sequenz in der die Daten abgelegt werden implizit kennen.
-
Abweichungen davon sind nicht möglich.
-
Der oben beschriebene Typ A Sensordatenpuffer hat den Mangel, dass häufig der Speicherplatz nur teilweise benutzt wird. Das führt dazu, dass der Applikationsprozessor des MCD häufiger aufgeweckt werden muss, als es erforderlich wäre, wenn der gesamte verfügbare Speicherplatz verwendet wird. Mit dem Typ B Sensordatenpuffer lassen sich Szenarien mit deterministischen Änderungen der Teilmengen der Messgrößen effizient implementieren. Bei jeder nichtdeterministischen Änderung muss aber der Sensordatenpuffer gelöscht werden und Daten gehen verloren. Zudem besteht das Risiko, dass die Synchronisation zwischen Sensordatenpuffer und MCD verloren geht, was leicht zu Datenintegritäts-Fehlern führen kann.
-
In beiden Typen A und B muss der Sensordatenpuffer gelöscht werden, wenn Sensorparameter geändert werden.
-
In beiden Typen A und B ist die Synchronisation der Daten im Sensordatenpuffer mit externen Daten aufwändig. Dies kann aber z.B. erforderlich sein, wenn ein Gyroskop mit einer Kamera zur elektronischen Bildstabilisierung synchronisiert werden muss.
-
Aufgabe der Erfindung
-
Aufgabe der Erfindung ist es, eine Sensordatenpuffer-Architektur zu schaffen, die möglichst alle Vorteile der existierenden Lösungen vereint ohne deren Nachteile aufzuweisen. Zudem soll eine effiziente Synchronisation der Sensordaten mit externen Events unterstützt werden.
-
Vorteile der Erfindung
-
Die Erfindung geht aus von einem Sensorsystem mit einem Sensordatenpuffer, wobei der Sensordatenpuffer derart konfiguriert ist, dass Sensordaten in Frames organisiert sind. Der Kern der Erfindung besteht darin, dass der Sensordatenpuffer derart konfiguriert ist, dass ein Datenframe einen Header und einen Sensordatenbereich aufweist. Vorteilhaft kann ein derartiges Sensorsystem im laufenden Betrieb neu konfiguriert werden, ohne die Daten im Puffer zu löschen, oder das System neu starten zu müssen.
-
Eine vorteilhafte Ausgestaltung des erfindungsgemäßen Sensorsystems sieht vor, dass der Header angibt, welche Messgrößen im Sensordatenbereich enthalten sind. Vorteilhaft ist hierbei, dass der Speicher kompakt genutzt wird, da nur die Daten abgelegt werden, die für den Frame vorhanden sind und sich die Datenzusammensetzung von Frame zu Frame ändern kann.
-
Eine vorteilhafte Ausgestaltung des erfindungsgemäßen Sensorsystems sieht vor, dass der Frame Metadaten enthält.
-
Eine besonders vorteilhafte Ausgestaltung des erfindungsgemäßen Sensorsystems sieht vor, dass der Frame als Metadaten einen Zeitstempel für die Sensordaten enthält. Vorteilhaft können so die Sensordaten auch bei Nicht-Echtzeit Datenübertragung bestimmten Zeitpunkten zugeordnet werden, wodurch insbesondere Sensordatenfusion verbessert oder überhaupt erst ermöglicht wird. Eine besonders vorteilhafte Ausgestaltung des erfindungsgemäßen Sensorsystems sieht vor, dass der Frame als Metadaten die Zahl von verlorenen Paketen enthält. Vorteilhaft können mit dieser Information die verlorenen Pakete identifiziert und ungültig erklärt oder auch erneut ausgelesen werden.
-
Eine besonders vorteilhafte Ausgestaltung des erfindungsgemäßen Sensorsystems sieht vor, dass der Frame als Metadaten Konfigurationsdaten oder auch Konfigurationsänderungen des Sensors enthält. Vorteilhaft können hierdurch die Konfiguration des Sensorsystems und deren Änderungen im laufenden Betrieb kommuniziert werden.
-
Die erfindungsgemäße rekonfigurierbare Sensordatenpuffer-Struktur enthält nicht nur Daten, sondern erfindungsgemäß zusätzlich eine Beschreibung der jeweiligen Datenstruktur. Ein Frame besteht aus einem Informationsblock der Beschreibung der Daten, im Folgenden auch Header genannt, und den Daten. Zudem können Header spezielle Kontrollframes auszeichnen, die Informationen zu geänderten Sensorparametern enthalten. Die Header enthalten Informationen, welche Daten im Frame enthalten sind, damit wird vermieden, dass unbenutzte Daten im Buffer vorgehalten werden müssen wie dies in Typ A der Fall ist. Wird eine nichtdeterministische Änderung vorgenommen, so ist dies auch im Header ersichtlich und der Buffer muss nicht gelöscht werden wie in Typ B.
-
Damit wird sowohl der Speicherplatz effizient nahezu so effizient genutzt wie Typ A als auch der Sensordatenpuffer muss nicht gelöscht werden, wenn eine nichtdeterministische Änderung der Teilmenge der Messgröße passiert.
-
Zudem ist eine effiziente Synchronisation mit externen Events möglich, indem Marker in den Headern platziert werden. Die Events werden z.B. über externe Pins zur Verfügung gestellt. Ein klassischer Anwendungsfall ist beispielsweise eine Kameraaufnahme mit einem MCD, während der alle Frames mit dem Event „Film“ synchronisieren.
-
Zeichnung
-
1 zeigt ein Sensorsystem in einem MCD
-
2A und B zeigt zwei Typen von Konfigurationen von Sensordatenpuffern im Stand der Technik.
-
3 zeigt den Aufbau eines erfindungsgemäßen Sensordatenpuffers mit Frames.
-
Ausführungsbeispiel
-
Der Sensordatenpuffer speichert die Daten in Frames ab. Ein Frame beinhaltet einen Header und Messdaten oder andere Informationen. Um welche Art von Informationen es sich handelt ist im Header definiert. Ein Frame kann Messungen von mehreren Sensorgrößen enthalten, die Messdaten wurden alle zum gleichen Zeitpunkt aufgenommen.
-
3 zeigt den Aufbau eines erfindungsgemäßen Sensordatenpuffers mit Frames. Neben den Daten Ax(6) und Gy(6) sind Header Hi(1) enthalten. i ist ein fortlaufender Index, 1 ist die Länge von einem Byte (beispielhaft).
-
In dem dargestellten Beispiel beginnt der erste Frame mit einem ein Byte langen Header H1(1). Dieser enthält unter anderem die Information, dass 6 Byte Drehratensensor-Daten G1(6) und 6 Byte Beschleunigungssensor-Daten A1(6) im Datenteil des Frames enthalten sind. Der zweite Frame beginnt mit einem ein Byte langen Header H2(1). Dieser enthält die Information, dass 6 Byte Drehratensensor-Daten G2(6) im Datenteil des Frames enthalten sind, etc.
-
Im Folgenden ist exemplarisch dargestellt, wie ein Header aufgebaut sein kann und wie er die Semantik der Daten definiert. Die nachfolgende Tabelle zeigt eine mögliche erfindungsgemäße Realisierung eines Headerformats:
-
Die Felder fh_mode, fh_parm und fh_ext beschreiben den Typ des Headers, Parameter für den Typ und Erweiterungen.
-
Invalid (fh_mode=0b00):
-
Die folgenden Frames sind ungültig. D.h. das Ende der gültigen Daten ist erreicht. Regulärer Frame (fh_mode=0b10):
-
Die Felder fh_parm zeigen an, welche Messgrößen in dem regulärem Frame enthalten sind. So heißt z.B. ‘1’(‘0’) Daten für Sensor X sind enthalten (nicht enthalten).
-
Das Feld fh_ext<1:0> kann zur Synchronisation mit externen Events verwendet werden.
-
Kontrollframe (fh_mode=0b01):
-
Kontrollframes enthalten keine Messdaten, sondern Metadaten die Events oder Änderungen der Sensorparameter beschreiben. Beispiele könnten sein, dass Frames im Datenstrom fehlen, Zeitstempel oder Änderungen der Sensor-Konfiguration, z.B. Filter oder Datenraten.
-
Die Synchronisation mit externen Events erfolgt über Marker im Header, beispielsweise kann der Wert eines Input Pins im fh_ext Feld abgelegt werden. Die Synchronisation mit dem MCD wird dadurch sichergestellt, dass Frames, die nur partiell aus dem rekonfigurierbaren Sensordatenpuffer ausgelesen werden beim nächsten Lesezugriff wieder vollständig wiederholt werden. Damit ist eine implizite Synchronisation gegeben.
