Welchen Mehrwert Software in der Medizintechnik schafft

Heute sind viele neue Geräte und Prozesse im Einsatz, die die Welt in der Medizintechnik und die Möglichkeiten zur Genesung deutlich verbessern und beschleunigen.

Die Medizintechnik wird softwaregestützter

Medizintechnische Geräte verfügen mittlerweile auch zunehmend über mehr Bedien- und Systemfunktionen, die durch Software Applikationen realisiert sind. Auch hier werden die Geräte also immer mehr „Software defined“. Das bedeutet für die Hersteller von Medizintechnik Produkten, dass die Kooperation mit Herstellern und Dienstleistern von Software immer entscheidender wird. Denn diese Applikationen müssen konzipiert, erstellt, aktualisiert und gewartet werden. Für viele Funktionen sind darüber hinaus noch Plattformen für die Datenhaltung und -verarbeitung (zum Beispiel in der Cloud) erforderlich.

Somit ist auch für doubleSlash die Digitalisierung der Medizintechnik ein sehr spannendes, wenn auch nicht ganz neues Betätigungsfeld. Unter anderem konnten wir unser IoT-Knowhow schon bei der Umsetzung von präventiver Wartung für hochkomplexe Mikroskope einsetzen.
Unser Learning: Bewährte IT-Methoden und -Technologien aus anderen Branchen, wie zum Beispiel aus Automotive, Logistik oder Industrie, können auch für die Medizintechnik nutzbringend eingesetzt werden.
Zudem passt die softwaregetriebene Unterstützung in der Medizintechnik auch hervorragend zu den Werten von doubleSlash: Menschen durch IT-unterstützte Diagnosen, Eingriffe und Therapien zu helfen ist ein wertiges und nachhaltiges Ziel, für das wir uns gerne engagieren.

So wurde auch auf der Eröffnungsfeier des doubleSlash Software Innovationszentrums durch das MedTech Team eine Art Zeitreise durch die Medizintechnik inszeniert: historische Bestrahlungslampen aus den 20ern reihten sich mit Operationsequipment aus den 50ern und einem Endoskop aus den 80ern ein in die heutige Welt ein, um den Fortgang und die digitale Entwicklung in der Medizintechnik zu veranschaulichen.

Equipment der Zeitreise
Equipment der Zeitreise
Kollegen aus dem doubleSlash MedTech Team: Rudolf Betz (Sales), Stefan Dürnay (Product Owner und Agile Coach) und Lukas Blumenstein (Gesundheitsinformatik Thesant)

Die Zukunft der Medizintechnik wird digital – Vernetzung, KI und kundenfreundliche Services

Schon heute wird in der Medizintechnik mit digitalen Prozessen und Technologien innovativ und kompetent unterstützt: Sei es in der Telemedizin, bei der Verwaltung von Patientendaten oder der Automatisierung von medizinischen Prozessen – um nur einige Beispiele zu nennen. Die Digitalisierung bringt hier viele Chancen mit, um den Arbeitsalltag des medizinischen Personals patientenzentrierter, sicherer und angenehmer zu gestalten. Fortschrittliche Algorithmen strukturieren und analysieren große Datenmengen und machen sie nutzbar, um z.B. Diagnosen zu unterstützen. Das trägt signifikant zur Entlastung des medizinischen Fachpersonals bei und so steht mehr Zeit für die Patientinnen und Patienten zur Verfügung. Den Themen Datenschutz und -sicherheit begegnen wir selbstverständlich äußerst sensibel, um die Datenverarbeitung mit höchsten Sicherheitsstandards umzusetzen und den Schutz von Patientendaten verlässlich zu gewährleisten.

Zudem haben sich medizinische Verfahren und Geräte massiv weiterentwickelt. Professionelle Wartung und Updates sollen den effektiven Einsatz der hochwertigen und kostspieligen Geräte für viele Jahre bei hoher Verfügbarkeit sicherstellen. Eine Integration der Geräte untereinander sichert effizientes und stressfreieres Arbeiten.

Haben auch Sie die Herausforderung oder Bedarfe einen Prozess digital zu unterstützen und zu verbessern? Dann sprechen Sie uns gerne an.

 

