BMW Car IT GmbH Prototyping bei BMW Car IT

Prototyping bei BMW Car IT Die Entwicklung der Elektronik/Software. Vernetzungsgrad Elektronische Einspritzung Check Control Geschwindigkeitsregler Zentralverriegelung ... 1970 1980 1990 2000 Elektronische Getriebe- steuerung Elektronische Klimaregelung ASC Anti Slip Control ABS Anti Blocking Sys. Telefon Sitzheizungssteuerung Autom. Spiegel- abblendung Navigationssystem CD-Wechsler ACC Active Crouse Control Airbags DSC Dynamic Stability Control Adaptive Getriebe- steuerung Rollstabilisierung Xenon Licht BMW Assist RDS/TMC Spracheingabe Notruf ACC Stop&Go BFD ALC KSG 42-Volt Internet Portal GPRS, UMTS Telematics Online Services Blue Tooth Car Office Local Hazard Warning Integrated Safty System Steer/Brake-By-Wire I-Drive Spurhalteunterstützung Personalisierung SW Update Force Feedback Pedal Exponentielles Wachstum: Verdoppelung ca. alle 4 Jahre Weiter Indikation aktueller 7er: 70MB Aktueller 5er: 120MB 7er Nachfolger: 1GB software spielt im fahrzeug eine grosse rolle und wird in zukunft eine noch groessere rolle Spielen ...software wird wahrscheinlich sogar ein unterscheidungsmerkmal zwischen fahrzeugen unterschiedlicher hersteller werden. Allerdings wird die software entwicklung momentan fasst ausschliesslich von zulieferern durchgefuehrt... Bmw hat den trend erkannt und versucht nun kompetenz aufzubauen...eine massnahme war die gruendung der bmw carit.

Prototyping bei BMW Car IT Die Entwicklung der Elektronik/Software. Innovationen im Automobil bei Elektronik/Software 40% der Herstellungskosten fallen auf Elektronik und Software Funktionen verteilen sich beim 7er auf 70 ECU´s 70 MB im aktuellen 7er 120 MB im neuen 5er 1 GB im 7er Nachfolger Software muss eine Kernkompetenz von BMW werden plattformen: Eigene: crusoe, linux, can, most Auftraege: ppc, qnx etc Formfaktoren.

Prototyping bei BMW Car IT Die BMW Car IT GmbH. Neu gegründete Tochterfirma der BMW AG Operativ seit dem 01.01.2002 Aktuell ca. 20 MA – Aufbau bis zu 40-50 MA Mitarbeiterstruktur 90% Akquisition neuer MA aus dem Informatikbereich 10% BMW MA zur Unterstützung der Automobilprozesse und der Schnittstellen zur BMW Entwicklung Neue Organisations- und Entwicklungsumgebung Was benötigt man für eine Automotive Softwareentwicklung 90% ...Hintergrund: Informatiker die mit modernen Softwaretechniken vertraut sind sollten unvoreingenommen die probleme des automotive umfelds untersuchen und loesungen entwickeln. Bewusst keine neue bmw-abteilung...weil man glaubte dass bmw struktur fuer softwareentwicklung ungeeignet Bmw carit pflegt engen kontakt zu universitaeten, vorallem tu-muenchen...wir vergeben viele diplomarbeiten und rekrutieren absolventen Woran an des carit noch etwas fehlt sind die „smalltalk guys“ sprich erfahrung Wichtig: bei carit wird software entwickelt...es werden nicht nur konzepte entwickelt die auf slideware praesnentiert wird.

Prototyping bei BMW Car IT Forschungsgebiete der BMW Car IT Integrierte Datenhaltung Konfigurationsmanagement/Datenhaltung Personalisierung Software Download Diagnose/Test/Systemüberwachung Firewall/Gatewayfunktionalitäten MMI Multimodales, adaptives MMI Online Dienste/Services Individualisierung, Assistenzsysteme Softwareprozesse Querschnitts Thema Natuerlich werden bei carit ausschliesslich fahrzeuspezifische software-themen bearbeitet Datenhaltung: Für viele Dienste notwendig, dass das Fahrzeug ueber sich selbst, d.h konfiguration auskunft geben kann ...heterogene datenhaltung...zentralisierung besser z.B. Produktzyklen bei software wesentlich kleiner... Es geht nicht so sehr um die einzelne Applikation sondern vielmehr um Infrastruktur, d.h. softwareplattformen Software prozesse: Es werden bestehende softwareprozesse untersucht und an das automotive umfeld angepasst...

