Blog

Dass wir für Bikesharing, wie unserem selbstgebauten OpenBike, auf GBFS - der internationalen General Bikeshare Feed Specification - setzen ist vielleicht bekannt. Aber was genau ist IXSI jetzt? Das Interface for X-Sharing Information, kurz IXSI, ist ein mit Fördermitteln unter anderem an der RWTH Aachen entstandener Standard zum Austausch zwischen Sharingdiensten und Auskunftsdiensten und wird hauptsächlich von der deutschen Carsharing-Industrie benutzt um Daten zwischen den einzelnen Carsharern austauschen zu können.

Im Rahmen der Mobilitätsstation am Eselsberg fordern wir von den Anbietern, welche dort Mobilitätsdienste anbieten wollen (und zukünftig auch für alle Mobilitätsanbieter, die in der gesamten Stadt anbieten wollen) die Bereitstellung von offenen Daten zur Verfügbarkeit der Angebote.

Für Bikesharing und Scootersharing fordern wir bereits in unserer Kooperationsvereinbarung [PDF] GBFS. Zwar wurde GBFS ursprünglich für Bikesharing entwickelt, aber es stellt sich schnell raus, dass sich die Auskunft von Bikesharing und anderen Verkehrsmitteln wie Leihautos gar nicht so stark unterscheidet. Zudem sind bereits für die zukünftige GBFS-Version 3.0 Erweiterungen für Carsharing und eine Umbenennung zu weniger »Bike«, mehr »Vehicle« geplant. Daher eignet sich GBFS aus unserer Sicht bereits jetzt dazu, auch offene Daten zu Carsharing auszuliefern.

Offene Daten im Carsharingmarkt sind wichtig - und leider zurzeit immer noch sehr rar. Die technischen Dienstleister der Carsharer und vorallem der Bundesverband Carsharing befinden sich, wie vor ein paar Jahren auch die meisten Verkehrsverbünde, noch im Glauben, dass offene Daten sie ins Verderben stürzen und ihre Geschäftsmodelle daran zerbrechen würden. Eine stichhaltige Begründung für diese Sorge konnte uns bis heute niemand liefern und wir glauben sogar, dass das Gegenteil der Fall ist: Um so mehr Menschen von einem verfügbaren Mobilitätsangebot wissen, um so mehr sind bereit es zu nutzen. Offene Daten könen genau für diese Sichtbarkeit der Angebote in Karten und Mobilitätsapps sorgen. Um so verbreiteter der Standard der Daten, um so einfacher ist es, diese Daten in vorhandene Anwendungen zu integrieren. Genau deswegen setzen wir hier auf das interantional verbreitete GBFS. Aber auch Prototypen und Nischenanwendungen profitieren hier von Open Data und verbreiteten Standards, da so auf vorhandene Programmierbibliotheken gesetzt werden kann oder Lösungen aus anderen Städten in neue Regionen übertragen werden können ohne dass diese aufwendig neu entwickelt werden müssen.¹

Und am Ende sitzt die Kundin dann sowieso im Fahrzeug des Anbieters - von einem vielbeschworenen drohenen »Verlust des Kundenkontakts« kann also wirklich nicht die Rede sein.

Die Software der in Ulm ansässigen Carsharing-Anbieter unterstützt leider noch kein GBFS, und der Softwareanbieter war nicht bereit, selbst GBFS zu implementieren. Um die Bereitstellung von GBFS als Open Data trotzdem zu ermöglichen, haben wir uns dann also darauf geeinigt, dass uns die vorhandene IXSI-Schnittstelle bereitgestellt wird. Auf deren Basis entwickelten wir dann eine Software, welche die IXSI-Daten regelmäßig abfragt, nach GBFS konvertiert und öffentlich zugänglich macht.

Das Ergebnis sind nun zwei GBFS-Endpunkte für die beiden Carsharing-Anbieter, welche ihre Leihautos an der Mobilitätsstation anbieten. Die SWU stellt darüber hinaus die Daten für alle ihre Carsharing-Stationen bereit, der Anbieter Conficars leider nur für die Station am Eselsberg.

