-
Stand der Technik
-
Die Erfindung geht aus von einem Verfahren nach dem Oberbegriff des Anspruchs 1.
-
Aus dem Stand der Technik sind intelligente Trägheitssensoren bekannt, in denen Entwickler Sensorfusion oder Aufgaben, wie Gestenerkennung direkt in der Sensorhardware implementieren können, wodurch eine Reduzierung der Verarbeitungslatenz und des Energieverbrauchs erzielt wird. Das Entwickeln von Software für intelligente Trägheitssensoren birgt einige Schwierigkeiten aufgrund der begrenzten Hardware-Fähigkeiten der Mikrocontroller (µC) und des Fehlens der Möglichkeiten reproduzierbare Tests direkt auf der Hardware auszuführen. Inertialsensoren werden üblicherweise für eine Vielzahl verschiedener Geräte für ein breites Anwendungsspektrum von Schritterkennung [1] über Gestenerkennung [2] bis hin zu autonom fahrenden oder unbemannten Luftfahrzeugen (UAVs) [3] verwendet. Um dies zu ermöglichen, sind die modernen Trägheitssensoren in der Lage, Filterung und Vorverarbeitung der erfassten Daten direkt auf dem Sensor auszuführen, bevor diese vom System verwendet und verarbeitet werden. Gerade für sicherheitskritische Systeme ist es entscheidend, dass das ganze Sensorsystem mit den Trägheitssensoren nach allen möglichen Aspekten, einschließlich ihrer physikalischen Eigenschaften bewertet werden [4]. Dies beinhaltet auch die Vorverarbeitung der Daten direkt auf dem Trägheitssensor und das Verhalten der Anwendungen, die diesen Daten verwenden. Für die Evaluation werden insbesondere zwei Methoden benutzt. Die erste Methode ist die Verwendung virtueller Prototypen, wobei die eigentliche Hardware durch ein Softwaremodell simuliert wird [5]. Diese Methode ermöglicht reproduzierbare Ergebnisse und kann programmiert werden, um alle möglichen Szenarien zu simulieren. Jedoch kann ein sehr detaillierter virtueller Prototyp zu rechenintensiv werden, um in Echtzeit ausgeführt zu werden, und wird daher deutlich länger für die Bewertung eines Systems benötigen. Ein weiterer Nachteil dieses Ansatzes ist, dass er nicht die reale verwendet Hardware widerspiegelt und es evtl. nicht möglich ist, alle Aspekte des realen Systems zu modellieren wie z. B. Hardwareeinschränkungen oder unberücksichtigte physikalische Effekte. Darüber hinaus ist zusätzlicher Aufwand erforderlich, um einen virtuellen Prototyp zu entwickeln, wenn das Hardwareprodukt bereits verfügbar ist. Die zweite Methode ist die Verwendung der realen Hardware auf einem Evaluierungsboard oder Prototyp. Dadurch können alle Effekte untersucht werden die nur in realer Hardware vorkommen. Der wesentliche Nachteil von einer Evaluation anhand eines Prototyps mit realer Hardware ist der Mangel an Möglichkeiten zur Erzeugung reproduzierbarer Eingaben. Für einige Szenarien ist es möglich, einen Roboter zu verwenden, der reproduzierbar genau die gleichen Bewegungen ausführen kann. Die Möglichkeiten für einen Roboter, um die reale Bewegung nachzuahmen sind aber begrenzt, besonders wenn dabei menschliche Interaktion eine Rolle spielt. In anderen Anwendungsfällen wie bei Luftfahrzeugen ist es fast unmöglich, genau dasselbe Manöver zweimal zu fliegen, um wiederholbare Daten zu generieren.
-
Es gibt zahlreiche Software-Suiten und Ansätze, um Inertialsensoren oder Inertialsensorsysteme auszuwerten und zu simulieren. Mit dem sogenannten Hardware-in-the-Loop-Ansatz lässt sich beispielsweise das physikalische Verhalten eines Sensors simulieren und auf diese Weise das Zusammenspiel mit einem realen Kontrollsystem testen [6]. Hierzu existieren insbesondere kommerziell verfügbare Sensor-Simulations-PCs, die es ermöglichen, in einer deterministischen Echtzeit-Simulation physikalische Modelle von Sensoren zu simulieren und die Algorithmen zur Verarbeitung der Sensordaten zu bewerten. Andere Toolboxen ermöglichen es, Daten der Inertialsensoren für die Entwicklung und Auswertung von Algorithmen zu simulieren. Beispiele sind die Sensor Fusion and Tracking Toolbox von MATLAB® oder das Open-Source-Projekt GNSS-INS-SIM. Die genannten Toolboxen bieten eine Software-Suite auf hohem Abstraktionsniveau mit Algorithmen und Werkzeugen für die Entwicklung, Simulation und Bewertung von Sensorfusionsalgorithmen für viele unterschiedliche Inertialsensoren. Die Algorithmen können entwickelt und ausgewertet werden, indem entweder aufgezeichnete oder vollständig synthetische Daten verwendet werden. Diese Ansätze sind vollständig softwarebasiert und basieren auf einem hohen Abstraktionsniveau. Es ist nicht möglich, den entwickelten Algorithmus direkt auf einer Sensorplattform auszuführen, um seine Leistungsfähigkeit, Energieverbrauch, Ressourcennutzung oder Echtzeitfähigkeit zu untersuchen. Der gebräuchlichste und modernste Ansatz zur Simulation von ein Trägheitssensorsystem ist die virtuelle Prototypensimulation, die die verwendete Hardware simuliert [5]. Ein wesentlicher Vorteil dieses Ansatzes besteht darin, dass er die eigentliche Hardware nicht zur Bewertung der entwickelten Fusionsalgorithmen benötigt. In der Arbeit [5] wird der Trägheitssensor per Software simuliert unter Berücksichtigung seiner physikalischen Eigenschaften, die aus dem Datenblatt extrahiert werden können. Der Nachteil dieses Ansatzes ist, dass das simulierte Modell die reale Hardware jedoch nur bis zu einem bestimmten Punkt annähern kann. Es ist nicht möglich, alle Eigenschaften des Systems zu untersuchen, insbesondere solche, die beispielsweise nicht im Datenblatt stehen. Eine weitere hochmoderne Methode zur Bewertung der Inertialsensoren und der Software, die die Sensoren verwendet, ist die Verwendung eines Prototyps oder einer Anwendungsplatine mit den realen Sensoren, wodurch eine Bewertung der tatsächlichen Hardware in Verbindung mit der Software ermöglicht wird. Hier ergibt sich jedoch, wie weiter oben beschrieben, die bedeutende Schwierigkeit, den auf den Sensor wirkenden Stimulus exakt zu wiederholen und auf diese Weise reproduzierbare Testbedingungen zu schaffen.
- [1] K. Wen, K. Yu, Y. Li, S. Zhang, and W. Zhang, „A new quaternion kalman filter based foot-mounted imu and uwb tightly-coupled method for indoor pedestrian navigation,“ IEEE Transactions on Vehicular Technology, vol. 69, no. 4, pp. 4340-4352, 2020.
- [2] P. Koch, M. Dreier, M. Maass, M. Böhme, H. Phan, and A. Mertins, „A recurrent neural network for hand gesture recognition based on accelerometer data,“ in 2019 41st Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC), pp. 5088- 5091, IEEE, 2019.
- [3] N. Koksal, M. Jalalmaab, and B. Fidan, „Adaptive linear quadratic attitude tracking control of a quadrotor uav based on imu sensor data fusion,“ Sensors, vol. 19, no. 1, p. 46, 2019.
- [4] A. Solanki, K. Prasad, R. Oreilly, and Y. Singhal, „Inertial mems test challenges,“ in International Mixed-Signals, Sensors and Systems Test Workshop, IEEE, 2011.
- [5] J. Rudolf, D. Gis, S. Stieber, C. Haubelt, and R. Dorsch, „Systeme power profiling for iot device firmware using runtime configurable models,“ in 2019 8th Mediterranean Conference on Embedded Computing (MECO), pp. 1-6, IEEE, 2019.
- [6] B. A. Krishna and A. S. Pillai, „Digital sensor simulation frame work for hardware-in-the-loop testing,“ in International Conference on Intelligent Computing, Instrumentation and Control Technologies, IEEE, 2017.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Verfügung zu stellen, mit dem sich die sensorinterne Datenverarbeitung auf eine reproduzierbare Weise testen, auf Fehler überprüfen und/oder optimieren lässt.
-
Das Verfahren gemäß Anspruch 1 erlaubt es gegenüber dem Stand der Technik, nicht nur in Echtzeit Daten zu erfassen, sondern auch zuvor aufgezeichnete Daten wieder in die reale Hardware einzuspeisen und auf diese Weise reproduzierbare Ergebnisse zu erhalten. Durch diesen Ansatz werden die positiven Aspekte der Verwendung von realer Hardware mit der zuverlässigen Reproduzierbarkeit von virtuellen Prototypen vereint. In Analogie mit dem Begriff „Hardware-in-the-Loop“ wird dieses Konzept im Folgenden als Sensor-in-the-Loop (SiL) bezeichnet. Dabei wird kann sowohl die echte Hardware mit einem Evaluierungsboard oder einem Prototyp verwendet werden, als auch zuvor aufgezeichnete Daten als alternative Eingabe zu den Sensoren genutzt werden. Die Platine oder der Prototyp ist dabei mit einem Computer verbunden und kommuniziert mit einem Softwareprogramm. Dieses Programm kann insbesondere sowohl die Sensordaten (insbesondere in Form von Rohdaten oder vorverarbeiteten Daten) als auch die verarbeiteten Daten erfassen, anzeigen und für spätere Verwendung speichern. Um reproduzierbare Ergebnisse zu erhalten, ist das erfindungsgemäße System in der Lage, zuvor erfasste Daten wieder in das Sensorsystem einzuspeisen. Das Sensorsystem verarbeitet dann die injizierten Daten und behandelt diese so, als wären sie von der Sensorhardware erzeugt worden. Dies ermöglicht die Entwicklung, Evaluierung und Fehlersuche im realen physikalischen Sensor in wiederholbarer Weise. Dies umfasst unter anderem die Nutzung von Systemressourcen, Echtzeitfähigkeit, Leistungsaufnahme oder Verhalten in Ausnahmefällen, ist aber nicht darauf beschränkt.
-
Das Sensorsystem ist insbesondere ein sogenannter intelligenter Sensor (Smart-Sensor) und enthält neben der mindestens einen Sensoreinheit eine integrierte Datenverarbeitungseinheit wie beispielsweise einen Anwendungsprozessor. Die Sensoreinheit wird durch den Sensor im engeren Sinn gebildet, d.h. das Element, das einen physikalischen Stimulus (z.B. Beschleunigung, Drehung, Temperatur oder Druck) in ein elektrisches Signal umwandelt. Bei der Sensoreinheit kann es sich insbesondere um ein mikroelektromechanisches System (MEMS) handeln, beispielsweise um einen mikroelektromechanischen Beschleunigungs- oder Drehratensensor. Das von der Sensoreinheit erzeugte elektrische Signal wird durch einen Analog-Digital-Wandler in ein digitales Signal umgewandelt, das anschließend von der Datenverarbeitungseinheit verarbeitet wird. Die Datenverarbeitung kann beispielsweise durch eine nichtprogrammierbare digitale logische Schaltung oder durch ein programmierbares Rechenwerk wie einen Mikroprozessor gebildet werden. Insbesondere kann das von dem Wandler erzeugte digitale Signal zunächst durch eine Hardwareimplementierte digitale Logik vorverarbeitet (z.B. gefiltert) und in einem Register gespeichert werden, aus dem die vorverarbeiteten Daten anschließend durch einen Mikrocontroller ausgelesen und weiterverarbeitet werden. Das Sensorsystem weist zusätzlich eine Speichereinheit auf, die als Random-Access Memory (RAM) ausgebildet sein kann und/oder durch einen Festspeicher (beispielsweise in Form eines Flash Speichers) erweitert bzw. ersetzt werden kann. Die Sensoreinheit, die Datenverarbeitungseinheit und die Speichereinheit können dabei in verschiedenen Integrationsstufen vorliegen, insbesondere als „System on Chip“ (SoC), als „System in Package“ (SiP) oder als „System on Module“ (SoM), wobei das erfindungsgemäße Konzept für alle diese Integrationsarten und deren Kombination gleichermaßen anwendbar ist.
-
Das Sensorsystem kann mehr als eine Sensoreinheit aufweisen, insbesondere können die verschiedenen Sensoreinheiten dabei für unterschiedliche physikalische Stimuli ausgelegt sein. Die einzelnen Sensoreinheiten können beispielsweise Beschleunigungen oder Drehraten bezüglich einer oder mehrerer Achsen messen und die Daten anschließend von der Datenverarbeitungseinheit zusammengeführt und aufbereitet werden (Multi-Sensor-Datenfusion). Insbesondere handelt es sich bei dem Sensorsystem um einen intelligenten Sensor-Hub. Im Folgenden wird bezüglich der Sensoreinheit vornehmlich die Einzahl verwendet, wobei jedoch eine Mehrzahl an Sensoreinheiten implizit eingeschlossen ist. Die Sensoreinheit und die Datenverarbeitungseinheit sind insbesondere über eine Schnittstelle (Inter-Circuit-Kommunikationsschnittstelle) wie beispielsweise eine serielle Peripherieschnittstelle (SPI) oder einen „Inter-Integrated Circuit“-Datenbus (I2C bzw. I2C) verbunden. Zusätzlich können zwischen Sensoreinheit und Datenverarbeitungseinheit eine oder mehrere Interrupt-Leitungen angeordnet sein, die eine Kommunikation mit niedriger Latenzzeit (beispielsweise für Ereignisse wie das Vorhandensein neuer Sensordaten) ermöglichen. Das Sensorsystem weist darüber hinaus eine oder mehrere Schnittstellen auf, um die verarbeiteten Daten an eine externe Vorrichtung weiterzugeben. Diese Schnittstelle kann beispielsweise über SPI, I2C oder durch eine Universal-Asynchronous-Empfänger-Sender-Schnittstelle (UART) realisiert werden und durch eine oder merhere weitere Interrupt-Schnittstelle ergänzt werden.
-
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind den Unteransprüchen sowie der Beschreibung unter Bezugnahme auf die Zeichnungen entnehmbar.
-
Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens werden die im Verarbeitungsschritt erzeugten Ausgangsdaten durch die externe Rechnereinrichtung ausgelesen, wobei in einem nachfolgenden Veränderungsschritt eine Veränderung der Datenverarbeitungseinheit erfolgt, wobei die aufgezeichneten Sensordaten in mindestens einem weiteren Injektionsschritt erneut in die Datenverarbeitungseinheit eingespeist und in einem weiteren Verarbeitungsschritt erzeugte weitere Ausgangsdaten durch die externe Rechnereinrichtung ausgelesen werden, wobei anschließend eine vergleichende Evaluation der funktionalen und extrafunktionalen Ergebnisse der Verarbeitungsschritte durchgeführt wird. Insbesondere erfolgt die Veränderung der Datenverarbeitungseinheit durch eine Veränderung der auf der Datenverarbeitungseinheit ausgeführten Software. Auf diese Weise lässt sich die Datenverarbeitungseinheit, bzw. die Software der Datenverarbeitungseinheit auf Fehler überprüfen (Debugging). Nach dem mindestens einen Injektionsschritt können insbesondere zusätzliche Iterationen erfolgen, bei denen ein oder mehrere weitere Injektionsschritte ausgeführt werden. Weiterhin ist es möglich, die Verarbeitungsgeschwindigkeit und/oder die bei der Verarbeitung verbrauchte elektrische Leistung oder andere Systemparameter zu evaluieren bzw. zu optimieren.
Vorzugsweise umfasst die vergleichende Evaluation der funktionalen Ergebnisse der Verarbeitungsschritte einen Vergleich der ersten und zweiten Ausgangsdaten und/oder die vergleichende Evaluation der extrafunktionalen Ergebnisse der Verarbeitungsschritte umfasst einen Vergleich des Leistungsverbrauchs und/oder der Antwortzeit und/oder des Durchsatzes und/oder Speicherbedarfs und/oder der Zuverlässigkeit und/oder der Energie.
-
Gemäß einer vorteilhaften Ausgestaltung wird während des Verarbeitungsschritts der Zustand der Datenverarbeitungseinheit, insbesondere der Zustand mindestens eines Speicherinhalts der Datenverarbeitungseinheit überwacht wird. Daraus ergibt sich vorteilhafterweise eine Möglichkeit, die Datenverarbeitung genau zu überwachen, zu analysieren und auf Fehler zu überprüfen.
-
Gemäß einer vorteilhaften Ausgestaltung weist das Sensorsystem mindestens eine weitere Sensoreinheit auf, wobei die Datenverarbeitungseinheit dazu konfiguriert ist, die von der Sensoreinheit ausgegebenen Sensordaten und von der weiteren Sensoreinheit ausgegebene weitere Sensordaten durch Datenfusion zu den Ausgangsdaten zu verarbeiten, wobei die weiteren Sensordaten im Aufzeichnungsschritt durch die externe Rechnereinrichtung aus dem Sensorsystem ausgelesen und aufgezeichnet werden und die aufgezeichneten weiteren Sensordaten im Injektionsschritt durch die externe Rechnereinrichtung in die interne Datenverarbeitungseinheit eingespeist werden. Diese Ausgestaltung entspricht einer Erweiterung auf Sensorsysteme mit mehreren Sensoren, insbesondere auf Sensorsysteme, die auf einem Multi-Sensor-Datenfusionsansatz basieren. Die in Bezug auf einen einzelnen Sensor beschriebenen Gestaltungsmöglichkeiten übertragen sich analog.
-
Gemäß einer vorteilhaften Ausgestaltung weist die interne Datenverarbeitungseinheit einen programmierbaren Mikroprozessor auf und die Systemsoftware des Mikroprozessors stellt vorzugsweise eine Funktion zum Auslesen der Sensordaten über eine Kommunikationsschnittstelle des Sensorsystems und besonders bevorzugt eine Funktion zur Injektion der aufgezeichneten Sensordaten bereit. Zur Realisierung des vorgeschlagenen SiL-Ansatzes muss die Firmware, die auf dem Anwendungsprozessor oder µC läuft, angepasst werden. Dies könnte durch die Einrichtung einer Bibliothek oder einer Sammlung von Funktionen erfolgen, die die Aufzeichnung und die Injektion der Daten des Sensors handhaben. Vorzugsweise ähneln diese Funktionen den ursprünglichen Funktionen der Sensor-Programmierschnittstelle (Application Programming Interface, API), die zum Lesen von Daten eines angeschlossenen Sensors unter Verwendung einer Kommunikationsschnittstelle wie SPI oder I2C oder zum Empfangen von Daten verwendet werden. Die Sensor-Firmware muss die Schnittstelle zwischen dem eigentlichen Sensor, dem Anwendungsprozessor und dem GUI implementieren. Dabei ist es entscheidend, dass das Zeitverhalten der modifizierten Firmware-Funktionen dem Zeitverhalten Originalfunktionen ähnelt oder mit diesem übereinstimmt.
-
Für die Gestaltung der Kommunikationsschnittstelle zwischen dem Anwendungsprozessor des Sensors und dem Computer, auf dem die grafische Benutzeroberfläche läuft, kommen eine Vielzahl von physikalischen Schnittstellen und Kommunikationsprotokollen in Frage. Abhängig von der gewünschten Anzahl verschiedener Sensortypen und Abtastraten jedes einzelnen Sensors Kriterien wie die Reihenfolge der Daten, Zuverlässigkeit, Durchsatz und Latenz in Betracht zu ziehen. Es ist dabei insbesondere unbedingt erforderlich, dass die Reihenfolge der Datenpakete (Sensordaten) während der Übertragung gleich bleibt. Die Zuverlässigkeit der Schnittstelle stellt sicher, dass während der Übertragung und bei jedem Lauf des Sensors mit den künstlichen Daten genau die gleichen Daten in der gleichen Reihenfolge verwendet werden. Der Durchsatz der Schnittstelle muss höher sein als der tatsächliche Sensordatendurchsatz, da es notwendig sein kann, zusätzliche Informationen wie Steuerdaten oder Berechnungsergebnisse zu senden. Weiterhin muss die Latenzzeit klein genug sein, um die Sensordaten für die vorgesehene Abtastrate in Echtzeit zu übertragen. Dabei ist es unter Umständen immer noch möglich, eine Schnittstelle zu verwenden, die nicht alle diese Anforderungen erfüllt. In einem solchen Fall ist es dann jedoch notwendig, die entsprechenden Anforderungen auf einer höheren Protokollebene manuell umzusetzen.
-
Gemäß einer vorteilhaften Ausgestaltung werden die Sensordaten, die Ausgangsdaten und/oder die weiteren Ausgangsdaten durch die Rechnereinrichtung grafisch dargestellt, wobei vorzugsweise vor der grafischen Darstellung eine Bearbeitung, besonders bevorzugt eine Filterung der Sensordaten durchgeführt wird. Dieser Teil des SiL-Konzepts betrifft die grafische Benutzeroberfläche (Graphical User Interface, GUI). Das GUI erlaubt es, die Sensor-Sensordaten vom entsprechenden Sensor in der gewünschten Datenrate aufzuzeichnen. Nachdem die Daten aufgezeichnet wurden, können sie modifiziert oder direkt zur erneuten Injektion verwendet werden, um verschiedene Varianten der Sensor-Firmware mit reproduzierbaren Datenmustern zu testen. Die Visualisierung der aufgezeichneten Daten und der entsprechenden Berechnungsergebnisse sind vorzugsweise ebenfalls über das GUI möglich. Diese Fähigkeiten ermöglichen es einem Ingenieur auf einfache und gezielte Weise, Software zu entwickeln, zu verbessern oder zu evaluieren.
-
Gemäß einer vorteilhaften Ausgestaltung weist die Sensoreinheit einen Analog-Digital-Wandler auf und die interne Datenverarbeitungseinheit weist eine durch Hardware implementierte logische Schaltung auf, wobei die aufgezeichneten Sensordaten in einem Datenpfad hinter dem Analog-Digital-Wandler und vor der logischen Schaltung eingespeist werden oder in ein Register der logischen Schaltung eingespeist werden.
-
Ein weiterer Gegenstand der Erfindung ist ein Sensorsystem gemäß Anspruch 9 und ein System gemäß Anspruch 10. Für das Sensorsystem und das System ergeben sich dieselben Gestaltungsmöglichkeiten und Vorteile, die in Bezug auf das erfindungsgemäße Verfahren beschrieben wurden.
-
Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Systems sind das Sensorsystem und die Rechnereinrichtung über eine Debugging-Sonde miteinander verbunden, wobei die Debugging-Sonde zum Auslesen und Einspeisen der Sensordaten konfiguriert ist
-
Ausführungsbeispiele der vorliegenden Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert.
-
Figurenliste
-
- 1 zeigt verschiedene Integrationslevel von intelligenten Sensoren.
- 2 zeigt eine typische Struktur eins Smart-Sensor-Hubs.
- 3 zeigt Komponenten eines intelligenten Sensors für eine mögliche Implementierung des erfindungsgemäßen Systems.
- 4 zeigt ein Flussdiagramm einer Beispielsoftware der Datenverarbeitungseinheit.
- 5 zeigt die Komponenten einer Ausführungsform des erfindungsgemäßen Systems, bei dem die Rechnereinrichtung mit dem Sensor über eine Debugging-Sonde verbunden ist.
- 6 zeigt den Datenfluss beim Auslesen und Einspeisen der Daten.
- 7 zeigt eine mögliche Implementierung des erfindungsgemäßen Verfahrens bei Sensoren ohne Mikrocontroller.
-
Ausführungsformen der Erfindung
-
Intelligente Sensoren können in drei verschiedene Integrationsstufen eingeteilt werden, die in 1 dargestellt sind. Die Version mit der höchsten Integration ist der SoC (System On Chip), dargestellt in 1a. Alle Komponenten 3, 4, 6 werden auf dem gleichen Die eines Halbleiterwafers platziert. Im Falle eines intelligenten Sensors gibt es mindestens ein MEMS-Element 6, einen Anwendungsprozessor 3 und ein Speicherelement 4 (hauptsächlich RAM). Die zweite Integrationsebene in 1b zeigt ein System in Package (SiP). Einige Komponenten werden im selben Gehäuse platziert und sind über Leitungen miteinander verbunden. Das MEMS-Element 6, der Mikrocontroller 3 und der Flash-Speicher 4 befinden sich auf dedizierten Dies, aber im gleichen Gehäuse. Die niedrigste Integrationsstufe bietet das System on Module (SoM)-Implementierung eines Smart Sensors zu sehen in 1c. Jede Systemkomponente 3, 4, 6 hat ihr eigenes Gehäuse und alle Komponenten 3, 4, 6 sind auf der gleichen Leiterplatte platziert. Das erfindungsgemäße Sensor-in-the-Loop-Konzept eignet sich für alle drei Arten von Smart-Sensor-Implementierungen. Auch Kombinationen der beschriebenen Integrationsarten sind möglich.
-
Ein typischer Smart-Sensor-Hub 1 ist in 2 dargestellt. Er besteht im Wesentlichen aus drei Komponenten, in denen das Integrationsniveau der individuellen Komponente von Typ zu Typ variieren kann. Der erste Teil wird von den Sensoren 2 gebildet (im abgebildeten Beispiel handelt es sich um drei einzelne Sensoren 2). Hierbei kann es sich beispielsweise um Trägheitssensoren wie Beschleunigungsmesser oder Drehratensensoren handeln. Andere Sensortypen z. B. Temperatur- oder Drucksensoren werden ebenfalls häufig in Sensor-Hubs 1 verwendet. Ein solcher Sensor 2 kann in der Regel wiederum in drei Unterkomponenten 6, 7, 8 unterteilt werden. Die erste Komponente ist das eigentliche Sensorelement 6, das oft in MEMS-Technologie hergestellt wird. Der Analog-Digital- Wandler (ADC) 7 wandelt die gemessene physikalische Größe in einen digitalen Wert um, der innerhalb des digitalen Logikteils 8 des Sensors 2 verwendet wird. In der digitalen Logik 8 kann der digitale Wert durch Filter vorverarbeitet werden, z. B. mit einem Tiefpassfilter oder einer Mittelung einer gewissen Anzahl von Werten. Nach der Vorverarbeitung werden die Daten in Registern gespeichert und können von der Datenverarbeitungseinheit 3, typischerweise einem Mikrocontroller 3 (Microcontroller Unit, MCU) über die Kommunikationsschnittstelle 10 angefordert werden. Es gibt eine Vielzahl von Inter-Circuit-Kommunikationsschnittstellen, die zur Verbindung von Komponenten in einem SiP verwendet werden. Häufig wird hier eine serielle Peripherieschnittstelle (SPI) oder Inter-Integrated Circuit (I2C) verwendet. Zusätzlich zur Kommunikationsschnittstelle 10 wird bei einigen Sensoren auch eine Interrupt-Leitung 11 mit der MCU 3 verbunden, um eine niedrige Latenzzeit bei der Benachrichtigung über Ereignisse, wie neuen Sensordaten zu erreichen. Verwendete MCUs 3 in Smart-Sensor-Hubs 1 sind im allgemeinen energieeffiziente µC oder anwendungsspezifisch proprietäre Verarbeitungseinheiten. Die MCU 3 kann durch zusätzliche Speichereinheiten erweitert werden, die als RAM 41 oder ROM 42 ausgebildet sind und die über eine Standard-Kommunikationsschnittstelle oder eine dedizierte Speicherschnittstelle angeschlossen werden. Die MCU 3 übernimmt die über die Schnittstelle 10 abgerufenen Daten als Datenfelder oder interne Registerwerte 15, führt mit diesen verschiedene Operationen durch und speichert die verarbeiteten Daten 14 im Speicherelement 41. Nach außen weist die Sensor-Hub 1 eine Schnittstelle 12 (z.B. SPI, I2C, UART) auf, um die verarbeiteten Daten an die externe Rechnereinrichtung 5 (Anwendungsprozessor, AP) zu übertragen. Zusätzlich kann zwischen dem Sensor-Hub 1 und der Rechnereinrichtung 5 eine Interrupt-Schnittstelle 13 angeordnet sein. Die Verwendung einer MCU 3 innerhalb eines Sensor-Hubs 1 ermöglicht es Entwicklern, alle bestehenden Sensoren 2 an einer Stelle zu testen und eine Vorverarbeitung dieser Daten durchzuführen, bevor sie an den AP 5 übertragen werden. Es gibt zahlreiche Möglichkeiten zur Manipulation der abgetasteten Daten in der MCU 3. Die gesammelten Daten könnten komprimiert oder gefiltert werden, zusätzlich kann der Entwickler sogenannte virtuelle Sensoren generieren, z.B. zur Schritterkennung, absoluten Orientierung oder zur Gestenerkennung.
-
3 zeigt Komponenten eines intelligenten Sensors 1 für eine Beispiel-Implementierung des erfindungsgemäßen Systems. Die Anwendbarkeit und die Vorteile des erfindungsgemäßen SiL-Konzepts lassen sich anhand des nachfolgend beschriebenen Prototyps demonstrieren. Für die Beispiel-Implementierung wird ein intelligenter programmierbarer Sensor 1 verwendet, der einen dreiachsigen 14-Bit-Beschleunigungsmesser 23, einen 16-Bit-Drehratensensor 22 und einen dreiachsigen geomagnetischer Sensor 21 mit einem 32-Bit-Mikrocontroller 3 kombiniert.
-
4 zeigt die Struktur der Firmware der Datenverarbeitungseinheit 3 der Beispiel-Implementierung. Das dargestellte Beispiel ist eine einfache Implementierung, die die drei enthaltenen Sensoren 21, 22, 23 des in 3 abgebildeten Systems konfiguriert. Im ersten Schritt 31 der Konfigurationsphase wird zunächst der Mikrocontroller 3 konfiguriert, im nachfolgenden Schritt 32 werden die Sensoren 21, 22, 23 konfiguriert und anschließend im Schritt 33 der Timer gestartet, so dass eine zyklisch wiederholte Abfrage 34 durchgeführt wird, bei der die Firmware die einzelnen Sensoren 21, 22, 23 mit einer konfigurierbaren Datenrate abtastet. Beim Vorliegen neuer Daten werden die Daten im Schritt 36 gesampelt und die erfassten Daten anschließend im Schritt 37 unter Verwendung der Universal-Asynchronous-Empfänger-Sender-Schnittstelle (UART) des µC 3 übermittelt. Diese Beispiel-Implementierung wurde um eine SiL-Bibliothek erweitert, die die notwendigen C-Funktionen durch die SiL-Funktionalitäten ergänzt. Diese Bibliothek bietet Funktionen zum Senden der abgerufenen Sensordaten über die SiL-Schnittstelle zum GUI der Rechnereinrichtung 5 für Aufnahme und Nachbearbeitung. Außerdem ist es möglich, die zuvor aufgezeichneten oder künstlich erzeugten Daten zurück in den laufenden Sensor zu injizieren. Für die Implementierung wurde 1 Kilobyte Puffer für jeden der drei Sensoren 21, 22, 24 verwendet. Die Größe dieses Puffers ist abhängig von der Datenrate und kann in den meisten Anwendungsfällen viel kleiner sein.
-
5 zeigen eine Ausführungsform des erfindungsgemäßen Systems, bei der für die Kommunikation zwischen dem externen Rechner 5 und dem auf einem Adapter-Board 27 angeordneten Sensorsystem 1 eine Debugging-Sonde 26 verwendet wird. Dabei ist die Sonde 26 an den Host-PC 5 über eine USB-Schnittstelle angeschlossen und unter Verwendung der 20 Pin Stiftleiste auf der Breakout-Platine mit dem „Serial Wire Debug Interface“ (SWD) des Sensorsystems 1 verbunden. Als Kommunikationsschnittstelle zwischen der laufenden Firmware des Sensorsystems 1 und den Prozess auf dem PC 5, der den Datenfluss steuert und die Daten visualisiert, wird eine Echtzeit-Übertragungsschnittstelle verwendet. Das zugehörige Übertragungsprotokoll ist in den Hardware-Debugger 26 integriert, der von einem Firmware-Entwickler genutzt werden kann, um die Sensor-Firmware zu debuggen. Dies bedeutet, dass keine zusätzliche Hardware für die Implementierung der SiL-Funktionen benötigt wird.
Zur Kontrolle des gesamten SiL-Prozesses während des Debuggings des Sensor-Targets 1, wurde ein Plugin 25 einer Open-Source-Entwicklungsumgebung (Integrated Development Environment, IDE) verwendet, das es erlaubt, alle notwendigen SiL-Funktionen für die Firmware-Entwicklung aus der IDE heraus zu nutzen. Die Kommunikation mit dem Plugin erfolgt über einen TCP-Socket der Debugging-Sonde 26. Die Verwendung der Standard-Socket-Implementierung in Java ermöglicht die Anwendung zur Steuerung des Datenflusses der SiL-Pakete für die Sensor-Anwendung. Nach Empfang der Daten aus dem Socket, verwendet der Debugger 26 eine Echtzeit-Schnittstelle zur Kommunikation mit dem Sensor 1 selbst.
-
6 zeigt den Datenfluss beim Auslesen und Einspeisen der Daten. Der obere Teil 41 stellt dabei die Aufzeichnung der Sensordaten dar, während im unteren Teil 42 die Injektion der aufgezeichneten Sensordaten darstellt. Bei dem dargestellten beispielhaften Fall ist die Datenverarbeitungseinheit 3 des Sensorsystems 1 dazu konfiguriert, Sensordaten von mehreren Sensoren über Datenfusion zusammenzuführen und die verarbeiteten Daten auszugeben. Bei dieser Implementierung des erfindungsgemäßen Verfahren kommunizieren das Sensorsystem 3, die Rechnereinrichtung 5, die Speichereinheit 30 der Rechnereinrichtung und die grafische Benutzeroberfläche (Graphical User Interface, GUI) 34 in folgender Weise: Die Sensordaten werden zunächst von der Datenverarbeitungseinheit 3 des Sensorsystems 1 an die Rechnereinrichtung 5 übermittelt und von dieser in der Speichereinheit 30 aufgezeichnet (dieser Teil des Datenflusses ist durch die Pfeile 31 angedeutet). Anschließend werden die gespeicherten Sensordaten wieder durch den Rechner 5 abgerufen und in die Datenverarbeitungseinheit 3 eingespeist (angedeutet durch die Pfeile 32). Die Datenverarbeitungseinheit signalisiert, dass es die Daten empfangen hat (Pfeil 35) und führt in einem Datenverarbeitungsschritt die Datenfusion auf Grundlage der Sensordaten aus. Die fusionierten Daten werden an den Rechner 5 übermittelt und von diesem abgespeichert (Pfeile 33). Der Rechner 5 ist nun in der Lage über die grafische Benutzeroberfläche 34 sowohl die Sensordaten, als auch die fusionierten Daten darzustellen (Pfeil 36). Auf diese Weise lässt sich beispielsweise der auf der Datenverarbeitungseinheit 3 ausgeführte Algorithmus zur Verarbeitung und Datenfusion auf Fehler überprüfen, testen bzw. optimieren.
-
Das erfindungsgemäße Verfahren und die Sensor-in-the-Loop-Architektur geben einem Entwickler die Möglichkeit, zuvor aufgezeichnete Daten von einem intelligenten Sensor 1 (insbesondere einem Inertialsensor) zurück in den Sensor 1 zu injizieren, so dass die Sensorsoftware mit reproduzierbaren Ergebnissen direkt auf der Hardware evaluiert und getestet werden kann. Dieser Ansatz besteht aus drei Architekturschichten und kann auf praktisch jeder intelligenten Sensor-Hardware implementiert werden.
-
7 zeigt eine mögliche Implementierung des erfindungsgemäßen Verfahrens bei Sensoren ohne Mikrocontroller. Der Signalpfad führt dabei von dem mikroelektromechanischen System (MEMS) über einen Analog-Digital-Wandler 7 zu einer digitalen Logikeinheit, d.h. zu einer durch Hardware implementierten logischen Schaltung 8, die bei dieser Implementierung die Datenverarbeitungseinheit 3 darstellt, in die aufgezeichneten Sensordaten eingespeist werden. Die Injektionsschnittstelle 41 ist dabei im Beispiel aus 7a im Datenpfad hinter dem Wandler 7 und vor der digitalen Logik 8 angeordnet. Alternativ dazu kann die Injektionsschnittstelle 41 wie in 7b dargestellt direkt in digitale Logik 8 selbst führen und die Injektion insbesondere durch Schreiben in ein Register erfolgen. In beiden Beispielen kann die digitale Logik 8 zusätzlich eine Debugging/Kontroll-Schnittstelle 43 aufweisen.