Lust auf eine Zeitreise?So könnte das Teamwork zwischen Mensch und Maschine im Jahr 2030 aussehen

HATEOAS – Können REST-APIs Geschichten erzählen?

Das bringt mich als Entwickler zu der Frage: Können wir mit unseren REST APIs auch Storytelling betreiben und werden sie dadurch verständlicher? Vielleicht lassen sich ja mit Storytelling die Funktionsweisen der Schnittstellen besser vermitteln?

Mein erster direkter Kontakt mit dem Thema Storytelling liegt mittlerweile einige Jahre zurück. Es war während einer internen Konferenz. Ein Kollege hat das Thema vorgestellt. Seine Herzensangelegenheit. Alle Kollegen, die diesen Vortrag besucht hatten, waren begeistert und sprachen ununterbrochen davon. Leider hatte ich mich für einen anderen Vortag entschieden. Ein technischeren, denn wie sollte mir Storytelling als Entwickler weiterhelfen? Zum Glück wurde sein Vortrag aufgezeichnet. So verzauberte auch mich das Storytelling. Bis heute erinnere ich mich an diesen Vortrag. An wie viele Vorträge der letzten Jahre erinnern Sie sich noch?

Ist Storytelling mit REST APIs überhaupt möglich?

Die Anbindung einer REST API kann beliebig komplex sein. Es muss die Schnittstelle selbst sowie ihre Domäne verstanden werden. Die Einhaltung von Best Practices hilft uns, die Schnittstelle technisch schneller zu verstehen. Aber oftmals steckt der größere Aufwand im Verständnis der Domäne. Kann uns Storytelling dabei weiterhelfen?

Darstellung einer dynamischen Geschichte
Abbildung 1: Darstellung einer dynamischen Geschichte; Bildquelle: Schmidt Spiele „Das schwarze Auge“

Geschichten müssen nicht statisch sein, sondern können auch dynamisch sein, so wie unsere Schnittstellen. Beispiele dafür sind Computerspiele, die eine dynamische Storyline haben, aber auch Bücher. Als Kind hatte ich ein Detektiv-Buch, bei dem man am Ende des Absatzes selbst entscheiden konnte wie die Geschichte weiter geht – ähnlich zu der Abbildung 1. Somit konnte man den Geschichtsverlauf beeinflussen. Wichtig ist der rote Faden.

HATEOAS – Hypermedia as the Engine of Application State – kann bei REST APIs zum Storytelling verwendet werden. Es wird von Roy Fielding in seiner Promotion als wichtigste Eigenschaft einer REST API beschrieben. Bei HATEOAS sendet der Server zusätzlich zu den eigentlichen Daten Metainformationen für den Klient mit. Dadurch wird eine lose Kopplung zwischen dem Klienten und dem Server erreicht. Diese Metainformationen verwendet der Klient zur Navigation. Ist das nicht ähnlich zu meinem Detektivbuch? Die Schnittstelle ist das Buch, eine Ressource ist der Absatz der Geschichte und die Metainformationen, die Verweise wo die Geschichte weitergeht.
Die zusätzlichen Metainformationen helfen einerseits, die Domäne besser zu verstehen und andererseits muss der Klient die Domäne nicht so im Detail verstehen, wie der Server. Somit wird der Aufwand für die Anbindung verringert.

Code Snippet 1: Antwort der Ressource “invoices“ mit verschiedenen Antwortoptionen

Geschichten aus REST APIs gehören zum Entwickler-Alltag

Vermutlich sind die Geschichten, die eine REST API erzählt, nicht so interessant, wie die eines Detektivs. Aber sie sind doch ein wichtiger Bestandteil unseres Entwickler-Alltags. In einem Projekt haben wir einen Microservice entwickelt, dessen (Kurz-)Geschichten sich um das Thema Rechnungen dreht. Die Informationen einer Rechnung sind sozusagen ein Absatz einer eigenständigen Geschichte. Je nach Inhalt der Geschichte gibt es verschiedene Pfade, diese weiterzuführen. Ist eine Rechnung also beispielsweise schon storniert, gibt es lediglich einen Verweis auf die Gutschrift. Andernfalls gäbe es einen Verweis zur Erstellung der Gutschrift. In Zukunft soll es aber noch weitere Handlungsstränge für die Rechnung geben. Dazu zählt beispielsweise die Rechnungskorrektur.