Prototyping bei BMW Car IT Prototyping Verständnis und Risiko Anspruch an Seriennähe Tiefe Integration mit automotive Hardware keine „fahrenden“ Notebooks Notwendig um Akzeptanz der Entwicklungsabteilungen zu erlangen Risiko: Automotive Hardware nicht a priori vorhanden Hardware unabhängige Architekturen ! plattformen: Eigene: crusoe, linux, can, most Auftraege: ppc, qnx etc Formfaktoren.

Prototyping bei BMW Car IT JAVA Plattformunabhängig Hohe Produktivität etc. Risiken im embedded Umfeld: Höherer Ressourcenverbrauch Laufzeitperformance Aufstartverhalten Verzicht auf Java Funktionen die für den Betrieb NOTWENDIG sind Funktionen sind „einfach“, robust, echtzeitkritisch Bsp.: Gateways, Bus-Master Keine werbeveranstaltung fuer java Auftstarten bereitet uns am meisten kopfzerbrechen Verweis auf die nachfolgenden vortraege. Konkret: j9 mit einem custom profil.

Prototyping bei BMW Car IT Zielsetzung: Zentrale/Offene Plattform Zentrale Plattform Dienst Erinnerung 2. Folie  komplexitaet nur noch schwer beherrschbar Offene softwareplattformen: Natuerlich keine 8bit microcontroller sondern 32bit multipurpose rechner mit beschaenkten resourcen. Optimiert HW: Erweiterbarkeit durch SW Updates kaum gegeben - Dienst Typischerweise eine Funktion je Steuergerät Geschlossenes System: HW ist für die Funktion optimiert

Prototyping bei BMW Car IT Anforderung: Wartbarkeit Lebenszyklus eines Fahrzeugs bis zu 15 Jahren ! Wartung der Softwareplattform Updates (Produktpflege) Erweiterung Herausforderung Sehr große Konfigurationsvielfalt Konfigurationsmanagement Konfigurationsvielfalt: Muss ausserhalb des fahrzeugs verwaltet werden z.b. durch integrationsstufen Zusaetlich muss man komponenten mit einer sinnvollen granularitaet finden die man deployen kann und mit denen man ein vernuenftiges KMM machen kann. Nicht sinnvoll: ansammlung von bytes die andresse xyz gepatcht werden.

Prototyping bei BMW Car IT OSGi (Open Service Gateway Initiative) Historie Start Dezember 1998 als Initiative von SUN, IBM und ERICSSON Heute OSGi Allianz mit über 80 Mitgliedern Ziel Software Infrastruktur die das Deployment von Diensten über Internet auf lokale Netzte und Geräten unterstützt. Umfeld Set Top Boxen Residential Gateways Automotive etc. 2 teil des vortrags

Prototyping bei BMW Car IT OSGi Gesamt Architektur Devices Gateway Szenario: residential gateway. OSGI vs. JINI: Dumme Devices, der Service laeuft auf dem Gateway. Beispiel: eine Heizung hat einen billigen Controller der ueber LON am Gateway haengt. ABER: nicht mit Businessmodelle dahinter langweilen sondern nur das „nackte“ framework anschaun. Service Provider Internet Services

Prototyping bei BMW Car IT OSGi Framework „Deploybare“ Komponenten heißen Bundles Framework bietet Laufzeitumgebung Bundle Operationen: install, uninstall, start, stop Framework überwacht Lifecycle der Bundles Bundles stellen Ressourcen zur Verfügung Framework überwacht resultierende Abhängigkeiten Bundles können Service anmelden Framework verwaltet Service in Registry Security Überprüft Rechte Das Osgi Framework ist eine Laufzeitumgebung + apis die dem entwickler ein programmiermodell in die hand geben.

Prototyping bei BMW Car IT OSGi Framework Bundles sind JAR-Archive und enthalten Klassen Ressourcen (Properties, etc.) Weitere JARs Erweitertes Manifest Native Bibliotheken BundleActivator (designierte Klasse) Abhängigkeiten auf Java Package Ebene Werden im Manifest definiert Bundles exportieren eigene Packages Bundles importieren fremde Packages Mapping auf java

Prototyping bei BMW Car IT OSGi Lifecycle Modell installed Resolved Uninstalled Starting Stopping Active Mapping auf java Nach installation versucht das framework die abhaengigkeiten aufzuloesen

