-
Die Erfindung betrifft ein Verfahren zum Überwachen einer um einen Raum (Geozone) herum angeordneten virtuellen Grenze (Geofence) gemäß dem Oberbegriff des Anspruchs 1. Gegenstand der vorliegenden Erfindung sind auch ein Computerprogramm und ein maschinenlesbarer Datenträger zur Speicherung des Computerprogramms, mittels derer das erfindungsgemäße Verfahren auf einem Rechengerät durchführbar ist.
-
Stand der Technik
-
Ein sogenannter „Geofence“ stellt eine virtuelle Grenze um ein Gebiet oder einen Raum (sog. „Geozone“) herum dar. Wenn ein Nutzer oder ein mobiles Gerät, z.B. ein Smartphone, einen solchen Geofence überschreitet, so betritt oder verlässt er die durch den Geofence jeweils begrenzte Geozone.
-
Es existieren bereits Systeme zum Überwachen solcher Geofences, z.B. bei dem von der Firma Google vertriebenen „Android“-Betriebssystem, dem von der Firma Apple vertriebenen „iOS“-Betriebssystem, bei der an sich bekannten Smartphone-App „Life360“ oder beim sogenannten „Familonet“. Diese Systeme nutzen globale Navigationssatellitensysteme (GNSS) sowie teilweise weitere Sensorik. Sie können auf verschiedenen Geräten installiert und betrieben werden. Um dabei eine Vielzahl unterschiedlicher Sensoren unterstützen zu können, verfügen sie über eine vereinheitlichte (abstrahierte) Schnittstelle, um auf die Sensorik zuzugreifen.
-
Diese bekannten Systeme benötigen zur Überwachung der Geofences nachteilig relativ viel Energie. Daher existieren neben den genannten Systemen, die mittels GNSS Geofences überwachen, alternative Systeme zu einer solchen Geolokalisierung. Bei diesen alternativen Systemen werden spezielle, sehr hardwarenahe Implementierungen, z.B. Implementierungen auf einem Sensorhub oder einem DSP (Digitaler Signal Prozessor), zur Kurzzeitlokalisation von Personen (z.B. „PDR“ - Pedestrian Dead Reckoning bzw. Fußgängerkoppelnavigation) eingesetzt. Diese alternativen Systeme bieten somit den Vorteil, sehr energiesparend zu sein. Ihr Nachteil ist allerdings, dass sie bei längerer Betriebsdauer zunehmend ungenauer werden, sofern sie nicht von einer weiteren Informationsquelle unterstützt werden können. Daher werden diese Systeme derzeit nicht zur Überwachung von Geofences eingesetzt.
-
Offenbarung der Erfindung
-
Im Gegensatz zum Stand der Technik, bei dem die zum Überwachen von Geofences erforderlichen Funktionalitäten auf der Nutzung von GNSS beruhen, erfolgt bei dem hier vorgeschlagenen Verfahren eine Kombination von an sich verfügbaren GNSS mit möglichst hardwarenahen Implementierungen. Dadurch wird im Ergebnis eine hardwarespezifische, energieoptimale Überwachung von Geofences bereitstellt, welche jedoch den genannten Nachteil des Ungenauerwerdens bei längeren Betriebsdauern nicht besitzen.
-
Bei dem vorgeschlagenen Verfahren gemäß Anspruch 1 zum Überwachen einer um einen Raum (Geozone) herum angeordneten virtuellen Grenze (Geofence) bezüglich eines zu überwachenden Objektes, wobei die virtuelle Grenze anhand von ersten Ortsdaten definierbar ist und wobei aktuelle zweite Ortsdaten des zu überwachenden Objektes mittels eines globalen Navigationssatellitensystems (GNSS) erzeugbar sind, und wobei die Überwachung des zu überwachenden Objektes auch mittels einer hardwarenahen Lokalisierungsschätzung durchführbar ist, ist insbesondere vorgesehen, dass erste Ortsdaten der virtuellen Grenze erzeugt und gespeichert werden, dass aktuelle zweite Ortsdaten des Objektes mittels GNSS erzeugt und gespeichert werden, dass aus den gespeicherten Ortsdaten der virtuellen Grenze und des Objektes der momentane Abstand zwischen dem Objekt und der virtuellen Grenze sowie die Bewegungsgeschwindigkeit und die Bewegungsrichtung des Objektes berechnet werden, dass aus den berechneten Daten eine Vorhersage getroffen wird, ob das Objekt die virtuelle Grenze innerhalb einer vorgebbaren Zeitdauer durchbricht, und dass bei nicht vorhergesagtem Durchbrechen innerhalb der vorgebbaren Zeitdauer die Überwachung des Objektes ausschließlich mittels der hardwarenahen Lokalisierungsschätzung durchgeführt wird.
-
Die algorithmische Überwachung anhand der ersten und zweiten Ortsdaten kann mittels eines auf dem mobilen Objekt eingerichteten Anwendungsprogramms und die hardwarenahe Lokalisierungsschätzung mittels eines auf dem mobilen Objekt angeordneten, virtuellen Sensors durchgeführt werden. Der virtuelle Sensor kann durch einen auf dem mobilen Objekt angeordneten Signalprozessor zur Kurzzeitlokalisation des Objektes oder durch ein Sensorhub gebildet sein.
-
Die Vorteile des vorgeschlagenen Verfahrens, welches die beiden Methoden der algorithmischen Überwachung mittels Geolokalisierung, z.B. durch GNSS-Daten und der hardwarenahen Lokalisierungsschätzung, miteinander kombiniert, liegen im besonders sparsamen Umgang mit Rechenoperationen und somit auch mit Energie.
-
Bei dem vorgeschlagenen Verfahren kann vorgesehen sein, dass, wenn bei der algorithmischen Überwachung die Bedingung gemäß der Vorhersage nicht erfüllt ist, die algorithmische Überwachung deaktiviert oder in einen Schlafmodus gesetzt wird und dass innerhalb der vorgebbaren Zeitdauer die Überwachung des mobilen Objektes ausschließlich mittels der hardwarenahen Lokalisierungsschätzung anhand einer Prüfschleife durchgeführt wird.
-
Bei dem vorgeschlagenen Verfahren kann vorgesehen sein, dass, wenn bei der algorithmischen Überwachung die Bedingung gemäß der Vorhersage erfüllt ist, die Überwachung des mobilen Objektes durch algorithmische Überwachung mittels Geolokalisierung, z.B. durch von dem globalen Navigationssatellitensystem bereitgestellte Daten, erfolgt.
-
Bei dem vorgeschlagenen Verfahren kann ferner vorgesehen sein, dass die bei der hardwarenahen Lokalisierungsschätzung ausgeführte Prüfschleife auf einer oder mehreren der folgenden Bedingungen beruhend durchgeführt wird:
- - Innerhalb eines vorgebaren Zeitfensters können keine Daten von dem globalen Navigationssatellitensystem abgerufen werden;
- - Es wird keine Bewegung des mobilen Objektes erkannt;
- - Es wird eine Bewegung des mobilen Objektes erkannt, aber anhand einer aus der ermittelten Geschwindigkeit und Entfernung zur nächsten virtuellen Grenze berechneten Ankunftszeit kann die virtuelle Grenze bei angenommener gleichbleibender Geschwindigkeit des Objektes innerhalb einer vorgebbaren Zeitdauer nicht erreicht werden;
- - Es wird eine Bewegung des mobilen Objektes erkannt und die virtuelle Grenze kann innerhalb der vorgebbaren Zeitdauer erreicht werden, jedoch bewegt sich das mobile Objekt nicht innerhalb eines vorgebbaren Winkels auf die virtuelle Grenze zu.
-
Die Erfindung kann insbesondere in einem Smartphone oder einer Smartwatch zur Anwendung kommen.
-
Das erfindungsgemäße Computerprogramm ist eingerichtet, jeden Schritt des Verfahrens durchzuführen, insbesondere wenn es auf einem Rechengerät, insbesondere auf einem mobilen Datenkommunikationsgerät (z.B. Smartphone oder Smartwatch) oder in einem Steuergerät eines Kraftfahrzeugs, abläuft. Es ermöglicht die Implementierung des erfindungsgemäßen Verfahrens auf einem solchen Datenkommunikationsgerät oder Steuergerät, ohne an diesen bauliche Veränderungen vornehmen zu müssen. Hierzu ist der maschinenlesbare Datenträger vorgesehen, auf welchem das erfindungsgemäße Computerprogramm gespeichert ist.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweiligen angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Figurenliste
-
- 1 zeigt typische Verfahrensschritte gemäß einem ersten Ausführungsbeispiel des erfindungsgemäßen Verfahrens, anhand eines Flussdiagramms.
- 2a und 2b zeigen eine detaillierte Ausgestaltung gemäß einem zweiten Ausführungsbeispiel des erfindungsgemäßen Verfahrens, anhand eines geteilten Flussdiagramms.
-
Beschreibung von Ausführungsbeispielen
-
Bei dem in 1 gezeigten Verfahren zum Überwachen eines um eine Geozone (= Raumgebiet) herum angeordneten Geofence (= virtuelle Grenze) in Bezug auf ein zu überwachendes Objekt, in dem vorliegenden Beispielszenario ein Smartphone, wird vorausgesetzt, dass der Geofence anhand von Ortsdaten auf dem Smartphone definierbar bzw. anlegbar ist. Es ist anzumerken, dass es sich bei dem zu überwachenden Objekt um ein beliebiges mobiles Gerät, wie das genannte Smartphone oder ein Kraftfahrzeug, bzw. um einen das mobile Gerät führenden bzw. tragenden Nutzer, handeln kann.
-
Zudem wird vorausgesetzt, dass aktuelle Ortsdaten des zu überwachenden Objektes mittels eines GNSS über eine sogenannte „GPS-Fix-Anfrage“ durch das Smartphone abrufbar bzw. erzeugbar sind. Insbesondere wird dabei vorausgesetzt, dass die Überwachung des zu überwachenden Smartphones, zusätzlich zu einer relativ viel Energie verbrauchenden, auf GNSS-Daten basierenden und auf einem höheren Level im Betriebssystem, z.B. einem Anwendungsprogramm oder einer App, des mobilen Gerätes bzw. Smartphones ablaufenden algorithmischen Berechnung auch mittels einer an sich bekannten hardwarenahen, relativ wenig Energie verbrauchenden Lokalisierungsschätzung durchführbar ist. Denn mittels einer hardwarenahen Lokalisierungsschätzung kann die Überwachung der Bewegungsintensität sowie der Bewegungsgeschwindigkeit und Bewegungsrichtung des Smartphones durch den hardwarenahen Teil in an sich bekannter Weise sehr energieeffizient ausgeführt werden.
-
Es ist dabei anzumerken, dass das hierin beschriebene Verfahren bevorzugt auf dem jeweiligen mobilen Gerät selbst durchgeführt wird.
-
Bei dem Verfahren werden zunächst in der genannten Weise Ortsdaten des Geofence erzeugt und gespeichert 100 sowie aktuelle Ortsdaten des Smartphones mittels GNSS erzeugt und gespeichert 105. Aus den gespeicherten Ortsdaten des Geofence und des Smartphones werden der momentane Abstand zwischen dem Smartphone und des Geofence sowie die Bewegungsgeschwindigkeit und die Bewegungsrichtung des Smartphones berechnet 110. Aus den so berechneten Daten wird eine Vorhersage getroffen 115, ob das Smartphone den Geofence innerhalb einer z.B. empirisch vorgebbaren Zeitdauer Δtmin durchbrechen wird. Es ist hierbei hervorzuheben, dass das genannte Durchbrechen des Geofence sowohl das mögliche Betreten als auch das mögliche Verlassen der jeweiligen Geozone bedeuten kann.
-
Ist die Bedingung gemäß der Vorhersage 115 nicht erfüllt, d.h. ein Durchbrechen des Geofence durch das Smartphone innerhalb der Zeitdauer Δtmin wird als nicht wahrscheinlich angenommen, dann wird der relativ viel Energie verbrauchende Überwachungsalgorithmus gemäß den Schritten 100 - 115 deaktiviert 120 und innerhalb der Zeitdauer Δtmin die Überwachung des Objektes ausschließlich mittels der energiesparenden Geolokalisierung anhand einer Prüfschleife 125 durchgeführt.
-
Ist die Bedingung gemäß der Vorhersage 115 allerdings erfüllt, d.h. ein Durchbrechen des Geofence durch das Smartphone innerhalb der Zeitdauer Δtmin wird als wahrscheinlich angenommen, dann wird wieder zu Schritt 105 zurückgesprungen. Die Überwachung des Smartphones erfolgt dann anhand der relativ viel Energie verbrauchenden, insbesondere auf den GNSS-Daten 105 basierenden algorithmischen Berechnung gemäß den Schritten 100 - 115.
-
Bei der in 1 gezeigten Prüfschleife 125 kann eine geringe Wahrscheinlichkeit, dass in nächster Zeit der betreffende Geofence von dem Smartphone durchbrochen wird, z.B. auf einer oder mehreren der folgenden vier (verschiedenen) Annahmen bzw. Bedingungen beruhend festgestellt werden:
- 1) Es wird kein GPS-Fix innerhalb eines vorgegebenen Timeouts tFix gefunden. Somit befindet sich das Smartphone mit hoher Wahrscheinlichkeit innerhalb eines Gebäudes und bewegt sich nicht auf einen Geofence zu oder von ihm weg.
- 2) Es wird keine Bewegung des Smartphones detektiert. Wenn sich das Smartphone überhaupt nicht bewegt, so kann es sich auch nicht fortbewegen.
- 3) Es wird zwar Bewegung des Smartphones erkannt, aber über eine aus der ermittelten Geschwindigkeit und Entfernung zum nächsten Geofence berechnete erwartete Ankunftszeit TTA (Time To Arrival, unabhängig von der Bewegungsrichtung!) kann der Geofence bei gleichbleibender Geschwindigkeit nicht unter einer entsprechend festgelegten Zeit ttaThreshold erreicht werden.
- 4) Es wird eine Bewegung des Smartphones erfasst und durch die dabei ermittelte Geschwindigkeit und Entfernung zum nächsten Geofence kann dieser Geofence innerhalb einer festgelegten Zeit ttaThreshold erreicht werden. Jedoch bewegt sich das Smartphone nicht innerhalb eines Winkels angularThreshold auf den Geofence zu und nähert sich somit nicht ausreichend schnell dem Geofence an.
-
Sobald die genannte, hardwarenahe Lokalisierungsschätzung bzw. Geolokalisierung die Vermutung nahe legt, dass sich das Smartphone auf einen Geofence zu bewegt, wird der genannte Überwachungsalgorithmus wieder aktiviert bzw. aufgeweckt und es wird versucht, eine zuverlässigere Lokalisierung des Smartphones zu bekommen bzw. eine Plausibilisierung durchzuführen. Im Folgenden werden drei verschiedene Möglichkeiten erläutert, welche zu dieser Vermutung führen können:
- 1) Die hardwarenahe Implementierung des StepCounters zählt stepsMax Schritte (siehe 2a und 2b).
- 2) Es wird eine große Geschwindigkeitsänderung erkannt, beispielsweise durch Tiefpassfilterung der nur roh vorliegenden Beschleunigungswerte. Daraus ergibt sich, dass die berechnete TTA nicht mehr gültig ist und folglich mittels des Algorithmus neu berechnet werden muss (siehe 2a und 2b).
- 3) Ein Timer mit der Dauer TTA*k läuft ab. Dies stellt eine „Fallbacklösung“ dar, falls nicht in angemessener Zeit (TTA*k) genügend Schritte oder eine große Geschwindigkeitsänderung erkannt werden. Um nicht permanent in dieser Fallbacklösung zu landen und dadurch zu häufig den Algorithmus zu reaktivieren, wird bei jedem Durchlauf über diesen Pfad ein Faktor k (initialisiert z.B. mit klnit = 0,5) um einen Faktor kGrow (z.B. 1,1) vergrößert. Sobald entweder genügend Schritte (Fall 1) oder eine große Geschwindigkeitsänderung (Fall 2) erkannt werden, so wird der Faktor k wieder auf den initialen Wert klnit zurückgesetzt (siehe 2a und 2b).
-
Wird also durch eine dieser drei Möglichkeiten festgestellt, dass die aktuelle Position des Smartphones neu ermittelt werden muss, so wird wieder ein GPS-Fix angefragt und die in 1 gezeigte Routine beginnt von Neuem.
-
Optional kann vorgesehen sein, dass nachdem von der hardwarenahen Lokalisierungsschätzung die Entscheidung getroffen wird, die sogenannte App-Komponente (siehe Beschreibung zu 2) zu wecken, die aktuelle Position des Objektes von der eingangs genannten Kurzzeitlokalisation (PDR) übernommen bzw. kopiert wird, anstatt diese mittels GNSS ermitteln bzw bestimmen zu müssen. Dieser Verfahrensschritt erfolgt ebenfalls mittels eines eingangs genannten Signalprozessors (DSP) und somit sehr energiesparend. Wird diese Position als ungenau zurückgegeben, so kann der beschriebene Ansatz (d.h. ohne PDR) beschritten und eine neue Position mittels GNSS ermittelt werden. Liefert das PDR jedoch eine ausreichend genaue Position des Smartphones, dann wird die Anfrage nach einem neuen GPS-Fix übersprungen und es wird direkt mit der neuen Position des PDR eine Time To Arrival (TTA) berechnet.
-
Der beschriebene Überwachungsalgorithmus wird nachfolgend als auf dem Smartphone eingerichtete App bzw. eine entsprechende App-Komponente angenommen. In 2a sind dabei die auf der App-Komponente ablaufenden Verfahrensschritte und in 2b die auf Seiten der hardwarenahen Lokalisierungsschätzung ablaufenden Verfahrensschritte dargestellt.
-
Nach dem Start 200 der In 2a gezeigten Routine wird zunächst ein erster GPS-Fix angefordert und dieser abgewartet 205. In Schritt 210 wird abgewartet, bis eine empirisch vorgebbare Wartezeit tlnit abgelaufen ist und nach Ablauf dieser Wartezeit in Schritt 215 die Konstante k = klnit gesetzt.
-
Danach beginnt mit Schritt 220 die eigentliche Überwachungsroutine, in dem ein aktueller GPS-Fix angefordert wird. In Schritt 225 wird geprüft, ob innerhalb eines empirisch vorgebbaren „timeout“-Intervalls tFix ein GPS-Fix erhalten wurde. Ist diese Bedingung erfüllt, wird mit Schritt 230 weiterverfahren, in dem ein Wert für die bereits genannte Dauer TTA berechnet wird. Die Dauer TTA wird als aus dem Abstand zum nächstgelegenen Punkt des Geofence (bzw. einem auf einer entsprechenden Grenzlinie der jeweils betrachteten Geozone liegender Punkt) zur Momentangeschwindigkeit des Smartphones gebildeter Quotient berechnet, und schließlich gemäß der Beziehung TTA = min (ttaMax, TTA) nach oben auf den Wert von ,ttaMax‘ begrenzt. Danach wird geprüft 235, ob der betrachtete Geofence von dem Smartphone bereits passiert bzw. durchbrochen wurde. Ist diese Bedingung erfüllt, dann wird mit Schritt 240 weiterverfahren, in dem ermittelt wird, ob die Geozone verlassen oder betreten wurde. Danach wird zu Schritt 220 zurückgesprungen und erneut ein aktueller GPS-Fix angefordert.
-
Ist die Bedingung gemäß Prüfschritt 235 nicht erfüllt, dann wird in einem weiteren Prüfschritt 250 geprüft, ob eine Bewegung des Smartphones erkannt wurde. Ist dies nicht der Fall, dann wird die Überwachungsroutine deaktiviert bzw. in einen Schlafmodus gesetzt 245. Ist diese Bedingung jedoch erfüllt, dann wird in Schritt 255 geprüft, ob die berechnete Dauer TTA kleiner als ein empirisch vorgebbarer Schwellenwert ttaThreshold ist. Dabei wird näherungsweise angenommen, dass das Smartphone mit einer konstanten Geschwindigkeit bewegt wird. Ist dies nicht der Fall, dann wird die Überwachungsroutine deaktiviert 245. Ist dies jedoch der Fall, dann wird in Schritt 260 geprüft, ob sich das Smartphone nicht innerhalb eines Winkels angularThreshold auf den vorliegend betrachteten Geofence zubewegt und sich somit vom Geofence entfernt. Dadurch kann der Geofence, trotz der Momentangeschwindigkeit des Smartphones bzw. des das Smartphone tragenden Nutzers, wegen der Bewegungsrichtung überhaupt nicht innerhalb der Dauer TTA erreicht werden. Ist dies nicht der Fall, dann wird die Überwachungsroutine deaktiviert. Andernfalls wird an den Anfang der Routine zu Schritt 220 zurückgesprungen.
-
Ist bereits die Bedingung gemäß dem Prüfschritt 225 nicht erfüllt, dann wird mit Schritt 227 weiterverfahren, in dem die Dauer TTA = ttaMax gesetzt wird. Danach wird die Überwachungsroutine deaktiviert 245.
-
Die in 2b gezeigte, hardwarenahe Geolokalisierungsroutine wird erst durch das Deaktivieren 245 der Überwachungsroutine gestartet. Dabei wird ja angenommen, dass der Geofence von dem Smartphone bzw. dem Nutzer nicht zeitnah erreicht werden kann. In Schritt 300 werden zunächst ein Schrittzähler (step counter) sowie ein Zeitgeber (timer) zurückgesetzt bzw. initialisiert. Im nachfolgenden Prüfschritt 305 wird solange gewartet, bis ein für die hardwarenahe Geolokalisierung bzw. Lokalisierungsschätzung vorliegend eingesetzter virtueller Sensor, z.B. ein zur Kurzzeitlokalisation von Personen (PDR) vorgesehener Digital Signal Prozessor (DSP), reaktiviert bzw. aus einem Schlafmodus aufgeweckt wurde. Nachdem diese Bedingung erfüllt ist, wird mit den nachfolgenden, parallel ausgeführten Schritten 310, 315, 320 weiterverfahren.
-
In Schritt 310 wird solange gewartet, bis der genannte Schrittzähler einen empirisch vorgebbaren Wert stepsMax erreicht. Ist dies der Fall, wird in Schritt 335 der genannte Faktor k = klnit gesetzt. Danach wird in Schritt 330 die Position des Smartphones anhand des virtuellen Sensors erneut überprüft. Ergibt diese Prüfung eine erhebliche Änderung der Position, dann wird die in 2a dargestellte Überwachungsroutine reaktiviert bzw. aus ihrem Schlafmodus aufweckt 355 und zu dem in 2a gezeigten Schritt 220 gesprungen.
-
In dem zu Schritt 310 parallel ausgeführten Schritt 315 wird mittels des virtuellen Sensors geprüft, ob das Smartphone einer erheblichen Geschwindigkeitsänderung seiner Bewegung unterliegt. Denn eine solche Änderung erfordert eine Neuberechnung der Dauer TTA. Daher wird in Schritt 340 wiederum k = klnit gesetzt und in Schritt 330 die Position des Smartphones mittels des virtuellen Sensors erneut überprüft. Auch hier wird bei einer erfassten erheblichen Änderung der Position des Smartphones die in 2a dargestellte Überwachungsroutine reaktiviert 355 und zu dem in 2a gezeigten Schritt 220 gesprungen.
-
In dem ebenfalls zu Schritt 310 parallel ausgeführten Prüfschritt 320 wird geprüft, ob die seit dem in Schritt 300 durchgeführten Zurücksetzen des genannten Schrittzählers vergangene Zeit größer als TTA * k ist. Ist dies der Fall, wird in Schritt 325 der Faktor k = min (kGrow * k, kMax) gesetzt. Anschließend wird wiederum mittels des virtuellen Sensors die momentane Position des Smartphones geprüft 330 und entsprechend mit dem beschriebenen Schritt 355 weiterverfahren.
-
Wie in 2b durch gestrichelte Linien angedeutet, kann optional vorgesehen sein, dass anstelle des einzelnen Schritts 355 die Schritte 345 - 360 ausgeführt werden. Dabei wird in Schritt 345 die aktuelle Position des Smartphones durch Anforderung einer von einem genannten DSP (PDR) bereitgestellten PDRlocation ermittelt. In Schritt 350 wird dann geprüft, ob der bereitgestellte Wert der PDRlocation gültig ist. Falls der Wert nicht gültig ist und damit verwertbar ist, wird mit Schritt 355 weiterverfahren. Andernfalls wird in Schritt 360 die Überwachungsroutine reaktiviert und der momentan vorliegende Positionswert für das Smartphone bzw. für den Nutzer als aktueller Wert für die Größe PDRlocation gesetzt. Danach wird zu Schritt 230 der Überwachungsroutine gesprungen.