Das Codebeispiel zeigt eine beispielhafte Antwort. Unter dem Attribut „_links“ sind alle weiteren Handlungsstränge für die Rechnung dargestellt. In diesem Fall kann eine Gutschrift für diese Rechnung erstellt werden. Bei HATEOAS ist es auch üblich, dass jede Ressource eine Referenz auf sich selbst hat.

Die vorherrschende Meinung ist: Die Umsetzung von HATEOAS ist mit einem hohen Aufwand verbunden

Auf den ersten Blick erhöht sich der Aufwand durch die Umsetzung von HATEOAS. Der zusätzliche Aufwand ist aber geringer als man im ersten Augenblick vermutet. Besonders im Spring-Umfeld und unter der Nutzung von Spring HATEOAS.

Code Snippet 2: Die einzige Änderung im Model ist die Vererbung von RepresentationModel.

Code Snippet 3: Beispiel für einen RestController mit Fokus auf die Bestandteile, die für die Verwendung von HATEOAS benötigt sind

Der Code in Zeile 15 – 33 entsteht durch den Einsatz von HATEOAS. Zusätzlicher Code, der auch gewartet und verstanden werden muss. Allerdings ist hier der Vorteil, dass der Code von den Domänenexperten entwickelt wurde. Kein Klient muss diese Logik verstehen und selbst implementieren. Dadurch fällt diese Fehlerquelle weg. Sollte sich doch einmal ein Fehler eingeschlichen haben, so kann er an einer zentralen Stelle gefixt werden.

Fazit: HATEOAS ermöglicht Storytelling

REST APIs können Geschichten erzählen. Diese Geschichten helfen dem Anwender die Domäne besser zu verstehen. Nicht nur wir, sondern auch unser Kunde war begeistert davon. Er hat den Mehrwert erkannt und sich darüber gefreut, wie einfach wir seine Domäne zugänglich gemacht haben. Der befürchtete erhöhte Aufwand bei der Umsetzung war vernachlässigbar gering. Der zusätzliche Code funktioniert problemlos und musste nicht nochmals angepasst werden. Das ist vor allem auf die wirklich gute Umsetzung von Spring HATEOAS zurückzuführen. Spring HATEOAS hat uns überzeugt und wir können jedem nur empfehlen es selbst auszuprobieren .

Könnt ihr euch vorstellen, bei der nächsten Schnittstelle auch auf HATEOAS zu setzen? Oder warum nicht?

Key as a Service (KaaS) – Eine IT-Anwenderstory zum digital Key – Teil 2

Dieser Beitrag widmet sich daher dem Teilen und Löschen des Schlüssels, sowie allgemeinen Datenschutz Themen rund um den digital Key.

Der digital Key: Sharing, Revocation und Datenschutz

Im ersten Teil unserer KaaS IT-Anwenderstory konnten wir uns einen Einblick in die Hauptschlüsselerstellung verschaffen und uns ein Bild vom Handling mit dem digitalen Fahrzeugschlüssel machen.

Erstellung eines digitalen Schlüssels
Abbildung 1: Erstellung eines digitalen Schlüssels; Bildquelle: doubleSlash

Erinnern wir uns an die Bilderstory aus dem ersten Teil zurück, da benötigte meine Kollegin Judith dringend meinen 1er BMW. Den Schlüssel habe ich ihr dann ganz einfach via Apple iMessage teilen können. Geht das wirklich so einfach und wie funktioniert das eigentlich?

Key Sharing: Fahrzeugschlüssel teilen mit dem digital Key

Als Generation X’ler (immerhin ein fast Y’ler) mit einer Faszination für digitale Prozesse ist man es irgendwie noch gewohnt, einen echten Autoschlüssel mit sich herumzutragen. Daher war für mich das Teilen des Schlüssels an Familie und Freunde der eigentliche Grund einen digitalen Schlüssel nutzen zu wollen.