Die GBFS-Endpunkte sind unter den folgenden URLs abrufbar:

• Conficars: https://gbfs.conficars.de/gbfs.json
• SWU2go: https://ixsi.swu.de/gbfs.json

Den Sourcecode des IXSI-GBFS-Converters stellen wir natürlich auch als OpenSource Software unter der freien MIT-Lizenz auf https://github.com/stadtulm/ixsi-gbfs-converter zur Verfügung. Ein Einsatz des IXSI-GBFS-Converters ist entweder direkt als node.js-Anwendung aus dem Sourcecode oder mit den vorbereiteten Docker-Images unter https://hub.docker.com/r/stadtulm/ixsi-gbfs-converter möglich.

Wir freuen uns auch über gemeinsame Weiterentwicklung des Adapters. Vorallem bei der aktuellen Entwicklungsgeschwindigkeit des GBFS-Standards werden sicher weitere Datenfelder auftauchen, die aus IXSI-Daten befüllt werden können. Aktuell fehlen auch noch die mit GBFS 2.1 eingeführten vehicle types. Zudem ist der Adapter aktuell nur für Stationsbasierte Systeme implementiert - mangels Free-Floating-Carsharer in Ulm. Falls also eine IXSI-Schnittstelle mit Freefloatern auftaucht, freuen wir uns besonders über Pull-Requests, die diese auch implementieren.

Außerdem würden wir uns freuen, wenn weitere Kommunen diesem Beispiel folgen und offene Mobilitätsdaten von den Anbietern einfordern und als Vorraussetzung für den Betrieb von Sharingdiensten machen. Eine Policy-Anleitung hat MobilityData in den letzten Tagen veröffentlicht, die technischen Vorraussetzungen sind nun mit dem Adapter geschaffen - auch wenn wir hoffen, dass die technischen Dienstleister der Carsharer doch noch einlenken und GBFS direkt in ihre Software einbauen. Bis dahin kann der Adapter auch von den Carsharinganbietern betrieben werden.

Wenn ihr eine Software entwickelt oder betreut, die mit GBFS umgehen kann, integriert doch gern die Daten. Dies hilft auch mehr Bürger*innen und Entscheider*innen zu zeigen, was man mit den Daten alles machen kann - und den Anbietern, dass das alles gar nicht weh tut.

Und natürlich freuen wir uns, wenn ihr dieses Beispiel nutzt um in eurer Kommune offene Mobilitätsdaten anzusprechen.

Neben den Wifi-Trackern benutzen wir als GPS-Tracker hauptsächlich die LoRaWAN GPS-Tracker Dragino LGT 92 in der Ausführung mit eingebautem Akku. Zwar testen wir auch andere Trackermodelle, möchten aber in diesem Artikel kurz beschreiben, wie wir die Tracker konfiguriert haben. Der Vorteil dieser Tracker ist, dass sie als fertiges Produkt gekauft werden können, aber trotzdem komplett Open Hardware sind und die Firmware als Freie/Open-Source-Software veröffentlicht wird. Die Annahme von Bugfixes auf GitHub scheint aber noch nicht so gut zu funktionieren. Der große Vorteil, dass man die Firmware selber anpassen und auch Firmwareupdates selbstständig einspielen kann, bleibt natürlich bestehen. Und das ist bei solchen Geräten nicht selbstverständlich, wie wir bei Experimenten mit Trackern anderer Hersteller schmerzlich feststellen mussten.

Wir möchten in diesem Artikel festhalten wie wir unsere Tracker konfiguriert haben. Die Konfiguration findet, wie in der Anleitung ab Seite 20 beschrieben mit AT-Kommandos über die serielle Konsole statt.

