Der Automotive Service Bus im Elektroauto der TU München

Entwicklung innovativer IT-Dienste im Auto mit OSGi

David Soto Setzke, Thomas Köhn, Maximilian Schreieck

@ Shutterstock/etraveler

An der TU München wurde im Oktober 2014 mit dem Visio.M der Prototyp eines umweltfreundlichen, sparsamen und sicheren Elektroautos vorgestellt. Neben technischer Neuerungen im Bereich Antrieb, Struktur und Design enthält der Visio.M ein innovatives On-Board-System auf Basis des Automotive Service Bus. In diesem Artikel wird der Aufbau des Automotive Service Bus beschrieben und die Entwicklung eines Diensts nachvollzogen.

Der Automotive Service Bus ist eine OSGi-basierte Plattformarchitektur für IT-Dienste im Auto, die sich besonders durch Flexibilität und Sicherheit auszeichnet. Einerseits können neue Dienste dynamisch nachgeladen und flexibel zusammengestellt werden, andererseits ist Sicherheit sowohl durch die Kapselung fahrrelevanter Systeme gegeben als auch durch die Darstellung und Bedienung aller Dienste in einem einheitlichen Interaktionskonzept. Letzteres erleichtert und beschleunigt ebenso die Entwicklung neuer Dienste. Diese Architektur wurde im Rahmen des Visio.M-Projekts umgesetzt, beispielhaft mit relevanten Diensten erprobt und nach Ende des Projektes Open Source verfügbar gemacht.

Abb. 1: Visio.M – Elektroauto der TU München. Weiterführende Informationen unter [1] (Foto: Technische Universität München, 2015)

Abb. 1: Visio.M – Elektroauto der TU München. Weiterführende Informationen unter [1] (Foto: Technische Universität München, 2015)

Architektur des Automotive Service Bus

Der Automotive Service Bus (ASB) im Visio.M läuft auf dem Linux-Betriebssystem und hardwareseitig auf dem PandaBoard von Texas Instruments. Da er auf der Plattformarchitektur OSGi und dem OSGi-Container Karaf basiert, kann er jedoch grundsätzlich auf verschiedenen Rechnerarchitekturen eingesetzt werden. Karaf und OSGi ermöglichen es, dass innerhalb des ASB verschiedene Dienste in Form von OSGi-basierten Bundles laufen und die Zusammenstellung der Bundles dynamisch zur Laufzeit verändert werden kann. Dies erlaubt es dem ASB, im laufenden Betrieb neue Dienste freizuschalten, bestehende zu aktualisieren oder sie zu deaktivieren, z. B. im Fall von Mehrwertdiensten. Die Gesamtarchitektur des ASB ist in Abbildung 2 dargestellt.

Abb. 2: Mehrschichtige Architektur des Automotive Service Bus

Abb. 2: Mehrschichtige Architektur des Automotive Service Bus

Laufende Dienste können den OSGi-basierten EventAdmin Service benutzen, um gegenseitig Nachrichten auszutauschen. Dies hat den Vorteil, dass Funktionalität wiederverwendet werden kann und Dienste kombiniert werden können, um komplexere Dienste zu erstellen. Der ASB stellt einen API-Wrapper bereit, der von den Standardfunktionen und Datenstrukturen (z. B. die Event-Klasse) des EventAdmin Service abstrahiert, um dem Programmierer die Arbeit zu erleichtern.

Dienste können einerseits Nachrichten als Broadcast an alle anderen Dienste senden, wenn sich einer ihrer Werte ändert, beispielsweise die aktuelle Geschwindigkeit oder der abgespielte Musiktitel. Andererseits kann ein Dienst auch eine Nachricht direkt an einen anderen Dienst adressieren, um bei diesem Dienst ein spezifisches Verhalten auszulösen, beispielsweise eine Änderung der Zieltemperatur der Klimaanlage. Zur Implementierung der Dienste müssen die entsprechenden Klassen passende Interfaces implementieren, zur Laufzeit bekommen sie dann via Dependency Injection Zugriff auf Objekte, über die sie Nachrichten empfangen und senden können. Die Nachrichtenklassen selber sind wiederum Wrapper der EventAdmin-internen Event-Klasse.

