Ein Herzstück von circular.bike ist die Software. Warum eigentlich? Ist die überhaupt wichtig? Die fahren doch quasi von selbst – so einfach per Knopfdruck… Spaß beiseite.

Angepeilt ist ein offenes Betriebssystem – wie Linux für PC’s. Klingt simpel. Als wär es schon vorhanden. Aber das ist es nicht. Und weshalb nicht?
Die notwendige Software ist sicher recht schnell bei der Hand, allein…wären da nicht die Herausforderungen der offenen Schnittstellen und der zugänglichen Hardware-Spezifikationen. Erst die öffentliche Verfügbarkeit dieser Infos ermöglichen ein funktionierendes Zusammenspiel von Hard- und Software. Ohne das wiederum ist ein offenes Betriebssystem leider flügellahm. Aber genau daran klemmt’s bei E-Bikes.
Zum besseren Verständnis der Gemengelage steige ich kurz in die Untiefen der E-Bike-Technik hinab.

Die Grundlage: das Bussystem

Quasi jede Hardware-Komponente eines Pedelecsystems ist stromabhängig und/oder kommuniziert via speziellen Programmierungen (Bussystem) mit ihren „Ansprechpartnern“, z.B. Motor oder Batterie. Ein Controller bündelt alle Infos, so dass Fahrwütige nur noch auf den Knopf zu drücken brauchen; und schon ist das gesamte System ihres Rades hochgefahren und startklar. Damit alles unauffällig ineinandergreifen kann und das Fahrzeug on top sogar mit uns Radler:innen „redet“, arbeitet Hard- und Software eng zusammen. 

Beispiel BIOS

Ein Vergleich zwischen E-Bikes und PC’s macht die Sache anschaulicher. Erst durch das Zusammenspiel vieler Komponenten  – oft unterschiedlicher Hersteller – wird ein Rechner zum PC. Die Bauteile melden sich im BIOS an. Das bündelt alle Hardware-Infos, selektiert sie und gibt die geforderten, z.B. verfügbarer Speicherplatz oder Gerätetemperatur, in verständlicher „Sprache“ an das Betriebssystem weiter. Das wiederum baut die Infos so um und ein, dass sich Programme / Apps reibungslos andocken können. Bis dahin managt der Computer alles quasi selbst und bereitet das System für uns – die User:innen – vor; für unseren großen Auftritt: die Nutzung der Programme/Apps.

CAN

Um jetzt so etwas wie ein „Linux für E-Bikes“ entwickeln zu können, braucht es ein Bios-Äquivant, das – anders als BIOS – zusätzlich für die Stromversorgung der Komponenten zuständig ist. Schließlich ist ein Pedelec nicht permanent mit der Steckdose verbunden, sondern soll sich autark bewegen können. In den 80igern entstand für bewegliche Objekte die Idee des CAN-Bus. Der ist inzwischen bei Automotive Standard. Allerdings leider nicht angepasst auf E-Bikes.

Machbar: Closed Source & DIY-Lösungen

Das hat fatale Folgen. Denn so bastelt sich jeder Hersteller seinen CAN-Bus selbst zurecht. Der landet meist gemeinsam mit dem Anforderungskatalog für andockende Komponenten hochgesichert in den Krypten der Firmen. Zugängliche CAN-Busse und Komponenten-Spezifikationen sind eine Rarität. Für die großen, kapitalstarken Hersteller ist die Situation klasse; für kleinere Unternehmen leider weniger. Im Ergebnis leidet die Produktvielfalt.

DIY-Lösungen für quasi selbstgebaute Bikes sind dagegen kein Problem – für Spezialist:innen. Solange sich privat Hardware mit zugänglichem Code (Firmware) auftreiben lässt, bleibt die Sache überschaubar. Simple – oft asiatische – Komponenten mit offenem Quellcode lassen sich via Internet finden. Als halbwegs trainierte:r Hacker- und Frickler:in ist der Einbau und die Programmierung schnell über die Bühne gebracht. Die Komponenten-Garantie verfällt natürlich, sobald man/frau selbst Hand anlegt.

Nicht-Hacker:innen gucken in die Röhre