Eine Liste aller AT-Kommandos findet sich in der AT-Anleitung des Herstellers. Hier solltet ihr überprüfen ob die Firmware auf dem Stand der Dokumentation ist, und diese im zweifel aktualisieren.

Akkulaufzeit optimieren

Da GPS sehr stromhungrig ist, bieten die Tracker eine Reihe von Konfigurationsmöglichkeiten um für verschiedene Anwendungsfälle die bestmögliche Laufzeit herauszuholen. Wichtigster Punkt: Wie oft wird der GPS-Chip gestartet um die Position zu erfassen.

Das Gute an den Dragino-Trackern ist, dass diese einen Beschleunigungssensor eingebaut haben und ab Firmwareversion 1.5 lässt der Tracker so konfigurieren, dass dieser uns beim Stromsparen sehr hilft: Unsere Räder stehen die meiste Zeit des Tages ja an einem Fahrradständer. Solange sie stehen brauchen wir keine regelmäßigen Positionsupdates im System. (Vielleicht alle paar Stunden mal, um sicher zu gehen, dass das Rad noch dort steht und kein Lora-Paket zwischendurch verloren gegangen ist.) Mit dem Beschleunigungssensor kann der Tracker erfassen, wann das Rad bewegt wird, und dann anfangen seine Position häufiger zu senden.

Mit AT+TDC kann man konfigurieren, in welchem Intervall in Millisekunden der Tracker seine Position sendet, wenn er bewegt wird. Und mit AT+KAT den Abstand zwischen Aussendungen in Millisekunden, solange keine Bewegung registriert wurde. Momentan nutzen wir die Werte AT+TDC=90000 und AT+KAT=1800000. AT+KAT ist bei uns mit 30 Minuten sehr gering eingestellt, da wir das Feature mit der neuen Firmware erst einmal testen wollten. Wahrscheinlich ist es aber sinnvoll, diesen Wert auf drei Stunden erhöhen. AT+TDC ist bei uns mit 90 Sekunden auch relativ gering, weil wir überlegen in Zukunft MDS-Daten zu generieren.

Ein Zweiter, für die Akkulaufzeit relevanter Faktor ist, wie lange der GPS-Chip versucht, eine Position zu ermitteln. Sucht dieser nicht lang genug nach Satelliten, ist die Genauigkeit der Position möglicherweise sehr schlecht. Stehen Fahrzeuge öfter unter Brücken, unter Dächern oder an sonstigen Orten mit schlechtem GPS-Empfang, verbraucht der GPS-Chip bei zu langer erfolgloser Suche sehr viel Strom. Diese Zeit lässt sich mit AT+FTIME konfigurieren. (Wert in Sekunden, in unserem Fall AT+FTIME=180) Damit im Zusammenhang steht auch die konfigurierbare Mindestgenauigkeit. Das heißt, wir können konfigurieren, ab welcher Genauigkeit sich der Tracker mit der Position zufrieden gibt und diese sendet. Da der Empfänger für eine genauere Position länger braucht und damit mehr Strom verbraucht, müssen wir hier also ein gutes Verhältnis zwischen Genauigkeit und Akkulaufzeit finden. Dies kann sich je nach Anwendungsfall unterscheiden. Nach unserer Erfahrung ist die vorkonfigurierte Genauigkeit von AT+PDOP=3.00 teilweise erschreckend ungenau. Unsere Tracker sind mit AT+PDOP=2.00 konfiguriert. Bei DOP handelt es sich nicht um eine Genauigkeit in Metern, sondern um eine dimensionslose Maßzahl für die Streuung der erfassten Positionswerte. Wenn die Genauigkeit AT+PDOP in der Erfassungszeit AT+FTIME nicht erreicht wurde, wird die bis dahin am genausten erfasste Position gesendet. AT+PDOP und AT+FTIME stehen hier also in einer gewissen Abhänigkeit zueinander - wir haben unser Optimum dabei auch noch nicht gefunden.