Um die Interaktion des Fahrers mit den verschiedenen Diensten zu ermöglichen, wurde im Visio.M-Projekt ein iPad im Auto verbaut, das den aktuellen Status der Dienste anzeigt und die Steuerung spezifischer Funktionen der Dienste realisiert. Des Weiteren wurde eine Smartphone-App entwickelt, über die der Fahrer Einstellungen einsehen und ändern kann, ohne direkten Zugriff auf das Auto zu haben. Eine zentrale REST-Schnittstelle sorgt für die Anbindung der verschiedenen Systeme an den ASB. Über XML-Dateien können Dienste angeben, welche ihrer Nachrichten auch über die Schnittstelle verfügbar sein können. Web-Services-Clients wie beispielsweise die iOS-basierte grafische Benutzerschnittstelle des iPads können dann mithilfe von Server-Sent-Events diese Nachrichten abonnieren und durch PUT Requests selbst Nachrichten über die Schnittstelle auf den Bus legen, um Dienste zu steuern. Die REST-Schnittstelle wird über ein eigenes Bundle realisiert, das die Nachrichten aller anderen Bundles empfängt und ggf. weiterleitet. Somit müssen sich andere Bundles nicht um die Implementierungsdetails des Web Service sorgen.

Einer der Dienste, die standardmäßig mit dem Bus ausgeliefert werden, realisiert eine Anbindung zum fahrzeuginternen CAN Bus. Hierfür wird das PandaBoard über einen USB-Adapter an den CAN Bus angeschlossen. Ein dezidiertes Bundle empfängt und liest konstant den vom CAN Bus ausgesendeten Bitstrom aus und übersetzt ihn mithilfe der im Bundle hinterlegten CAN-Matrix in konkrete Signale und ihre aktuellen Werte, wie beispielsweise die aktuelle Geschwindigkeit oder den Reifendruck. Auch das Schreiben von Werten auf den CAN Bus ist möglich, hierfür wird ebenfalls die CAN-Matrix verwendet, um Zahlenwerte zusammen mit Metadaten in das CAN-kompatible Bitmuster zu übersetzen.

Da bei der Entwicklung nicht ständig ein echter CAN Bus zur Verfügung steht, wurde für dienstübergreifende Integrationstests ein Java-basierter Simulator entwickelt, der Werte für ausgewählte Signale generiert, über den ASB schickt und auch Schreibzugriffe zulässt. Dies wird über ein Bundle realisiert, das nach außen dieselbe Schnittstelle bereitstellt, intern aber anstatt der Anbindung an das USB-Interface einen einfachen Key-Value-Speicher verwendet.

Prototypische Dienste auf dem Automotive Service Bus

Zur Veranschaulichung der Entwicklung neuer Services auf dem ASB wurden im Rahmen des Projekts u. a. folgende Prototypen gängiger, wie auch innovativer Dienste für Automobile umgesetzt: Navigation, Infotainment sowie ein Empfehlungsdienst. Die prototypischen Dienste verdeutlichen die einfache Implementierung neuer Dienste auf dem ASB, ihre Kommunikation untereinander über das Bus-Prinzip, ihre Vernetzung mit Onlinediensten sowie die Eingliederung in das einheitliche Interaktionskonzept. Durch den Fokus auf minimale Interaktion mit dem Nutzer können auch komplexe Dienste angeboten werden, ohne die Fahrsicherheit zu gefährden.

Navigation: Der Navigationsdienst veranschaulicht die modulare Austauschbarkeit von Funktionalität, die Kommunikation zwischen verschiedenen Diensten über den ASB sowie die innovative Unterstützung ressourcenschonenden Verhaltens. Der Dienst besteht aus mehreren modularen OSGi Bundles, wovon eines die Routenberechnung via Microsofts Bing Maps übernimmt und ohne die Veränderung anderer Bundles, z. B. durch den Routendienst von Google Maps, ersetzt werden kann. Der Dienst nutzt darüber hinaus Echtzeitverkehrsdaten von Bing, die an den Empfehlungsdienst zur Empfehlung alternativer Routen übermittelt werden, der wiederum nach Bestätigung durch den Nutzer die Aufgabe der Berechnung und Navigation der Alternativroute an den Navigationsdienst zurück übergibt. Eine weitere Funktion zur Optimierung des Routings ist die Einbeziehung von topologischen und weiteren Daten, die den tatsächlichen Energieverbrauch auf einer Route genauer approximieren lassen.

