Hochautomatisiertes Fahren findet auch in der Cloud statt

Vollautonomes Fahren ist in aller Munde. Die einen erwarten mehr Sicherheit im Straßenverkehr. Die anderen haben Angst vor der Autonomie künstlicher Intelligenzen und den ethischen Konsequenzen. Tatsächlich ist das vollautonome Fahren (Stufe 5 des autonomen Fahrens1 ) auf unseren Autobahnen noch Zukunftsmusik. Längst real hingegen sind die immer ausgereifteren Fahrerassistenzsysteme in modernen Fahrzeugen, die das Leben des Fahrers erleichtern und die Sicherheit verbessern sollen. Diese Assistenzsysteme nehmen aktuell die Hürde zur Stufe 3, dem hochautomatisierten Fahren (HAF). Und das findet nicht nur im Fahrzeug statt, sondern auch in der Cloud. Warum das so ist und was das für die Softwareentwicklung bedeutet, lest ihr hier.

Fahrzeugsensordaten reichen für hochautonomes Fahren nicht aus

Heutige Fahrerassistenzfunktionen basieren meist auf der Auswertung der Daten unterschiedlicher Sensoren und Systeme eines Fahrzeugs wie Kamera, Ultraschall, Lidar oder Radar. Diese erkennen jeweils Teilausschnitte der Umgebung und werden zu einem einheitlichen Umfeldmodell zusammengefügt. Dieses Umfeldmodell stellt verschiedenste Informationen zu bewegten Objekten, statischen Hindernissen, Straßenverläufen und mehr bereit. Das „Sichtfeld“ des Fahrzeugs ist auf dieses Umfeld eingeschränkt.

Das allerdings reicht nicht aus, um den Weg zum hochautomatisierten Fahren konsequent weiterzugehen. Vielmehr muss das bisherige Umfeldmodell zur Berechnung und Kontrolle des Fahrwegs deutlich erweitert werden. Dies geschieht mit Informationen, die von außerhalb der Sensorreichweite kommen. Mit ihnen lassen sich die Fahrfunktionen dynamisch verbessern und sogar ganz neue Fahrfunktionen entwickeln. Damit werden IT-Systeme, die sich außerhalb des Fahrzeugs befinden, erstmals Teil fahrdynamischer Fahrzeugfunktionen.

IT-Systeme außerhalb des Fahrzeugs werden Teil der Fahrerassistenzsysteme

Mit den neuen Fahrzeugvarianten vieler Hersteller kommen weitere Fahrzeugfunktionen auf die Straße, die durch IT-Systeme in der Cloud unterstützt und erweitert werden. Das Backend in der Cloud hält zum Beispiel das Kartenmaterial aktuell und liefert dynamische Informationen. Diese Informationen basieren sowohl auf externen Informationsquellen als auch aus aggregierten Sensordaten vieler Fahrzeuge. IT-Systeme im Hintergrund sammeln diese Daten aus unterschiedlichen Quellen, bereiten sie auf und liefern sie wieder an die Fahrzeuge aus.

Ein solches HAF-IT-System ermittelt zunächst, ob die jeweilige Information für ein Fahrzeug relevant ist. Der Standort des Fahrzeugs dient dabei als Basis, und alle im Umkreis dieses Standorts auftretenden Events sind potenziell für ein Fahrzeug relevant. Der Umkreis wird dabei abhängig von der Art des Events festgelegt. Da sich der Standort eines Fahrzeugs bei der Fahrt ständig ändert, ist es essentiell, dass nur die jeweils veränderte Information an das Fahrzeug übertragen wird.

Fahrzeug und HAF-System sind in ständigem Austausch

Das IT System stellt unterschiedliche Informationen über Umfeldbedingungen wie etwa Geschwindigkeitsbegrenzungen, Baustellen oder Ampelphasen zur Verfügung. Diese können als sogenannte Events an die Fahrzeuge übertragen werden. Die Fahrzeuge können sich für eine oder mehrere Eventarten anmelden, so dass sie Benachrichtigungen zu den jeweiligen Events erhalten.

Dabei kann es ganz unterschiedliche Arten von Events geben, an denen die Fahrzeuge beziehungsweise ihre Fahrer interessiert sein können, zum Beispiel Informationen zu variablen, elektronischen Geschwindigkeitsbegrenzungen. Diese können aufgrund von Verkehrsbedingungen, Baustellen oder anderen Gegebenheiten unterschiedliche Werte anzeigen. Eine weitere Eventart sind Warnungen vor gefährlichen Fahrbedingungen wie Glatteis. Solche frühzeitigen Warnungen sollen helfen Unfälle zu vermeiden.