Teilen und Nutzen eines digitalen Schlüssels
Abbildung 2: Teilen und Nutzen eines digitalen Schlüssels; Bildquelle: doubleSlash

Ist es denn jetzt wirklich so einfach wie es uns die Werbung und die anderen Berichte erzählen wollen? Schauen wir es uns doch gemeinsam einfach an.

Unsere Ausgangslage vom letzten Blogpost war, dass wir einen funktionierenden Hauptschlüssel im Wallet des iPhones haben mit dem wir das Fahrzeug öffnen und schließen, sowie das Fahrzeug starten und fahren können. Klicken wir nun vom Hauptschlüssel im Wallet oben rechts auf den drei Punkte Button gelangen wir auf die Schlüsselinformationsseite im Wallet.

Schlüsselinformationsseite im Wallet
Abbildung 3: Schlüsselinformationsseite im Wallet; Bildquelle: Eigene Darstellung

Klingt jetzt super spannend, ist es aber eigentlich nicht. Dahinter verbergen sich drei Links auf die BMW Seite, eine App-Details Seite, der Umschalter für den Expressmodus und den mit Spannung erwarteten Button “Einladen …“.

Im nachfolgenden Menü erhalten wir eine kurze Erklärung sowie eine Auswahl über “Einladen” und “Zugriff konfigurieren“. Der Informatiker in mir siegt und ich klicke auf die Konfiguration und in der nachfolgenden Auswahl kann ich das vorausgewählte “Entsperren & Fahren” oder “Eingeschränktes Fahren” wählen. So richtig selbsterklärend ist das jetzt nicht, vor allem wenn dann auch noch der Verweis auf das Benutzerhandbuch des Fahrzeugs kommt.

Klicke ich dennoch weiter, kann ich im Anschluss auf “Einladen …” klicken und lande in Apples iMessage. Jetzt muss nur noch der Empfänger aus dem Adressbuch ausgewählt werden und es kann los gehen.

 

 

 

 

Empfänger auswählen
Abbildung 5: Empfänger auswählen; Bildquelle: Eigene Darstellung

Werfen wir nun einen Blick auf die Technik:

Prozessbild der Schlüsselausstellung beim Teilen eines Schlüssels
Abbildung 6: Prozessbild der Schlüsselausstellung beim Teilen eines Schlüssels; Bildquelle: eigene Darstellung in Anlehnung an Apple Darstellung

Das Teilen des Schlüssels (Key Sharing) setzt auf dem X.509 zertifikatsbasiertem Hauptschlüssel auf. Der neue, geteilte Schlüssel ist prozessual eine Fortführung der Zertifikatskette vom Hauptschlüssel. Apple geht in dem WWDC Beitrag leider nicht tiefgehend auf den Prozess ein, aber ein wenig konnten wir herausziehen.

Der Prozess startet mit einer Einladung in Form einer iMessage ausgehend vom Hauptschlüssel. Die iMessage selbst enthält das Grundgerüst (Template) zur Schlüsselerstellung. In dem Prozess wird ein spezielles Hauptnutzer / Zweitnutzer Intermediär Zertifikat erstellt, welches auch wieder mit dem Fahrzeughersteller Zertifikat verbunden ist. Während bei der Hauptschlüsselerstellung das Backend des Fahrzeugs den Schlüssel validiert, erfolgt dies beim Teilen des Schlüssels durch das Telefon des Hauptnutzenden.

Der wesentliche Unterschied zwischen Hauptschlüssel und Zweitschlüssel ist die Bekanntgabe des Schlüssels im Fahrzeug. Während wir beim Hauptschlüssel den kompletten Prozess im Fahrzeug durchführen müssen und das Fahrzeug dabei “online” sein muss, ist dies beim Zweitschlüssel nicht mehr notwendig. Der Vorteil ist, dass wir das Fahrzeug offline in der Tiefgarage parken und dennoch den Schlüssel teilen können.

Standard Transaction / Fast Transaction