Infotainment: Das Infotainment als klassischer Automotive-Service in PKWs wurde durch innovative Möglichkeiten zur Personalisierung und Lokalisierung im ASB neu erfunden. Der Dienst passt sich durch die Integration moderner Onlinedienste wie Last.fm, Spotify und selbstkonfigurierbarer Nachrichtenquellen dem persönlichen Geschmack des Nutzers in den Bereichen Musik und News an und richtet diese an der Länge der aktuellen Fahrt aus, um bestmögliche Unterhaltung und Informationsversorgung zu gewährleisten. Darüber hinaus tauscht sich das Infotainment mit dem Empfehlungsdienst aus, um nach Wunsch des Fahrers auch ortsbezogene Musik abzuspielen (z. B. basierend auf aktuell in der Nähe stattfindenden Konzerten).

Empfehlungsdienst: Der Empfehlungsdienst aggregiert relevante Informationen für den Fahrer aus verschiedenen Quellen und bietet sie proaktiv anderen Services und dem Fahrer direkt in gefilterter Form an. Der Dienst integriert dabei unterschiedlichste Informationen, von nahegelegenen Gastronomieangeboten über Sehenswürdigkeiten bis hin zu Parkmöglichkeiten, basierend auf Kontextdaten wie der aktuellen Position oder dem Navigationsziel. Da Vorschläge proaktiv stattfinden, filtert der Dienst sie u. a. nach Häufigkeit des Auftretens und Akzeptierens durch den Fahrer, um die Fahrablenkung so gering wie möglich zu halten.

Einen Dienst erstellen

Im Folgenden beschreiben wir die Entwicklung eines HTML-basierten Dashboards, das die aktuelle Geschwindigkeit des Autos anzeigt und über das sich die Stufenregelung des Lüfters bedienen lässt. Außerdem wird dort die aktuelle Temperatur am Standort Garching angezeigt. Über ein Menü kann ein alternativer Ort, z. B. der Zielort, ausgewählt werden. Das Dashboard wird über das REST-API des ASB auf die benötigten Daten zugreifen. Die aktuelle Geschwindigkeit sowie die Lüfterregelung sind bereits im ASB integriert. Um die Temperaturdaten zu erhalten, werden wir einen eigenen Dienst entwickeln und diesen im ASB installieren. Wir beginnen mit der Implementierung des Diensts und werden danach die HTML-Oberfläche erstellen. Wir beschränken uns in diesem Artikel auf eine kompakte Beschreibung der wichtigsten Konzepte – ein detaillierter Walkthrough ist im Readme des GitHub Repositories verfügbar.

Projektskelett generieren

ASB-Dienste benutzen Maven als Build-Management-Tool und weisen eine vordefinierte Multiprojektstruktur auf. Zur einfachen Erzeugung dieser Struktur wird der Archetyp de.visiom.carpc/service-archetype bereitgestellt. Nach der Erzeugung des Projekts erhalten wir ein Parent-Projekt mit folgenden Unterprojekten:

service: Dieses Projekt definiert die Metadaten des Diensts. Jeder Dienst verwaltet eine Reihe an Werten, im Folgenden „Parameter“ genannt. Im ASB fest installiert sind bereits die Dienste „Auto“ und „Klima“, die Parameter wie „Geschwindigkeit“ und Lüfterstärke“ verwalten. Dienste senden Nachrichten über einen Nachrichtenbus, wenn sich der Wert eines Parameters ändert. Andere Dienste können nach dem Publish-Subscribe-Prinzip Änderungen für einen bestimmten Parameter abonnieren. Außerdem können sie auch selbst Anfragen auf den Nachrichtenbus legen, wenn sie möchten, dass ein Dienst den Wert einer seiner Parameter ändert.

impl: In diesem Projekt wird das Verhalten des Diensts definiert. In vielen Fällen stellen Dienste eine Schnittstelle zwischen einem externen System und dem ASB dar – diese Anbindung an das externe System, beispielsweise an ein Steuergerät des Autos oder einen REST-basierten Wetterdienst, wird in diesem Projekt realisiert. Des Weiteren wird hier definiert, wie der Dienst auf externe Anfragen nach Änderungen von Parameterwerten (über das REST-API) reagiert und wann er selbst Änderungen auf dem Nachrichtenbus veröffentlicht.