Über Streckenfreigabe-Events kann dem Fahrzeug außerdem mitgeteilt werden, welche Teilabschnitte für autonomes Fahren geeignet sind. Außerdem sind RTTI-Informationen zur aktuellen Verkehrslage möglich sowie Events, die Daten zur Dauer von Ampelphasen übertragen. Mit letzteren ist es prinzipiell möglich, die Geschwindigkeit entsprechend zu ermitteln, um bei der nächsten Ampel bei grün anzukommen.

Ein IT-System für HAF bildet die die Grundlage für eine übergreifende Plattform, die weitere digitale Services in den Bereichen Gefahrenwarnung, Navigation, Verkehrsinformationen und Parken ermöglicht. Dabei gilt auch hier, dass die Automobilhersteller erst einen Teil dieser Eventarten umgesetzt haben und vieles noch Zukunftsmusik ist.

Ein agiler cloudbasierter Ansatz ist Erfolgsfaktor für HAF-Systeme

Damit das hochautomatisierte Fahren mit Unterstützung eines IT-Systems im Hintergrund zuverlässig funktioniert und auch in Zukunft erweitert werden kann, sind die Anforderungen an die entwickelte Backend-Software hoch. Ausfallsicherheit und Performanz sind genauso sicherzustellen, wie die Skalierbarkeit für zukünftige Erweiterungen.

Zusammen mit Kunden und Partnern entwickelt doubleSlash HAF-Backendsysteme, die Informationen sammeln, auswerten und die daraus berechneten dynamischen Informationen an die Fahrzeugflotte verteilen. Bei der Entwicklung haben unsere Experten folgende Erfolgsfaktoren identifiziert:

Cloudbasierter Ansatz und Microservice Architektur

Das technologische Fundament einer HAF-Anwendung stellt die Kunden-Cloud dar. Die cloudbasierte Anwendung dient dazu, die Hochverfügbarkeit des Systems in allen Regionen zu garantieren und eine stetig wachsende Fahrzeugflotte bedienen zu können.

Das IT-System basiert auf einer flexiblen Microservice-Architektur mit fachlich getrennten, unabhängigen Services. Für Monitoring und Logging werden aktuelle Cloud-Technologien eingesetzt.

SAFe – agile Zusammenarbeit im großen Stil

Ein agiles Vorgehensmodell macht flexible Reaktionen auf Veränderungen möglich. Da das Projekt in einem größeren Gesamtkontext mit verschiedenen IT-Systemen im Bereich automatisiertes Fahren zu sehen ist, bietet sich hier das Modell SAFe („Scaled Agile Framework“) an.

Das agile Manifest ist die Grundlage für SAFe, daraus werden – wie für Scrum – die SAFe Prinzipien abgeleitet. SAFe geht jedoch noch einen Schritt weiter, denn das Rahmenwerk ist zur Koordination mehrerer agiler Teams und Projekte gedacht. Diese Scrum Teams arbeiten auf ein gemeinsames Ziel hin, ihre Projekte sind Teil eines größeren Produkts. Durch den Zusammenschluss der einzelnen Teams lassen sich Abhängigkeiten identifizieren und Redundanzen vermeiden. Ihre Sprints haben einen gemeinsamen Takt, und die Ergebnisse der einzelnen Teams werden durch eine übergreifende Planung auf der Program Increment Ebene aufeinander abgestimmt.2

 

Fazit

Für hochautomatisiertes Fahren (HAF) werden zahlreiche Informationen außerhalb der Sensorreichweite eines Fahrzeuges benötigt, damit das Fahrerassistenzsystem lernen kann. Dafür liefern IT-Systeme außerhalb des Fahrzeuges aufbereitete dynamische Informationen auf Basis unterschiedlichster Informationsquellen. Für solche Systeme gelten besonders hohe Anforderungen an Themen wie Performanz, Ausfallsicherheit und Skalierbarkeit. Um dies zu gewährleisten, setzen wir auf aktuelle Cloud-Technologien und ein agiles, aber skalierbares Vorgehensmodell. Mit letzterem lässt sich schnell und flexibel auf Veränderungen reagieren – ohne jedoch Abhängigkeiten zu anderen Projekten im Gesamtkontext außer Acht zu lassen.

 

Beispiel: Technolgy Stack auf Basis Amazon Webservices
Amazon Web Services (AWS)

  • Amazon Elastic Compute Cloud (EC2)
  • Amazon Elastic Kubernetes Service (EKS)
  • Amazon Relational Database Service (RDS)
  • Amazon Virtual Private Cloud (VPC)
  • AWS Security Groups
  • Amazon CloudWatch
  • Amazon Route 53
  • AWS Lambda