Ein Problem mit der aktuellen Firmware ist, dass leider die Genauigkeit der GPS-Position nicht mit per Lora übermittelt wird. Andere GPS-Chips in neueren Hardwarerevisionen könnten sich anders verhalten. Wir haben Tracker in der Hardware-Version 1.4 mit dem Quectel L70-RL GPS-Chip. Es gibt wohl auch eine Nachfolgegeneration auf dem ein anderer GPS-Chip verbaut ist.

Reichweitenoptimierungen

Für Orte die nicht so gut mit LoRaWAN abgedeckt sind, gibt es zwei relevante Einstellungen.

Datenrate

Die Datenrate (oder auch Spreading Factor): LoRaWAN-Nodes können ihre Daten in verschiedenen Geschwindigkeiten senden. Um so langsamer die Daten gesendet werden, um so höher ist die Wahrscheinlichkeit, dass das Gateway zwischen vielen Störfaktoren das gesendete Signal noch herausfiltern kann. Dementsprechend steigt mit niedrigerer Datenrate (höherem Spreadingfactor) also auch in der Regel die Reichweite des Signals. Allerdings ist dabei zu beachten, dass wir uns das Übertragungsmedium mit allen anderen LoRa-Geräten und noch vielen anderen Sendern teilen, die diese offene Frequenz benutzen. Das heißt, um so länger wir senden, um so länger beeinträchtigen wir die Frequenz für alle anderen Teilnehmenden. Neben den rechtlichen Regelungen, die aus diesem Grund die Bundesnetzagentur getroffen hat, gibt es auch noch restriktivere Beschränkungen, die sich die TTN-Community selbst auferlegt hat. Das soll dafür sorgen, möglichst vielen Geräten die Teilnahme am Netzwerk zu ermöglichen. In der Praxis bedeutet dies: Es gibt einen Richtwert, wie lange jedes Gerät pro Tag maximal senden sollte. Wie viele Daten das sind, wie oft ein GPS-Tracker also seine Daten übermitteln kann, hängt dementsprechend auch mit der Datenrate zusammen.

Um auszurechnen, wie häufig der Dragino-Tracker bei welcher Datenrate senden darf, gibt es diesen großartigen Rechner: https://avbentem.github.io/airtime-calculator/ttn/eu868. Hier sehen wir, dass die Tracker bei einer Payload-Größe von 21 Byte und der voreingestellten Datenrate (DR5 / SF7) 16 mal pro Stunde, also etwa alle 4 Minuten, ihre Position senden könnten. Damit stoßen wir an keine realen Grenzen, denn schon allein aus Akkulaufzeitgründen ist es nicht sinnvoll dauerhaft so oft die Position zu übermitteln. Selbst bei der niedrigsten festeinstellbaren Datenrate (DR2/SF10) dürfen wir noch mehr als zwei Geolocations pro Stunde senden, was in gut ausgelasteten System in denen die Räder mehrere Fahrten pro Tag machen noch deutlich ausreicht, da die Fahrräder sich ja trotzdem die meiste Zeit nicht bewegen.

Mit dem AT-Kommando AT+DR=4 kann man somit die Datenrate auf 4 setzen, was dem Spreadingfaktor 8 entspricht. DR1 und DR2 dürfen nur benutzt werden, wenn ADR (Adaptive Data Rate) aktiviert ist, was in unserem Anwendungsfall eher wenig praktikabel ist.

Single Channel Gateways

LoRaWAN benutzt im Normalfall 8 Unterfreuqenzen (Channels/Kanäle). Dies dient dazu das geteilte Frequenzband besser auszunutzen. Das heißt auch, dass standardkonforme Gateways auch gleichzeitig auf alle 8 Kanäle hören sollten, um alle gesendeten Nachrichten empfangen zu können. Die Clients wählen sich zufällig einen Kanal, um das Band möglichst gleichmäßig auszunutzen.