features: Zur Installation des Diensts im Karaf-basierten ASB wird der so genannte Featuremechanismus verwendet. Ein Feature in Karaf beschreibt eine Anwendung anhand eines Namens, einer Versionsnummer sowie einer Menge an Bundles. Durch die Installation eines Features werden alle Bundles, die dieses Feature referenziert, installiert. Das Projekt features dient dazu, ein passendes Feature zu definieren und zu erzeugen. Insbesondere müssen hier die Namen aller externern Dependencies aufgelistet werden.

Definition der Metadaten

Zunächst definieren wir die Metadaten des Diensts im Projekt service. In der Datei OSGI-INF/service.xml geben wir an, welche Parameter unser Dienst anbietet (Listing 1).

 

  
    
    
      
        Berlin
        Garching
      
    
  

Jedem Parameter wird ein fester Datentyp zugeordnet. Abhängig vom gewählten Datentyp können weitere Metadaten angegeben werden, für numerische Parameter beispielsweise der Definitionsbereich oder die Schrittweite. Außerdem kann angegeben werden, ob der jeweilige Parameter „read-only“ ist, also ob der dazugehörige Wert nur vom definierenden Dienst selbst verändert werden kann.

Als Nächstes definieren wir in der Datei OSGI-INF/rest/service.xml, wie diese Parameter über das REST-API abgebildet werden sollen. In unserem Fall können wir Listing 1 wiederverwenden und lediglich die Tags durch und durch ersetzen. In komplexeren Szenarien haben wir hier die Möglichkeit, weitere Beschränkungen analog zum vorherigen Beispiel anzugeben.

Beim Start des Bundles wird mithilfe dieser XML-Dateien durch den ASB ein REST-API erzeugt – hierfür kommt Jersey zum Einsatz. Die XML-Struktur wird in JSON konvertiert und über einen festen Endpoint zur Verfügung gestellt. Der aktuelle Wert des Parameters remoteLocation kann dann (bei einem lokal installierten ASB) über einen GET Request an folgenden URL abgerufen werden: http://localhost:8080/services/weather/parameters/remoteLocation.

Um den Wert eines Parameters zu ändern, muss ein PUT Request mit entsprechendem Payload an dieselbe Adresse gesendet werden. Hängt man an den URL noch den Pfad /subscription an, erhält man außerdem über GET Requests mittels Server-Sent-Events Push-Updates, die bei der Änderung des Werts gesendet werden.

Verhalten des Diensts

Nun implementieren wir das eigentliche Verhalten des Diensts, der Wetterinformationen auf dem ASB bereitstellt. Fassen wir noch einmal die Anforderungen an den Dienst zusammen: In regelmäßigen Abständen soll die aktuelle Temperatur an einem ausgewählten Ort ausgegeben werden. Der Dienst muss also einerseits die aktuelle Temperatur regelmäßig abfragen und ausgeben sowie auf Benutzeranfragen reagieren und darauf achten, dass intern der neue, vom Benutzer gewählte Ort für die Temperaturabfrage verwendet wird.

Für die Ausgabe der Temperatur benutzen wir die von dem ASB-API bereitgestellte abstrakte Klasse ParallelWorker, die abstrakte Methoden für die Ausführung von zu wiederholenden, asynchronen Aufgaben definiert. Der Inhalt der Methode execute() wird automatisch wiederholt in einem neuen Thread ausgeführt – in dieser Methode bietet es sich also an, mit einem externen Web Service zu kommunizieren, um die aktuelle Temperatur zu ermitteln und diese anschließend auf den Bus zu legen. Hierfür kann beispielsweise das freie REST-API des Onlinewetterdiensts OpenWeatherMap verwendet werden. Um zu bestimmen, in welchen Abständen die Methode execute() ausgeführt werden soll, ruft das ASB-Framework die Methode getExecutionInterval() auf und interpretiert den Rückgabewert als eine Angabe in Millisekunden. Indem wir die Methode überschreiben, können wir also diese Abstände bestimmen – wir wählen hier als Wert 10000.

Zur Interaktion mit dem ASB werden von dem ASB-API verschiedene Interfaces und Klassen bereitgestellt. Im Folgenden benötigen wir unter anderem die Interfaces ServiceRegistry und EventPublisher. Hierbei handelt es sich um OSGi-Services, die wir mithilfe des Dependency-Injection-Frameworks Blueprint in unsere Klasse einbinden können.