Generell lässt sich das Fahrzeug relativ schnell in unter einer Sekunde mit dem Telefon öffnen. Allerdings nur dann, wenn der Schlüssel auch im Fahrzeug bekannt ist. Dies funktioniert zwar generell auch beim Zweitschlüssel, allerdings nicht im erwähnten Tiefgaragenfall beim Erstkontakt. Der ganze Prozess wird im WWDC Beitrag sehr technisch geprägt beschrieben und erläutert in Summe die Kommunikation mit dem Fahrzeug und den Austausch der notwendigen Informationen.
Grundsätzlich ist der Zweitschlüssel nach Abschluss des zuvor beschriebenen Prozess noch nicht vollständig, da weitere Informationen mit dem Fahrzeug ausgetauscht werden müssen. Dieser Austausch bzw. die Komplettierung der Schlüsselinformationen erfolgt beim ersten Kontakt mit dem Fahrzeug.

Sollten dem Fahrzeug Informationen fehlen, wie in unserem Offline Tiefgaragenfall, so werden diese aus dem noch unbekannten Zweitschlüssel extrahiert und im Fahrzeug gespeichert. Dies dauert leider etwas und ich fand es bei den ersten Malen befremdlich. Zum einen hatte ich kein Gefühl dafür, wie das Telefon oder die Uhr an den Türgriff zu halten ist und zum anderen kommt auch keine Rückmeldung, ob derzeit ein Austausch von Informationen stattfindet. Demzufolge habe ich den Prozess wahrscheinlich einige Male abgebrochen, da der Prozess zwischen 2-3 Sekunden dauert.

Der komplette Prozess ist wesentlich schneller, wenn das Fahrzeug vorher online war. Dann werden nur noch wenige Informationen für die Öffnung der Tür benötigt.

Apple Watch als Digital Key

In der ersten Version des digitalen Schlüssels war die Anzahl der Schlüssel seitens BMW begrenzt und man konnte nur mit Hilfe eines Zusatzpakets jeweils weitere fünf Personen dazu buchen. Diese Option wurde dankenswerterweise mit dem Standard abgeschafft, sodass der neue digitale Schlüssel nach dem Car Connectivity Consortium nur noch eine rein technisch begründete Begrenzung der teilbaren Schlüssel erhalten hat.
Zusätzlich erlauben Apple und BMW die gleichzeitige Nutzung von einem iPhone und Apple Watch, sofern diese am gleichen iCloud Account gebunden sind. Das Übertragen des Schlüssels auf die Apple Watch ist in Summe genauso einfach wie der Übertrag von Kreditkarten bei Apple Pay. Hierzu ist keine Aktion oder eine Form von Bestätigung durch den Hauptschlüsselbesitzenden notwendig.

KaaS: Fahrzeug öffnen mit der Apple Watch
Abbildung 7: Öffnen des Fahrzeugs mit der Apple Watch; Bildquelle: doubleSlash

In der Präsentation von Apple wurde erwähnt, dass jedes Gerät ein eigenes und eindeutiges Secure Element besitzt. Daher muss es aus technischen Gründen zwingend um einen weiteren geteilten Schlüssel handeln, da sonst die Zertifikatskette nicht mehr eindeutig ist.

Digitalen Schlüssel löschen

Natürlich möchte man auch geteilte Schlüssel oder den eigenen Schlüssel wieder löschen und wir konnten unterschiedliche Prozesse ausmachen. Generell konnte jeder Schlüssel einzeln im Fahrzeug gelöscht oder die komplette Funktion zurückgesetzt werden. Hinzu kommt das Löschen des eigenen Schlüssels direkt über das Telefon oder aus der iCloud. Für geteilte Schlüssel kommt zusätzlich die Option für das Löschen durch den Hauptbenutzerschlüssel hinzu.

Der Prozess funktioniert sehr gut. Egal über welchen Weg: die Schlüssel sind von allen Geräten und auch im Fahrzeug gelöscht. In Summe ist der Prozess recht unspektakulär, daher gehe ich hier nicht weiter darauf ein. Die Besonderheiten lagen jedoch im Detail und wann die Schlüssel wirklich gelöscht werden. Bei der Löschung des eigenen Schlüssels wird die Löschung direkt angestoßen, so weit so logisch. Spannend wurde es allerdings bei der Löschung eines geteilten Schlüssels, denn hier scheint das Fahrzeug zu definieren, wann welcher Schlüssel gelöscht wird. Wir haben ein wenig ausprobieren und experimentieren müssen, bis wir auf diese sehr geschickte Logik gekommen sind.