Kubernetes
Docker
Terraform
Grafana
Kibana
Agile Toolchain
Atlassian Confluence, Jira, Bitbucket
Gitlab
Mehr zum Technology Stack erfährst du hier

 

Mehr zum Thema autonomes Fahren:

Von Driver-Only bis Roboter-Taxi – die Herausforderungen beim automatisierten Fahren


Quellen:

1 https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/fahrerassistenzsysteme/

2 https://www.scaledagileframework.com/

Vendor Lock-In in der Cloud richtig erkennen

Besitzen Sie mehrere Apple-Produkte? Dann können Sie nicht einfach auf ein Samsung Smartphone umsteigen, da Ihnen so die Kompatibilität zu Ihrer Apple Watch verloren ginge. Sie müssten sich zusätzlich noch eine andere Smartwatch zulegen, die mit Ihrem neuen Smartphone kompatibel ist. Selbst wenn Sie gerne also ein Samsung Smartphone hätten, der komplette Umstieg auf eine andere Marke wäre teuer. Hindern Sie die abzusehenden Kosten an einem solchen Umstieg und Sie bleiben deshalb bei Ihrem iPhone, hat Apple Sie „eingelockt“ – man spricht hier auch von „Vendor Lock-In“. Wir zeigen Ihnen was Vendor Lock-In ist und wie Sie es richtig erkennen.

Vendor Lock-In ist die Abhängigkeit eines Anwenders/ Kunden/ Nutzers bezüglich eines oder mehrerer Produkte oder Services von einem bestimmten Hersteller. Diese Abhängigkeit entsteht dadurch, dass ein Wechsel zu einem alternativen Anbieter

  • aufgrund mangelnder Alternativen (z.B. fehlender Funktionen) nicht möglich oder
  • aufgrund zu hoher Transaktionskosten unwirtschaftlich ist.

Das klingt zunächst nach etwas, womit wir uns nur selten befassen müssen. Aber weit gefehlt – Vendor Lock-In kann nicht nur in unserem Alltag auftreten, sondern auch in der Cloud. Wie entsteht ein solcher Vendor Lock-In und wie können Sie ihn erkennen?

Vendor Lock-In der Cloud – was ist das?

Ein Vendor Lock-In in der Cloud entsteht dann, wenn die Kosten für eine Migration höher sind als ihr Nutzen.¹ Haben Sie sich für einen bestimmten Cloud-Anbieter entschieden, kann es verschiedene Gründe geben, dass ein Umstieg zu einem anderen Cloud-Anbieter – sollte dieser gewünscht oder notwendig sein – so teuer ist, dass diese Kosten die Vorteile der Migration überwiegen. Im Rahmen meiner Thesis habe ich ein Vorgehen entwickelt, um einen möglichen Vendor Lock-In in der Cloud frühzeitig erkennen und ihm vorbeugen zu können.

Vendor Lock-In am Beispiel von Serverless-Plattformen

Wie ein Vendor Lock-In in der Cloud entstehen kann, lässt sich sehr gut anhand verschiedener Serverless Plattformen zeigen. AWS Lambda und Google Cloud Functions ermöglichen beispielsweise beide das Erstellen von Functions. Functions sind in ihrer Funktion abgeschlossene Code-Einheiten, die bei Bedarf automatisiert ausgeführt werden. Vergleicht man AWS Lambda² mit Google Cloud Functions³, so fällt zunächst auf, dass nicht unbedingt die gleichen Programmiersprachen und Laufzeitumgebungen verwendet werden können. Von beiden Umgebungen werden Node.js, Python und Go unterstützt, seitens AWS Lambda zudem noch Java, C# und Ruby. Wurden nun Functions für AWS Lambda in Java erstellt, können diese nicht für die Google Cloud übernommen werden, da hier keine Java Functions unterstützt werden.

Weiterhin werden in den verschiedenen Cloud-Plattformen verschiedene proprietäre Bibliotheken verwendet. Eine Bibliothek ist eine vorgefertigte Sammlung von Programmcode, der für bestimmte Aufgaben eingesetzt werden kann. Für die betrachteten Plattformen gibt es zum Beispiel die folgenden Bibliotheken:

  • AWS – aws-lambda-java-core: Diese Bibliothek enthält unter anderem das Lambda-Context-Objekt, über das mit der AWS Lambda-Ausführungsumgebung interagiert wird.4
  • Azure – com.microsoft.azure.functions: Diese Bibliothek enthält unter anderem den ExecutionContext, durch den mit der Azure Functions-Ausführungsumgebung interagiert wird.5