Solche vollwertige Gateways sind nicht für alle einfach erschwinglich, auch wenn der Preis für manche Geräte mittlerweile auf unter 100€ gefallen ist. Deswegen existieren Bauanleitungen für Selbstbau-Gateways, die nur auf einem Kanal empfangen und senden. An Orten ohne systematisch aufgebaute TTN-Infrastruktur sind dies womöglich die ersten und einzigen verfügbaren Gateways, oder auch im eigenen Arbeitszimmer für Experimente.
Da diese Gateways im Durchschnitt aber nur jede achte Nachricht überhaupt empfangen, kann der Effekt solch eines Single-Channel-Gateways erst mal sehr enttäuschend sein. Um temporär Abhilfe zu schaffen, können die Dragino-Tracker in den Single-Channel-Mode versetzt werden. Wenn man die eingesetzte Frequenz des Single-Channel-Gateways kennt, kann der Tracker dann mit z.B. AT+CHS=868100000 auf diese Frequenz festgesetzt werden. Das Problem ist, dass dadurch die vorhin angesprochene gleichmäßige Verteilung von Aussendungen auf alle Channels unterwandert wird. Deswegen sollte der Tracker wieder in den Multi-Channel-Mode gesetzt werden (AT+CHS=0), sobald er in einem „richtigen“ TTN-Netz mit ausreichend vielen standardkonformen Gateways eingesetzt wird.

In den letzten Wochen haben wir uns immer wieder Gedanken über die Rückgabe von Fahrrädern gemacht. Das ist ein Themengebiet, das erstmal recht einfach erscheint, wir durch den Bikesharing-Betrieb aber schon einiges gelernt haben und jetzt mehr spannende Fragen sehen als vorher.

Momentan ist es so, dass unsere Räder kostenlos ausgeliehen werden können. Wir beschränken dabei auch die Länge der Ausleihe/Fahrt nicht. Bei kommerziellen Anbietern gibt es meist den Anreiz möglichst kurz zu fahren (weil z.B. die ersten 30 Minuten kostenfrei sind), oder bei Nichtbenutzung die Leihe auch schnellstmöglich wieder zu beenden, da minütlich abgerechnet wird. Bei unserer kostenfreien Ausleihe bestehen diese Anreize zurzeit nicht - was dazu führt, dass wir immer wieder mehrere stunden- bis tagelange Ausleihen gesehen haben, ohne dass sich das Rad bewegt hat. Leute haben also vergessen, die Ausleihe des Rads zu beenden und somit anderen wieder zur Verfügung zu stellen.

Am naheliegensten wäre nun bei Ausleihen, die deutlich länger als die Durchschnittsausleihe dauern, die ausleihende Person zu benachrichtigen und zu erinnern, bei Nichtbenutzung das Rad auch wieder zurückzugeben. Unsere Oberfläche ist aber aktuell eine Webapp. Diese können nur unter Android überhaupt (Web-)Push-Nachrichten auslösen, unter iOS ist dies aktuell gar nicht möglich.

Eine weitere Möglichkeit Nutzerïnnen über noch offene Leihen zu informieren, wären bereits bestehende Kanäle wie E-Mail, SMS oder diverse Messenger. Da wir in cykel aber keine Registrierung und Login selbst anbieten, sondern dies über externe Dienste per oAuth2 abbilden, bekommen wir diese Kontaktmöglichkeiten nur in seltensten Fällen. Zudem werfen wir diese Daten - falls doch übermittelt - sogar aktiv weg. Dies hilft uns dabei, möglichst datensparsam mit persönlichen Daten umzugehen, denn eine wunderbare Möglichkeit für Datenschutz ist es, wenn man Daten gar nicht erst erfasst.

Nun stellt sich jedoch die Frage, ob wir diese Prinzipien über Bord werfen müssten, um über vergessene Rückgaben informieren zu können. Zudem würden uns mehr personenbezogene Daten nur noch mehr Probleme bereiten, wenn wir das zukünftig angedachte Roaming zwischen verschiedenen OpenBike-Instanzen einbauen. In dem Fall müssten diese personenbezogenen Kontaktdaten dann mitwandern.