Sicheres Löschen

Angenommen wir teilen den Schlüssel mit der besten Freundin und sie ist so nett und fährt mit dem Wagen zur Tankstelle. Irgendwie sitzt uns aber heute der Schalk im Nacken und wir löschen ihr den Schlüssel während sie unterwegs ist.

Bleibt das Auto stehen? Lässt es sich überhaupt noch abschließen? Oder lässt es sich abschließen, aber dann nicht mehr öffnen?

Sie hätte „bestimmt“ ihren Spaß an der Tankstelle gehabt oder wir hätten zumindest in einem Jahr gemeinsam da drüber gelacht.
Aber um ehrlich zu sein war die Aktion total langweilig, denn es passiert rein gar nichts. Ja ehrlich, gar nichts. Wahrscheinlich hätte sie mit dem Schlüssel noch in den Urlaub fahren können und es passiert nichts.

Nach unseren Tests mussten folgende Bedingungen erfüllt sein:

  • Fahrzeug abgestellt und abgeschlossen
  • Der zuletzt genutzte Schlüssel darf nicht der zu löschende Schlüssel sein

Die Bedingungen können nicht zu 100 Prozent verifiziert werden, decken sich aber mit unseren Tests. Ich persönlich finde das super mitgedacht. Immerhin kann ich dadurch nicht aus reinem Versehen von dem aktuellen Benutzer den Schlüssel löschen und gefährde womöglich Personen oder Fahrzeug.

Probleme beim Löschen von digitalen Schlüsseln

Das Löschen von Schlüsseln funktioniert perfekt. In unserem Test konnten wir nur einmal ein Problem feststellen, dass wir aber nicht gelöst bekommen haben ohne das Hauptnutzer-Telefon zurückzusetzen. Es handelte sich dabei um die Löschung eines geteilten Schlüssels vom Telefon des Zweitnutzenden. Der Schlüssel wurde auf dem Wallet des Telefons des Zweit- bzw. Nebennutzenden gelöscht und im Fahrzeug war der Schlüssel ebenfalls gelöscht, allerdings nicht auf meinem Telefon (Hauptnutzer). Ich habe versucht den Schlüssel mehrfach zu löschen, aber bekam es nicht hin. Der Fehler trat jedoch danach nie wieder auf und auf Rückfrage beim Apple Support wurde das Problem auch behoben.

Digital Key und Datenschutz

Apple betont, dass ihnen der Datenschutz besonders wichtig ist. Aber wie ist das überhaupt möglich in einem derartigen System? Schaut man im Wallet genauer hin, so wird erkennbar, dass sich der digitale Fahrzeugschlüssel in den Bereich der Kreditkarten einbindet und nicht im unteren Bereich mit den Flugtickets oder Kinokarten.

KaaS und Versicherungen
Abbildung 8: Anordnung digitaler Fahrzeugschlüssel im Wallet; Bildquelle: Eigene Darstellung

Kreditkarten und der Fahrzeugschlüssel werden laut Apple im Secure Element des Telefons abgelegt. Bei Kreditkarten ist bekannt, dass Apple keine Informationen über die eigentlich hinterlegten Daten an die Kartenlesegeräte weitergibt. Weiterhin gilt das Bezahlen via Apple Pay als eine der sichersten Methoden. Der Datenaustausch seitens Apple Pay ist generell gut dokumentiert und durch die vorgestellte System Architecture lassen sich Annahmen treffen, welche datenschutzrelevanten Informationen für den BMW Digital Key benötigt werden könnten.

Fangen wir beim Fahrzeug an:

  • Jedes Fahrzeug hat eine sogenannte VIN/FIN (Fahrzeugidentifikationsnummer), die eindeutig ist
  • Als digitale Identität des Benutzers wird bei BMW normalerweise der Connected Drive Benutzeraccount verwendet. Als Login des Benutzers wird in Deutschland die E-Mail Adresse genutzt.

Apple iPhone:

  • BMW erwähnt, dass eine verknüpfte Apple Watch zu einem iPhone nur als ein Schlüssel zählt und kein erneutes Sharing mit dem Hauptschlüssel notwendig ist. Demzufolge wird der iCloud-Account sehr wahrscheinlich eine Rolle spielen
  • Seriennummer vom Smartphone bzw. der Apple Watch
  • Seriennummer vom Secure Element vom Smartphone bzw. der Apple Watch, im Smartphone als SEID hinterlegt

Digitaler Fahrzeugschlüssel:

  • Physische Fahrzeugschlüssel besitzen eine Schlüssel Kennnummer. Die digitalen Fahrzeugschlüssel besitzen ebenfalls eine ID, die im Fahrzeug von BMW bei den Einstellungen vom Fahrerprofil des jeweiligen Schlüssels einzusehen ist.

Apple erwähnt in dem WWDC Beitrag, dass die Daten sicher auf dem Gerät liegen und keine Rückverfolgung oder Zugriffe durch Apple möglich sind. Wie kann das sein? Immerhin werden Daten nicht nur zwischen den Geräten über NFC ausgetauscht, sondern eben auch über die Server. Apple wirbt seit Jahren mit ihrer Ende-zu-Ende Verschlüsselung und es ist davon auszugehen, dass die entsprechenden digitalen Identitätsmerkmale zusätzlich von jeder Partei maskiert und verschlüsselt werden. Das iPhone selbst muss bspw. nicht zwingend die VIN kennen, damit der Schlüssel funktioniert. Die Identifikation vom Fahrzeug ist auch nur in der Anfangsphase für BMW selbst relevant, denn ohne die Zuordnung werden die beschriebenen rechtlichen Anforderungen nicht umsetzbar sein. Für Apple ist dies irrelevant, denn es wird nur die Information benötigt, mit welchem Fahrzeughersteller kommuniziert werden soll.

Maskierte Identifikationsmerkmale

Anhand der Informationen vom Car Connectivity Consortium, dem WWDC Beitrag und auch den zugrunde liegenden Technologien können wir nur Vermutungen anstellen welche IDs ausgetauscht werden. Daher versuchen wir es doch einfach mal logisch aufzubauen mit dem Best Guess Ansatz:

  • Das Fahrzeug muss in irgendeiner Art und Weise identifiziert werden und auch den entsprechenden Geräten/Fahrzeug zugeordnet werden. Da nur BMW die Hauptnutzerinformationen kennt und mittels einem Mapping Prozesses zusammenführt, gehe ich von einer VehicleID aus, die eine Verknüpfung aus Fahrzeug und der digitalen Identität des Benutzers darstellen wird.
  • Jeder Schlüssel besitzt eine eigene Identifikationsnummer. Sie wird zwar im Wallet nicht dargestellt, jedoch im Fahrzeug bei der Verknüpfung von Profilen mit einem Schlüssel. BMW steuert mit den Profilen beispielsweise, bei welchen Außentemperaturen die Sitzheizung generell angeschaltet wird.
  • Im ersten Blogpost hatte ich Bezug auf einen Beitrag der Allianz Versicherung hergestellt, in dem auf die eindeutige Schlüsselidentifizierung bei einem Diebstahl eingegangen wird. Wir erinnern uns, dass die Polizei in der Regel den Besitznachweis des physischen Schlüssels verlangt. Die physischen Schlüssel werden hierzu bei der Wache abgegeben und die Schlüsselkennung wird mit den Herstellerinformationen abgeglichen. Wir hatten zwar die Schlüsselidentifikationsnummer im vorherigen Schritt, diese wird jedoch im Telefon nicht angezeigt. Da Apple nach eigenen Angaben keine Informationen an BMW über seine Benutzer preisgibt, ist davon auszugehen, dass auch Apple die Seriennummer und die Secure Element ID einzeln oder als gemeinsames Paar als GeräteID maskiert übergeben wird.
  • BMW und Apple versprechen die gemeinsame Nutzung von Watch und iPhone des Benutzenden ohne den Schlüssel zusätzlich teilen zu müssen. Die Identifikation der Geräte einer Person kann nur Apple wissen, die Anzahl der verfügbaren Schlüssel des Fahrzeugs kennt wiederum nur BMW. Das, nach meiner Meinung, wahrscheinlichste Identifikationsmerkmal für dieses Feature ist die iCloud-Account ID von Apple. Daher ist davon auszugehen, dass diese auch maskiert vorliegen wird als eine Art AppleAccountID.

 