Prototyping bei BMW Car IT OSGi Bundle-Manifest Import-Package: javax.comm, org.apache.log4j; specification-version=1.2.8 Export-Package: de.bmw.most.serial; specification-version=1.0.4 Bundle-Name: Serialmost Bundle-Description: Realisiert Zugriff auf MOST über Optolyzer Bundle-Activator: de.bmw.most.osgi.SerialMostBundleActivator Bundle-Classpath: . Bundle-Copyright: (C) BMW Car IT GmbH 2002 All Rights Reserved. Bundle-Vendor: BMW Car IT Bundle-Version: 1.0.4 Bundle-DocUrl: http://www.bmw-carit.de/ Bundle-ContactAddress: gerd.schaefer@bmw-carit.de Bemerkung: Man sieht dass man packages versionieren kann:

Prototyping bei BMW Car IT OSGi Classpath Framework verwaltet den „globalen“ Classpath Jedes Bundle hat eigenen Classloader nur eigene und importierte Klassen werden geladen Eindeutigkeit der Klassen wird sichergestellt einheitlicher Namespace Keine ClassCastExceptions Dynamischer Package Import seit OSGi Release 3 Manifest: DynamicImport-Package: de.bmw.* Problem: Klassen werden geshared...wie koennen diese geladen werden. Natuerlich mit einem entsprechenden Classloader

Prototyping bei BMW Car IT OSGi Schnittstelle der Bundles zum Framework import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; public class HelloWorldBundleActivator implements BundleActivator { public void start(BundleContext bundleContext) throws Exception { } public void stop(BundleContext bundleContext) throws Exception { Starting/Stopping sind die einzigen Zustände über die Bundle benachrichtigt wird BundleContext: Services registrieren Bundles verwalten

Prototyping bei BMW Car IT OSGi Services Service registrieren: Service erfragen: OSGi ist eine sehr dynamische Umgebung Bundles müssen Abhängigkeiten zu Servicen verfolgen Unterstützung durch Utility ServiceTracker ServiceRegistration inputManagerServiceReg = context.registerService(InputManager.class.getName(), inputManager, null); Service koennen mit properties versehen werden: Bsp.: mehrere cans, die sich nur in der geschwindigkeit unterscheiden...natuerlich selbes interface: Man kann den typ des cans in die properties schreiben. „best practice“: - Inteface eines Service in eigenes Bundle: - die Implementierung in eigenes Bundle ServiceReference serviceRef = context.getServiceReference(InputManager.class.getName()); InputManager inputManager = (InputManager) context.getService(serviceRef);

Prototyping bei BMW Car IT Exkurs: Service orientierte Architektur Allgemein Durch Services lose Kopplung von Komponenten Trennung Abstraktion von Implementierung Bindung an Service zur Laufzeit möglich Warum bei Car IT ? Abstraktion von Hardware Entkopplung von „risikobehafteten“ Komponenten Hardware: 5 Unterschiedliche CAN-Karten. Der Applikation ist das egal: getService(„CAN“) Risikobehaftete Komponenten: Dienst mit dem Konfiguration des Fahrzeugsverwaltet werden kann. Intern benutzt diese Komponente ein objektorientierte datenbank von poet mit jdo schnittstelle. Falls zu langsam: austauschen.

Prototyping bei BMW Car IT OSGi Projekte bei BMW Car IT Multimedia Plattform Kundenwertige Funktionen MP3-Player, Email-Client, etc. Software als Produkt Plattform für Systemdienste Fahrzeuprogrammierung Fahrzeugdiagnose Fahrzeugbetrieb Hardware: 5 Unterschiedliche CAN-Karten. Der Applikation ist das egal: getService(„CAN“) Risikobehaftete Komponenten: Dienst mit dem Konfiguration des Fahrzeugsverwaltet werden kann. Intern benutzt diese Komponente ein objektorientierte datenbank von poet mit jdo schnittstelle. Falls zu langsam: austauschen.

Prototyping bei BMW Car IT OSGi nur für embedded Systeme ? Leichtgewichtig Concern Deployment Bundles können Komponenten enthalten Grundlage für Systeme die auf einen Erweiterungs –oder Pluginmechanismus angewiesen sind ? Equinox (Eclipse) http://www.eclipse.org/equinox/index.html Beispiel Mbeans in Bundles JMX-Server in Bundle Auf den plugin vortrag verweisen!!!

Prototyping bei BMW Car IT Fazit Bedeutung der Software im Fahrzeug nimmt zu. Wartung ist eine zentrale Anforderung an Softwareplattformen im Fahrzeug OSGi ist ein Framework, dass dieser Anforderung gerecht wird Beispiel Mbeans in Bundles JMX-Server in Bundle Auf den plugin vortrag verweisen!!!

Prototyping bei BMW Car IT Vielen Dank für Ihre Aufmerksamkeit