Darüber hinausgehende Software, die User:innen ohne Programmierungserfahrungen komfortabel nutzen können, bei der vor allem die Garantie erhalten bleibt, die mutiert zur veritablen Herausforderung. Mit ihrer Closed-Source-Politik blockieren die Hersteller den Weg dorthin. Vermutlich ungewollt – unterstützt durch die Hacker:innen-Community. Die hält wegen der obengenannten Alternative Open Source für Zeitverschwendung. Das traurige Ergebnis ist: Ohne offenen CAN und Hardware-Schnittstellen, leider keine brauchbare massentaugliche Software.

EnergyBus  und CANopen

Der EnergyBus will die Engpässe durch verschlossene Schnittstellen und mangelnde Spezifikationen ändern. Seit 2000 haben sich unter seiner Flagge Akteur:innen und Hersteller zusammengeschlossen, die die Standardisierung des Energiemanagements und von Datenübertragungsprotokollen diverser Komponenten vorantreiben. Bosch hat sich leider aus dem Konsortium verabschiedet. Der Konzern präferiert einen Alleingang.
Der Bus arbeitet mit CANopen. Seine Spezifikationen sind zugänglich – aber nicht kostenlos.

Wunschliste für das openBikeOS

Für ein user:innenfreundliches openBikeOS ließe sich der EnergyBus verwenden. Wie ginge es dann weiter? Wie sieht ein Lastenkatalog für die Software aus? Ein paar Ideen dazu:

• robust.
  So wenig oder viel Code wie nötig, clever umgesetzt – als Voraussetzung für geringe Hardware-Belastung und den passenden Energieverbrauch. Als Leitlinie können die Ideen des UBA dienen. Das forscht zu dem Themenkomplex und hat begonnen, eine Zertifizierung für klimaschonende Software zu entwickeln.

• adaptierbar.
  Sie soll ähnlich geplant sein wie ein OS für PC oder Smartphones, d.h. flashbar auf Fahrzeuge mit Komponenten unterschiedlicher Hersteller. Und das bitte nicht nur via Google oder App-Store sondern auch über freie Stores wie F-Droid. Die Rangehensweise von LineageOS oder /e/ können prima Vorbilder sein.

• datensparsam.
  Sinnvoll ist sicher ab Entwicklungsstart zu überlegen, welche Daten unbedingt erforderlich sind, um Prozesse auszuführen und verständliche Infos zur Verfügung zu stellen. Nicht vorhandene Daten benötigen keinen Speicherplatz und können auch nicht zu Werbezwecken weitergegeben werden – eine Binsenweisheit. Da E-Bikes allerdings sehr viele auch persönliche Daten (Pdf) zur Verfügung stellen können, ist sie durchaus interessant im Entwicklungsprozess.
  Datensparsamkeit im Sinne der Klimaschonung. Auch das sollte die Software gewährleisten.

• onboard speichernd.
  So viele Daten wie möglich kann das Fahrzeug direkt onboard speichern. Anders als zur Zeit. Aktuell landen sie auf Servern diverser Hersteller, Dienstleister oder Verwerter – eben „in der Cloud“. Der Overall-Stromverbrauch der Fahrzeuge erhöht sich dadurch je nach Hersteller immens. Da Speichermodule immer leistungsfähiger und kompakter werden, bietet es sich an, vieles erst gar nicht zu verschicken.

Fazit

Die Idee  eines offenen Betriebssystems für Viele, das user:innenorientiert ist und nicht zwangsweise an einen Hersteller bindet, ist ein wichtiger Baustein auf dem Weg in eine digitale Mobilität für uns alle. Nur diese Software ermöglicht – unter den obengenannten Bedingungen – barrierefrei jederzeit Zugang zum Fahrzeug; egal ob arm oder reich, langsam oder schnell. Ein CAN-Bus wie EnergyBus kann gewährleisten, dass unterschiedlichste Komponenten zur Anwendung kommen – allerdings mit Entgegenkommen von Herstellern und evt. auf Druck der User:innen.
Ein Traum? Nicht, wenn sich genug Interessierte finden, die unterstützen und das Projekt vorwärtstreiben. Wir werden sehen…

 

 

Lizenzen: Fotos + Text: CC BY-SA