Vorausgesetzt, dass die Variable currentTemperature die aktuelle Temperatur darstellt, können wir wie in Listing 2 gezeigt ein Update auf den Bus legen.

Service thisService = serviceRegistry.getService("temperatureService");
NumericParameter remoteTemperatureParameter = (NumericParameter)   thisService.getParameter("remoteTemperature");
ValueObject valueObject = NumberValueObject.valueOf(currentTemperature);
ValueChangeEvent valueChangeEvent = ValueChangeEvent.
  createValueChangeEvent(remoteTemperatureParameter, valueObject);
eventPublisher.publishValueChange(valueChangeEvent);

Wir müssen also dem EventPublisher ein Objekt vom Typ ValueChangeEvent übergeben. Zur Erstellung dieses Objekts benötigen wir ein ValueObject, das den neuen Wert repräsentiert, sowie eine Referenz auf den betroffenen Parameter. Diese erhalten wir indirekt über die Referenz auf den dazugehörigen Service, die wir wiederum durch die ServiceRegistry erhalten.

Über das REST-API hat der Benutzer die Möglichkeit, bestimmte Parameterwerte zu ändern, wie beispielsweise hier den ausgewählten Ort für die Temperaturanfragen. Um auf solche Anfragen zu reagieren, implementieren wir eine Klasse, die von der abstrakten Klasse ValueChangeRequestHandler erbt. In der Methode onValueChangeRequest definieren wir das Verhalten, sobald eine REST-Anfrage in Form eines PUT Requests eintrifft (Listing 3).

public void onValueChangeRequest(ValueChangeRequest request, Long requestID) {
  StateValueObject valueObject = (StateValueObject) request.getValue();
  ValueChangeEvent valueChangeEvent = ValueChangeEvent .createValueChangeEvent(request.getParameter(), valueObject);
  eventPublisher.publishValueChange(valueChangeEvent);
  Response response = GenericResponse
    .createGenericResponse(GenericResponse.STATUS_OK);
  commandPublisher.publishResponse(response, requestID,
    request.getParameter().getService());
  String rawValue = valueObject.getValue();
  remoteTemperaturePublisher.setLocation(rawValue);
}

Den CommandPublisher verwenden wir, um rückzumelden, ob die Anfrage erfolgreich bearbeitet und der Wert des entsprechenden Parameters geändert wurde. In komplexeren Fällen können wir hier bei ungültigen Werten nach einer fehlgeschlagenen Überprüfung eine entsprechende Response mit dem Wert GenericResponse.STATUS_ERROR zurückgeben. Zuletzt übergeben wir den neuen Wert noch an die Klasse RemoteTemperaturePublisher. Diese ist für die Veröffentlichung der Updates zuständig und muss nun intern bei der nächsten Anfrage an den Wetter-Web-Service den neuen Ort verwenden.

Auch hier werden CommandPublisher und EventPublisher wieder über Blueprint referenziert. Damit der Handler nicht bei jedem beliebigen Request aufgerufen wird, kann außerdem konfiguriert werden, auf welche Requests welcher Dienste horcht. Da der Nachrichtenbus auf dem OSGi EventAdmin basiert, müssen wir bei der Registrierung des Handlers das passende EventTopic für Requests als ServiceProperty angeben, was in diesem Falle visiom/commands/requests lautet. Um uns auf unseren neuen Dienst zu beschränken, fügen wir als weitere ServiceProperty außerdem den Filter (serviceName=weather) hinzu. Auch die Angabe der ServiceProperties kann über Blueprint in der Datei OSGI-INF/blueprint.xml erfolgen (Listing 4).

Analog zur Klasse ValueChangeRequestHandler gibt es auch die Klasse ValueChangeEventHandler. Diese kann ValueChangeEvents für Parameter bestimmter Dienste abonnieren. Sie wird also aufgerufen, wenn ein Dienst signalisiert, dass sich der Wert einer seiner Parameter geändert hat. Da dies in unserem Szenario aber nicht nötig ist, werden wir nicht weiter auf diese Klasse eingehen.

Installation des Diensts

Um unseren neuen Dienst zu verwenden, müssen wir zunächst den Quellcode des ASB herunterladen und ihn mit Maven kompilieren. Als Resultat bekommen wir im Projekt carPC-assemblies/core-can-test-assembly eine fertige Karaf-Distribution, in der wir unser generiertes Karaf-Feature installieren können.