Functions können also nicht immer einfach von einer Cloud in die andere übernommen werden, sondern müssen vorher möglicherweise angepasst oder komplett neu geschrieben werden.

Für ein paar Functions ist dies vielleicht kein großer Aufwand. Denken Sie jedoch daran, dass Ihre Anwendung vermutlich nicht ausschließlich aus Functions besteht. Sie müssen beispielsweise auch folgende Punkte genauer betrachten:

  • Sind Ihre Daten kompatibel mit der Zieldatenbank in der neuen Cloud?
  • Wie viel kostet der Export der Daten?
  • Was muss in der Anwendung angepasst werden, um proprietäre Cloud-Schnittstellen unterstützen zu können?
  • Und sind die benötigten Funktionalitäten überhaupt in der neuen Cloud verfügbar?

 

Vendor Lock-In richtig erkennen

Die Summe all dieser verschiedener Lock-In-Gefahren ist es, die am Ende einen Vendor Lock-In ausmachen können. Aus diesem Grund beschäftigte sich meine Thesis mit der Entwicklung einer Möglichkeit, einen Vendor Lock-In zu erkennen. Damit noch darauf reagiert werden kann, muss dies möglichst vor der Migration in eine Cloud oder vor der Neuentwicklung eines Cloud-Services geschehen.

Wie bereits erwähnt entsteht ein Vendor Lock-In dann, wenn die Kosten für eine Migration ihren Nutzen übersteigen. Es müssen also sowohl die Kosten einer Migration als auch ihr Nutzen identifiziert werden, um einen Vendor Lock-In erkennen zu können.

Da der tatsächliche Nutzen einer Migration erst in der Zukunft deutlich werden würde und somit nicht vorhersehbar ist, muss hierfür eine alternative Zahl herangezogen werden. Deshalb wird der Nutzen betrachtet, der bei der Wahl eines bestimmten (anstatt eines bestimmten anderen) Cloud-Anbieters entsteht. Beispielhaft ist dies hier mit fiktiven Zahlen zu sehen:

 

Berechnung eines Vendor Lock-Ins
Abbildung: Beispiel für die Berechnung eines Vendor Lock-Ins (anhand fiktiver Zahlen)

Im Beispiel fällt die Entscheidung auf die Cloud A. Betrachtet werden die Erstellungskosten, bei denen zunächst gegenüber der Wahl von Cloud B ein Nutzen von 10.000€ entsteht. Durch die günstigeren Nutzungskosten in einem bestimmten Betrachtungszeitraum entsteht hier außerdem ein Nutzen von zusätzlich 5.000€. Der Nutzen im Betrachtungszeitraum insgesamt liegt also bei 15.000€. Diesem muss man jedoch die zu erwartenden Migrationskosten gegenüberstellen, im Beispiel 30.000€. Da der Nutzen dann negativ wird, entstünde hier ein Vendor Lock-In.

 

Fazit:

Letztendlich besteht jedoch auch hier das Problem, dass sich in der Zukunft die Nutzungskosten und die zu erwartenden Migrationskosten verändern können. Entweder wird so eventuell ein Vendor Lock-In vorausgesagt, der dann doch nicht entsteht, oder ein Vendor Lock-In tritt wider Erwarten doch auf. Es kann also keine genaue, durch Zahlen belegte Aussage getroffen werden, ob bei einem Cloud-Anbieter mit Sicherheit ein Vendor Lock-In auftreten wird.

Trotzdem können die identifizierten Migrationskosten zumindest als Einschätzung herangezogen werden, an welchen Stellen in einer Cloud-Anwendung ein Vendor Lock-In entstehen könnte. In Verbindung mit Expertenwissen kann so eingeschätzt werden, ob einem möglichen Lock-In entgegengewirkt werden sollte und welche Maßnahmen hierzu herangezogen werden können.


Quellen:

1 angelehnt an: Justice Opara-Martins, Reza Sahandi und Feng Tian. “A Holistic Decision Framework to Avoid Vendor Lock-in for Cloud SaaS Migration. In: Computer and Information Science 10 (Juli 2017), S. 29. issn: 1913-8989. doi: 10.5539/cis.v10n3p29. (S.30)

2 https://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html

3 https://cloud.google.com/functions/docs/writing

4 https://docs.aws.amazon.com/de_de/lambda/latest/dg/java-programming-model.html

5 https://docs.microsoft.com/en-us/java/api/com.microsoft.azure.functions.executioncontext?view=azure-java-stable