Wir suchen also einen Weg, Benutzerïnnen Nachrichten zukommen zu lassen, ohne dass wir zwingenderweise einen Bezug zwischen einer Ausleihe, der Nachricht, dem Nachrichtenweg und der Person haben müssen.

Momentan benutzt die Kernkomponente von OpenBike zur Authentifizierung oAuth2. Einige Dienste, mit denen eine oAuth2-Authentifizierung möglich ist, bieten selbst auch eine Messenging-Funktion (wie z.B. Twitter mit Direktnachrichten), mit der wir benachrichtigen könnten. Aber nicht alle Dienste bieten das an und zudem gibt es bei den einzelnen Diensten dafür auch keine einheitliche Schnittstelle. Dies ist aber auch gar nicht das Ziel von oAuth2 - dieser (und verwandte) Standards wie OpenID Connect sind ja eigentlich für die Absicherung von Schnittstellen gedacht.

Noch dazu besitzen viele Menschen ja bereits eine Menge an Möglichkeiten, über die sie erreichbar wären - neben klassisch E-Mail und SMS kämen da noch diverse Messenger, Soziale Netzwerke und andere Dienste in Betracht, die vielleicht sogar schon auf den Smartphones installiert sind und Push-Nachrichten ausspielen.

Unsere Idee wäre es nun eine weitere Komponente zu bauen, die zwischen OpenBike und den Authentifizierungsprovidern liegt und sich einerseits um die Abwicklung der Authentifizierung mit verschiedenen Providern und andererseits um das Weiterleiten von Nachrichten über diese kümmert. Diese Komponente sollte also können:

• selbst oAuth Provider sein
• mehrere andere oAuth Provider für den Login unterstützen
• für die Provider die es anbieten, Messaging unterstützen
• für alle anderen die Hinterlegung einer E-Mail-Adresse oder Handynummer (für SMS) ermöglichen
• der Benutzer:in wählen lassen, über welchen Weg sie kontaktiert werden will
• die Zurordnung zu einer Mailadresse, Handynummer oder Loginprovider aufheben können (für E-Mail-Addresswechsel, neue Handynummer, oder gesperrtem/neuen Account bei einem Provider)
• selbst eine Schnittstelle für Benachrichtigungen anbieten

Damit schaffen wir zwar wieder ein zentrales System, das personenbezogene Daten hortet, aber dieses wäre zumindest von den Ausleihvorgängen auf unterschiedlichen OpenBike-Instanzen unabhängig. Das ist auch der Grund, warum wir dies nicht direkt in cykel einbauen möchten - einerseits sollte diese Kommunikationskomplexität mit zig unterschiedlichen Anbietern nicht in die eigentliche Bikesharingsoftware rein, andererseits sollen auch die personenbezogenen Daten möglichst weit weg davon. Nehmen wir einen kollektiven Betrieb von vielen kleinen OpenBike-Instanzen in unterschiedlichen Nachbarschaften und Städten an, würde ein zentraler Service, der sich um dieses Problemfeld kümmert immerhin den Fokus auf Datenschutz und entsprechende Regelungen an dieser einen Stelle bündeln. Trotzdem können natürlich unterschiedliche Instanzen auch ihre eigenen Login/Notificationservices hosten.

Wir sind uns aber auch nach viel drüber grübeln noch nicht ganz sicher, ob das die sinnvollste Variante ist, das Notificationproblem zu lösen. Auch welche Protokolle dort in Betracht kommen könnten - aktuell klingen zumindest oAuth2 und ActivityPub interessant - ist noch offen.

Wir freuen uns daher über weitere Ideen, Anmerkungen oder auch Vorschläge das Ganze komplett anders zu machen. Gerne per Mail an openbike@ulm.dev - oder sogar besser im öffentlichen #transport-bikesharing:matrix.org Matrix-Channel.