Fazit

Die technologische Basis vom digitalen Schlüssel ist sehr durchdacht und man darf gespannt sein, welche physischen Geräte sich in Zukunft ganz einfach mit dem Telefon öffnen lassen. Der Grundstein dafür wurde mit diesem Standard geschaffen, auch wenn er sich wahrscheinlich nicht 1:1 übertragen lassen wird.

Für den digitalen Fahrzeugschlüssel der Zukunft würde ich mir wünschen, dass ich meinen Apple Car Key mit Benutzern eines Android Smartphones teilen kann und der Schlüssel damit nicht auf das eigene „Universum“ begrenzt ist, wahrscheinlich ist dies aber auch nur eine Frage der Zeit. Außerdem fehlt mir eine personalisierte Darstellung des digitalen Schlüssels im Wallet. Wir verbringen zum Teil viel Zeit in „des Deutschen liebstes Kind“ und insbesondere BMW spielt mit genau dieser Verbundenheit. Das Smartphone steht dem in Nichts nach, es wird den ganzen Tag mitgeführt und oft sind die persönlichsten Informationen und Bilder auf dem Telefon zu finden.

Insgesamt ist der digitale Fahrzeugschlüssel ein richtig gelungenes Feature eines Connected Cars und auch dieses Mal bleibt uns nur zu sagen: “Awesome, great job!”

 

 

Mehr zum digitalen Fahrzeugschlüssel erfahren

__________________________________________________________________________________________

Quellen

It’s #FrontendFriday – Observer-Pattern

Was ist das Observer-Pattern?

Mit Hilfe des Observer Entwurfmusters können Abhängigkeiten zwischen mehreren Objekten definiert werden.  Das Objekt, welches beobachtet wird, wird Subject genannt. Das beobachtende Objekt ist der Observer. Sollte sich das Subject ändern, so werden die dazugehörigen Observer automatisch aktualisiert. [4]

Observer Entwurfsmuster

[3]

Der Einsatz des Observer Design Pattern hat den großen Vorteil, dass das Subject nicht permanent auf Änderungen geprüft werden muss. Sobald sich das Subject ändert, wird der neue Wert automatisch an alle Observer übermittelt.

 

Code-Example

Wie sieht denn das Observer-Pattern in Javascript aus? Hier ein Beispiel:

Im obigen Beispiel gibt es 2 Observer – FrontendFridayObserver1 und FrontendFridayObserver2.

Mit der Methode itsFrontendFriday() werden alle Subscriptions aufgerufen, woraufhin die Funktionen FrontendFridayObserver1 FrontendFridayObserver2 ausgeführt werden. [2]

Ausgabe:

 

Relevanz in JavaScript

Observer sind eine sehr effiziente Methode um Informationen mit verschiedenen Komponenten zu teilen.

Dies kann allerdings auch zu einem Nachteil werden, da immer alle Observer informiert werden, sobald sich das Subject ändert. Dies erhöht die Rechenleistung und kann sich negativ auf die Performance auswirken. Zudem ist am Subject selbst nicht ersichtlich wie viele Observer es gibt und aktualisiert werden.

Dennoch ist das Observer Pattern besonders in der Frontend-Entwicklung sehr hilfreich.

Ein Beispiel ist der Einsatz von Observer für Benutzeroberflächen. Sollten sich im Hintergrund Werte ändern, so muss auch die Anzeige entsprechend aktualisiert werden um den Nutzer über diese Änderungen zu informieren. [1]

 

Die Webfrontend-FG wünscht allen ein schönes Wochenende!

Mehr über Java Programmierung erfahren

 

Quellen:

[1] Observer Pattern: Was steckt hinter dem Observer Design Pattern?

[2] dofactory – Understanding JavaScript Observer Patterns

[3] dofactory – JavaScript Observer – Diagram

[4] dofactory – JavaScript Observer