-
Die Erfindung bezieht sich auf die Software-Entwicklung und insbesondere auf Software-Rahmen und Software-Entwicklungsplattformen für Multisensorsysteme.
-
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung Nr. 61/422.084, eingereicht am 10. Dezember 2010, mit dem Titel ”Software Framework and Development Platform for Multi-Sensor Systems”, deren gesamte Inhalte hier durch Bezugnahme mit aufgenommen sind.
-
Viele moderne Mobilvorrichtungen (z. B. Smartphones, elektronische Tabletts) umfassen eine Reihe von Sensoren, um Anwendungen zu unterstützen, die Trägheits- und Umgebungssensordaten benötigen. Trägheitsdaten können durch integrierte Beschleunigungsmesser, Gyrosensoren und Magnetometer geliefert werden. Umgebungssensordaten können durch Temperatur-, Druck-, Näherungs- und Umgebungslichtsensoren geliefert werden. Trägheits- und Umgebungssensoren können durch eine Vielzahl von Herstellern als IC-Bausteine beschafft werden. Somit ist es üblich, dass eine einzige Vorrichtung Sensoren von verschiedenen Herstellern enthält. Jeder Sensor kann seinen eigenen Software-Treiber enthalten, um für die Interaktion mit dem Sensor wie beispielsweise das Anfordern von Sensordaten oder das Programmieren des Sensors das Ausführen von Programmcode durch einen Anwendungsprozessor (z. B. einen Mikrocontroller) zu ermöglichen.
-
Da die Hersteller von Sensorvorrichtungen ihre Vorrichtungen an viele Kunden verkaufen, liefern die Sensorvorrichtungen im Allgemeinen Rohdaten, um zu ermöglichen, dass die Software-Anwendungen des Kunden die Rohdaten wie gewünscht verarbeiten. Anwendungsentwickler müssen eine weitere Verarbeitung der Rohdaten (z. B. Skalieren und Umrechnen von Einheiten) vornehmen, was vom Anwendungsprozessor zusätzliche Verarbeitungszyklen verlangt.
-
Der Erfindung liegt die Aufgabe zugrunde, einen Software-Rahmen und eine Software-Entwicklungsplattform zu schaffen, die wesentliche Vorteile bieten.
-
Die oben genannte Aufgabe wird erfindungsgemäß gelöst durch ein System nach Anspruch 1 bzw. ein Verfahren nach Anspruch 4. Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
-
Der Software-Rahmen und die Software-Entwicklungsplattform, die offenbart worden sind, erleichtern die Software-Entwicklung für Multisensorsysteme. Bei manchen Implementierungen können Entwickler eine Sensorkarte auswählen, die eine gewünschte Kombination von Sensorvorrichtungen enthält. Die Sensorkarte kann mit einer Entwicklungskarte gekoppelt sein, die einen Zielprozessor und weitere Schaltungen enthält, um die Entwicklung und das Testen eines Systems, das den Zielprozessor und die Sensoren enthält, zu erleichtern. Es sind verschiedene Software-Unterstützungswerkzeuge bereitgestellt, die eine Anwendungsprogrammierschnittstelle (API) umfassen, die API-Abstraktionen für Software-Treiber für die Sensoren auf der Sensorkarte liefert. Durch Verwendung der Abstraktionen der API muss ein Software-Entwickler keinen Code (”Leim”) zur Interaktion mit den verschiedenen Software-Treibern schreiben. Außerdem verschafft die API Zugriff auf eine Vielzahl von Software-Bibliotheksfunktionen zum Ausführen von Datenskalierung, Umrechnung von Einheiten sowie mathematischen Funktionen und Algorithmen.
-
Bestimmte Ausführungsformen der Erfindung können implementiert sein, um einen oder mehrere der folgenden Vorteile zu verwirklichen: 1) schnelle und effiziente Software-Entwicklung für Multisensorsysteme, 2) reduzierte Software-Entwicklungskosten und 3) eine einfache Schnittstelle zu Sensoren und Standard-API-Definition zur Anwendungs-Software.
-
Weitere Merkmale und Vorteile der Erfindung werden deutlich beim Lesen der folgenden Beschreibung bevorzugter Ausführungsformen, die auf die Zeichnungen Bezug nimmt, es zeigen:
-
1 einen Blockschaltplan eines beispielhaften Software-Entwicklungssystems zum Entwickeln und Testen von Multisensorsystemen,
-
2 eine beispielhafte Software-Architektur zum Entwickeln von Software unter Verwendung des Software-Entwicklungssystems von 1,
-
3 einen Ablaufplan eines beispielhaften Prozesses zum Anfordern von Sensordaten unter Verwendung der Software-Architektur von 2 und
-
4 einen Blockschaltplan eines beispielhaften Multisensorsystems zum Speichern und Ausführen von durch das Software-Entwicklungssystem von 1 entwickelter Software unter Verwendung der Software-Architektur von 2.
-
Beispielhafte Entwicklungsplattform
-
1 ist ein Blockschaltplan eines beispielhaften Software-Entwicklungssystems 100 zum Entwickeln und Testen von Multisensorsystemen. In manchen Implementierungen umfasst das System 100 eine Entwicklungskarte 102 und eine Sensorkarte 104.
-
Die Entwicklungskarte 102 kann einen Zielprozessor 106, einen Karten-Controller 108, digitale Anschlüsse 110a–b, einen Datenspeicher 112 (z. B. einen Flash-Speicher), einen analogen Anschluss 114, einen Programmieranschluss 116, einen seriellen Anschluss 118 (z. B. USB), einen Vielzweck-E/A-Anschluss 120 (GPIO) und eine Berührungs-Schiebeeinrichtungs-Schnittstelle 122 enthalten.
-
Der Zielprozessor 106 ist jener Prozessor, der die Software, die unter Verwendung der Entwicklungskarte 102 entwickelt oder getestet wird, speichert und ausführt. Der Karten-Controller 108 steuert die Funktionen der Entwicklungskarte 102 einschließlich des Leistungsmanagements, der E/A-Anschlüsse und Peripherieeinheiten, des Busmanagements, des Speichermanagements und irgendwelcher weiterer Funktionen, die mit der Entwicklungskarte 102 zusammenhängen. Der Karten-Controller 108 kann Betriebssystemcode zur Erfüllung der verschiedenen Entwicklungskartenfunktionen ausführen. Die digitalen Anschlüsse 110a, 110b bilden eine digitale Schnittstelle zur Entwicklungskarte 102 für verschiedene digitale Vorrichtungen und Peripherieeinheiten. Der analoge Anschluss 114 bildet eine analoge Schnittstelle zur Entwicklungskarte 102 für verschiedene analoge Vorrichtungen und Peripherieeinheiten. Der Programmieranschluss 116 bildet eine Schnittstelle zur Entwicklungskarte 102, die einer weiteren Rechenvorrichtung ermöglicht, Programmcode in die Entwicklungskarte 102 zur Ausführung durch den Zielprozessor 106 zu laden. Der serielle Anschluss 118 bildet eine serielle Kommunikationsschnittstelle (z. B. USB) zur Entwicklungskarte 102. Der Vielzweck-E/A-(GPIO)-Anschluss stellt einen allgemeinen Schnittstellenanschluss zur Entwicklungskarte 102 für externe Vorrichtungen und Peripherieeinheiten dar. Die Berührungs-Schiebeinrichtungs-Schnittstelle 122 bildet eine Schnittstelle zur Entwicklungskarte 102 für Berührungs-Schiebeinrichtungseingabe. Weitere Entwicklungskarten können mehr oder weniger Komponenten enthalten.
-
Die Sensorkarte 104 kann eine Schnittstelle 124 zur Kommunikation mit der Entwicklungskarte 102 enthalten. Die Sensorkarte 104 enthält Sensoren 126a–126c. Die Sensoren 126 können irgendeine Kombination von durch den Entwickler ausgewählten Sensorvorrichtungen sein. Die Sensoren 126a–126b können Trägheitssensoren sein, wobei der Sensor 126a ein Beschleunigungsmesser ist, der Sensor 126b ein Gyrosensor ist und der Sensor 126c Magnetometer ist. Manche Sensorkarten können Umgebungssensoren enthalten, die Temperatursensoren, Drucksensoren und Lichtsensoren umfassen. Nochmals weitere Sensorkarten können eine Kombination von Trägheitssensoren und Umgebungssensoren enthalten.
-
Jede dieser Sensorvorrichtungen kann ein von einem anderen Hersteller gelieferter IC-Chip sein. In einem einzigen IC-Gehäuse können mehrere Sensoren (z. B. eine Beschleunigungsmesser- und Gyroskopkombination) vorgesehen sein. Jede Sensorvorrichtung kann durch einen eigens für jenen speziellen Sensor entwickelten Software-Treiber rohe Sensordaten liefern. Der zugeordnete Software-Treiber bildet eine API der unteren Ebene, um dem Anwender das Anfordern von rohen Sensordaten zu ermöglichen. Der Anwendungsprogrammcode kann durch eine API der oberen Ebene, die Abstraktionen für die Software-Treiber liefert, um so den Software-Treibern eine Transparenzschicht hinzuzufügen, auf diese Software-Treiber zugreifen. Diese zusätzliche Transparenzebene kann dadurch, dass sich die Wissensmenge, die der Entwickler darüber benötigt, wie die Software-Treiber mit den Sensoren kommunizieren, verringert, die Entwicklung des Anwendungsprogrammcodes vereinfachen. Mit der API der oberen Ebene ist kein sensorspezifischer Code für die Anwendung erforderlich. Mittels der API der oberen Ebene können Anwendungen ohne Quellcodemodifikation mit verschiedenen Hardware-Plattformen verwendet werden. Die API der oberen Ebene wird mit Bezug auf 2 näher besprochen.
-
2 zeigt eine beispielhafte Software-Architektur 200 zum Entwickeln von Software mit Hilfe des Software-Entwicklungssystems von 1. In manchen Implementierungen kann die Software-Architektur 200 konzeptionell eine Anwendungsschicht 202, eine Software-Bibliotheksschicht 204 und eine Treiberschicht 206 umfassen. Die Treiberschicht 206 kommuniziert direkt mit einer Hardware 208, die die Sensorvorrichtungen auf der Sensorkarte 104 enthält. Die Software-Architektur 200 repräsentiert eine konzeptionelle Hierarchie oder einen ”Software-Stapel”, den API-Funktionsaufrufe und API-Funktionsaufrufantworten durchqueren können. Beispielsweise kann ein Anwendungsprogramm, das einen Kompasskurs benötigt, den API-Funktionsaufruf an eine Software-Bibliotheksfunktion zur Berechnung des Kompasskurses absetzen. Die Software-Bibliotheksfunktion kann Definitionen und Deklarationen zum Definieren von Datenstrukturen zur Rückgabe von API-Funktionsaufrufergebnissen zugeordnet sein. Ein API-Funktionsaufruf kann eine Parameterliste umfassen, die Variablen oder Zeiger zum Senden und Empfangen von Daten und Zeiger zu und von dem zugrunde liegenden Software-Bibliothekscode zum Durchführen der Kompasskursberechnung liefert. Der Software-Bibliothekscode kann durch die Sensorhersteller gelieferte API der unteren Ebene verwenden, um auf in Datenregistern in den Sensorvorrichtungen gespeicherte Rohdaten zuzugreifen. Diese API der unteren Ebene sind für den Anwendungsentwickler aufgrund der API-Abstraktionen der oberen Ebene transparent.
-
In der beispielhaften Architektur 200 gibt es in der Hardware 208 eine Mischung von Trägheits- und Umgebungssensoren. Dies führt zu Treibern und API-Abstraktionen in der Treiberschicht 206 für jeden der Sensoren, wie sie in 2 gezeigt sind. Software-Bibliotheksfunktionen in der Software-Bibliotheksschicht 204 greifen mittels der API-Abstraktionen auf die Software-Treiber zu. Einige Beispiele von Software-Bibliotheksfunktionen sind das Skalieren, das Umrechnen von Einheiten, mathematische Berechnungen oder Algorithmen oder irgendeine andere gewünschte Funktion, die für eine Anwendung nützlich sein kann. Die in 2 gezeigten Sensoren entsprechen keiner erschöpfenden Auflistung; in ähnlicher Weise können weitere Typen von Sensoren unterstützt sein.
-
In manchen Implementierungen kann in der Treiberschicht 206 ein Software-Rahmen vorgesehen sein. Ein Software-Rahmen ist eine Abstraktion, die üblichen Code zum Verschaffen einer allgemeinen Funktionalität umfasst, der wahlweise durch Anwendercode überschrieben oder spezifiziert werden kann, um so eine spezifische Funktionalität zu verschaffen. Der Software-Rahmen kann wieder verwendbare Abstraktionen von in der API verborgenem Code umfassen, die kennzeichnende Merkmale enthalten können, die sie von anderen Software-Bibliotheksfunktionen unterscheiden.
-
3 ist ein Ablaufplan eines beispielhaften Prozesses 300 zum Anfordern von Sensordaten unter Verwendung der Software-Architektur von 2. In manchen Implementierungen kann der Prozess 300 beginnen, wenn von einer Anwendung eine Anforderung von Sensordaten empfangen wird (302). Eine solche Anforderung kann auf Grundlage einer programmierten Zeitperiode, durch die Anwendung identifizierter Bedingungen oder in Ansprechen auf Unterbrechungen oder andere asynchrone Ereignisse einschließlich jener, die durch die Sensorvorrichtung selbst erzeugt werden, eingeleitet werden. Die Anforderung kann von einem Anwendungsprogramm durch einen API-Aufruf ausgeführt werden. Der API-Code kann in der Programmiersprache C oder irgendeiner anderen geeigneten Sprache implementiert sein. Strukturdefinitionen können C-Unions verwenden, um ”Aliases” von Datenfeldern für verschiedene Datenklassen zu ermöglichen. Ein Zeitstempelfeld kann von einem Echtzeit-Taktgeber automatisch mit einem Wert (z. B. einem Mikrosekundenwert) ausgefüllt werden.
-
Der Prozess 300 identifiziert einen Zielsensor zum Liefern von Sensordaten (304). Der Prozess 300 prüft, um zu sehen, ob rohe Sensordaten angefordert worden sind (306). Wenn rohe Sensordaten angefordert worden sind, fordert der Prozess 300 die rohen Sensordaten vom Zielsensor an (308), empfängt die Rohdaten vom Zielsensor (310) und sendet die rohen Sensordaten zur aufrufenden Anwendung zurück (312). Wenn keine rohen Sensordaten angefordert worden sind, fordert der Prozess 300 die Rohdaten vom Zielsensor an (314), empfängt die rohen Sensordaten vom Zielsensor (316), verarbeitet die Rohdaten (318) und sendet die verarbeiteten rohen Sensordaten zur aufrufenden Anwendung zurück (320). Das Verarbeiten der Rohdaten (318) kann das Datenskalieren, das Umsetzen oder das Berechnen mathematischer Formeln und Algorithmen unter Verwendung der Rohdaten umfassen.
-
Beim Verwenden der API der oberen Ebene kann eine Beschleunigungsablesesequenz die folgende Form besitzen:
-
In diesem Beispiel können der API-Aufruf Sensor_attach () und der Sensor-Deskriptor accel_dev dazu verwendet werden, den Beschleunigungsmesser als Zielsensor zu identifizieren. Rohe Beschleunigungsmesserdaten können durch das aufrufende Anwendungsprogramm angefordert werden, in dem accel_data.scaled = true gesetzt wird. Dies führt dazu, dass rohe Beschleunigungsdaten in Milli-g zum aufrufenden Anwendungsprogramm zurückgesendet werden. Der API-Funktionsaufruf sensor_get_acceleration () kann dazu verwendet werden, die Beschleunigungsdaten zu erlangen und die Beschleunigungsdaten in den drei Feldern der accal_data-Struktur zurückzusenden.
-
Die API kann zum Zurücksenden von Sensordaten zwei grundlegende strukturierte Datentypen verwenden. Der erste Datentyp ist vector_data_t. Dieser Datentyp kann für 3-Achsen-Messvorrichtungen (z. B. Beschleunigungsmesser, Gyroskop) oder andere Ablesungen, die drei Werte zurückgeben (z. B. Kompasskurs) verwendet werden. Die drei Werte können in drei separaten Datenfeldern (z. B. als ganze Zahlen mit 32 Bit und Vorzeichen) zurückgesendet werden. Der zweite Datentyp ist scalar_t. Dieser Datentyp kann dazu verwendet werden, eindimensionale Messwerte (z. B. Temperatur, Druck) zurückzusenden.
-
Andere Sensoren besitzen eine ähnliche Ablesesequenz. Beispielsweise kann ein Gyrosensor eine Ablesesequenz in der folgenden Form besitzen:
-
Viele Sensorvorrichtungen können Temperaturdaten als sekundären Ausgabewert liefern. Die Temperaturdaten können intern in der Vorrichtung zur Temperaturkompensation verwendet werden. Eine beispielhafte Temperaturablesesequenz für ein Gyroskop kann die folgende Form besitzen:
-
In manchen Implementierungen können API-Aufrufe mathematische Funktionen oder Algorithmen liefern. Beispielsweise beinhaltet ein API-Aufruf für den Kompasskurs das Sammeln von 3-Achsen-Magnetsensormesswerten X, Y, Z und das Verwenden einer Schwerebeschleunigung vom Beschleunigungsmesser, um Neigungswinkel für das Wanken (θ) und das Nicken (ϕ) zu messen. Die X- und Y-Magnetsensormesswerte können in eine durch Vektoren XH und YH definierte horizontale Ebene gedreht werden, und zwar mit Hilfe der folgenden Gleichungen [1] und [2]: XH = X·cos(ϕ) + Y·sin(θ)·sin(ϕ) – Z·cos(θ)·sin(ϕ) [1] YH = Y·cos(θ) + Y·sin(θ) [2]
-
Der Azimut kann berechnet werden anhand der Gleichungen [1] und [2] unter Verwendung der Gleichung [3]: Azimut = [(tan)](–1) (YH/XH) [3]
-
Eine Magnetkursberechnungssequenz kann die folgende Form besitzen:
-
4 ist ein Blockschaltplan eines beispielhaften Multisensorsystems 400 zum Speichern und Ausführen von durch das Software-Entwicklungssystem von 1 unter Verwendung der Software-Architektur von 2 entwickelter Software. In manchen Implementierungen kann das System 400 eine Speicherschnittstelle 402, einen oder mehrere Prozessoren 404, eine Peripherieeinheitenschnittstelle 406, einen Speicher 410, ein E/A-Subsystem 412, einen Beschleunigungsmesser 414, ein MEMS-Gyroskop 416, ein Magnetometer 418 und einen Drucksensor 420 umfassen. Das E/A-Subsystem 412 umfasst einen Berührungs-Controller 422, der mit dem Berührungsbildschirm/Berührungsfeld 426 gekoppelt ist, und weitere Eingabe-Controller 424, die mit anderen Eingabe-/Steuervorrichtungen (z. B. Schaltern) gekoppelt sind. Die für die Sensoren 414, 416, 418 und 420 entwickelte Software kann im Speicher 410 gespeichert und durch den (die) Prozessor(en) 404 ausgeführt werden, um Sensordaten zu einer oder mehreren Anwendungen zu liefern, die ebenfalls im Speicher 410 gespeichert sind und durch den (die) Prozessor(en) 404 ausgeführt werden.
-
Obwohl dieses Dokument viele spezifische Implementierungsdetails enthält, sollten diese nicht als Beschränkungen des Umfangs dessen, was beansprucht sein kann, aufgefasst werden, sondern vielmehr als Beschreibungen von Merkmalen, die für bestimmte Ausführungsformen spezifisch sein können. Gewisse Merkmale, die in dieser Patentbeschreibung im Kontext verschiedener Ausführungsformen beschrieben worden sind, können auch in Kombination in einer einzelnen Ausführungsform implementiert sein. Umgekehrt können verschiedene Merkmale, die im Kontext einer einzelnen Ausführungsform beschrieben worden sind, auch in mehreren Ausführungsformen getrennt oder in irgendeiner geeigneten Teilkombination implementiert sein. Obwohl Merkmale oben als in bestimmten Kombinationen wirkend beschrieben und sogar zu Anfang als solche beansprucht sein können, können ein oder mehrere Merkmale einer beanspruchten Kombination in manchen Fällen aus der Kombination herausgeschnitten sein und kann die beanspruchte Kombination auf eine Teilkombination oder eine Variante einer Teilkombination gerichtet sein.