HTML-Dashboard

Zum Schluss beschreiben wir, wie die Parameter unseres Diensts über ein HTML-Dashboard angezeigt werden können. In einer HTML-Datei definieren wir vier Widgets, passend zu den vier angezeigten Werten: Ein Tachometer für die Geschwindigkeit, ein Drop-down-Menü für die Auswahl des Orts, dessen Temperatur angezeigt werden soll, ein Textlabel für die Temperatur des gewählten Orts sowie ein Spinner für den Innenraumlüfter. Zur Initialisierung der Werte können wir via JavaScript einfache asynchrone GET Requests an die passenden URLs schicken und mit den Rückgabewerten die Widgets entsprechend anpassen. Um auf Push-Updates zu reagieren, können wir mittels EventSource-API Updates für bestimmte URLs abonnieren und über einen Callbackmechanismus die Aktualisierung des passenden Widgets implementieren (Listing 5).

var velocitySource = new EventSource ("http://localhost:8080/services/auto/parameters/geschwindigkeit");
velocitySource.onmessage = function(event) {
  // Refresh widget
};

Bei einer Änderung der Auswahl des Drop-down-Menüs senden wir einen PUT Request mit dem neuen Wert an den entsprechenden URL. Abbildung 3 zeigt das fertige Dashboard im Einsatz.

Abb. 3.: Das HTML-Dashboard im Einsatz

Abb. 3.: Das HTML-Dashboard im Einsatz

Da über das REST-API auch sämtliche Metadaten aller verfügbaren Dienste und ihrer Parameter abrufbar sind, lassen sich solche Dashboards prinzipiell auch dynamisch ohne vorherige Kenntnis über die genauen Namen und Datentypen der Parameter zusammenbauen – ein Ansatz, der im Visio.M-Projekt in der Benutzeroberfläche der Bordkonsole des Autos verfolgt wurde. Dies erlaubt die dynamische Nachinstallation von neuen Diensten ohne Änderungen am Code der Benutzeroberfläche. Durch das standardisierte Messaging-API sind auch keine Änderungen im Code des ASB nötig, um neue Dienste zu entwickeln und bereitzustellen – die Plattform ermöglicht es also, schnell und ohne viel Aufwand Dienste zu entwickeln und zu testen.

Im Rahmen des Visio.M-Projekts hat sich der Automotive Service Bus als flexible und robuste Serviceplattform erwiesen. Das dynamische Programmiermodell erlaubt eine schnelle Entwicklung und Integration von komplexen Diensten und insbesondere auch eine unkomplizierte Anbindung von externen Systemen wie beispielsweise grafischen Benutzeroberflächen. Zusammen mit dem Bundle-basierten Deployment-Mechanismus eröffnet dies die Möglichkeit der Modularisierung der Autosoftware – Dienste wie z. B. Navigation oder Multimedia können jederzeit und ohne Werkstattbesuch wie auf einem Smartphone hinzugefügt, aktualisiert und entfernt werden. Nach dem Ende des Visio.M-Projekts wird der Automotive Service Bus nun unter eine Open-Source-Lizenz gestellt, um anderen Entwicklern die Möglichkeit zu geben, die Plattform für die eigene Forschung zu verwenden.

Aufmacherbild: Car presentation von Shutterstock / Urheberrecht: etraveler

Verwandte Themen:

Geschrieben von
David Soto Setzke
David Soto Setzke
David Soto Setzke hat an der Technischen Universität München Wirtschaftsinformatik studiert und entwickelt als selbstständiger Programmierer Eclipse-Anwendungen. Im Visio.M-Projekt war er maßgeblich an der Konzeption und Entwicklung der Automotive-Service-Bus-Plattform beteiligt.
Thomas Köhn
Thomas Köhn
Thomas Köhn ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Wirtschaftsinformatik von Prof. Dr. Helmut Krcmar an der Technischen Universität München. Er promoviert im Bereich Automotive Services und forscht unter anderem an Nutzerinteraktionen für das Auto der Zukunft.
Maximilian Schreieck
Maximilian Schreieck
Maximilian Schreieck ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Wirtschaftsinformatik von Prof. Dr. Helmut Krcmar an der Technischen Universität München. Er beschäftigt sich mit der optimalen Steuerung von Serviceplattformen, insbesondere im Bereich Automotive.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: