Click here to load reader

Automatisiertes Fahren Notwendiger Wandel der Infrastruktur · PDF fileBeim Cold-Standby werden sie erst bei Ausfall der Hauptfunktion aktiviert, sie verdrängen dann gegebenenfalls

  • View
    212

  • Download
    0

Embed Size (px)

Text of Automatisiertes Fahren Notwendiger Wandel der Infrastruktur · PDF fileBeim Cold-Standby...

  • KLASSISCHE ENTWICKLUNG FUNKTIONIERT NICHT MEHR

    Eine Vielzahl von Fahrerassistenzfunk-tionen ist bereits heute verfgbar. Doch bislang ist es dem Fahrer gesetzlich nicht erlaubt, sich auf diese Systeme hundertprozentig zu verlassen. Im Feh-lerfall (zum Beispiel beim Ausfall eines Sensors) muss er sofort die Kontrolle wieder bernehmen knnen. Zuknf-tige Fahrerassistenzfunktionen werden

    dem Fahrer eine neue Freiheit geben. Es wird erlaubt sein, das Lenkrad loszu-lassen und beispielsweise im Stau bei aktivierter Assistenzfunktion ein Video-telefonat zu fhren, statt seine volle Aufmerksamkeit dem Stauverkehr wid-men zu mssen.

    Systeme wie der von Audi fr das Jahr 2017 angekndigte Staupilot [1] lassen dem Fahrer mehr Zeit zur bernahme. Zunchst wird der Fahrer bis zu 10 s Zeit haben, wieder die Kontrolle ber das

    Automatisiertes Fahren Notwendiger Wandel der Infrastruktur

    Aktuelle Fahrerassistenzfunktionen

    wie selbststndiges Einparken oder

    Stau- und Spurhalteassistenten fr

    die Autobahn sind der erste Schritt

    auf dem Weg zum automatisierten

    Fahren. Doch die aktuellen System-

    architekturen stoen fr die in den

    nchsten Jahren erwarteten Fahr-

    funktionen bereits an ihre Grenzen.

    Die zunehmende Vernetzung der

    Steuergerte untereinander und die

    immer komplexeren Funktionen

    erfordern einen integrativen Sys-

    temansatz bei der Entwicklung und

    eine funktionsbergreifende, fahr-

    zeugweite Softwareplattform. Vor-

    schlge fr knftige Anstze kom-

    men von Elektrobit.

    EB

    AUTOR

    Dipl.-Ing. (M. Sc.) Karsten Hoffmeister

    ist Senior Manager bei Elektrobit

    in Erlangen.

    ENTWICKLUNG FAHERASSISTENZSYSTEME

    42

  • Fahrzeug zu bernehmen. Dabei ist es dem Fahrer explizit erlaubt, whrend der aktiven Assistenzfunktion seine Auf-merksamkeit auf andere Dinge zu len-ken. Er ist damit fr einen eventuellen Fehlerfall nicht mehr verfgbar, was bedeutet, dass das Fahrzeugsystem in dieser Zeit eine gefhrliche Situation ver-meiden oder bewltigen muss. Bereits dieser scheinbar kurze Zeitraum von 10 s erfordert tiefgreifende Vernderungen in der Systemarchitektur. Die Systeme ms-

    sen sich von Fail Silent zu Fail Degra-ded oder sogar Fail Operational ver-ndern. Das bedeutet, dass sie sich im Fehlerfall nicht einfach abschalten dr-fen, ohne die Kontrolle an den Fahrer bergeben zu haben. Sondern es gilt, ein Mindestma an Funktionalitt aufrecht- zuerhalten, um die Sicherheit des Fahr-zeugs und seiner Insassen zu gewhr-leisten, BILD 1.

    Fahrzeuginfrastruktur, Hardware und Software mssen nun so ausgelegt

    sein, dass sie selbst im Fehlerfall arbeitsfhig sind. Fr die ersten Funkti-onen kann dieser Notfall-Funktionsum-fang rudimentr sein, beispielsweise ein sicheres, langsames Anhalten mit Warnblinkanlage. Dieser sichere Zustand ist im Stau ausreichend, im flieenden Verkehr wird das System aber sicher bis zur nchsten Nothalte-bucht weiterfahren oder die nchste Abfahrt nehmen und dort sicher zum Stillstand kommen mssen. Je nach

    01I2016 11. Jahrgang 43

  • geforderter Funktionalit im Fehlerfall sind viele Teilfunktionen beteiligt, mit all ihren Sensoren, Aktoren und Softwareberechnungen.

    Um Funktionen mit der durch das automatisierte Fahren geforderten, oben

    beschriebenen Verfgbarkeit und Zuver-lssigkeit implementieren zu knnen, bedarf es einer vernderten Systemar-chitektur. Denn noch wird ein Steuerge-rt klassisch entwickelt: Die Implemen-tierung der Fahrerassistenzfunktionen

    ist statisch und folgt einem festgelegten Muster (Sensordaten einlesen, Regelsoll-werte berechnen, Aktoren ansteuern). In Zukunft ist die Entwicklung gezwun-gen, Lsungen verstrkt auf System-ebene umzusetzen. Einzelne Steuerge-rte geraten aus dem Fokus: Kommuni-kationspfade mssen sich verndern knnen, Funktionen in Software ms-sen beim Ausfall von Hardware in Echt-zeit auf einer anderen Hardware weiter ausgefhrt werden.

    Hinzu kommen die steigenden Anfor-derungen fr die Umsetzung der eigent-lichen Assistenzfunktionen, deren Kom-plexitt im Verbund der Sensoren und Aktoren stetig zunimmt. Der Bedarf an leistungsstarken Prozessoren, die kom-plexe Berechnungen in Echtzeit durch-fhren knnen, wird grer. Teile der Software mssen zustzlich hohe Sicherheitsanforderungen erfllen, bis hin zum hchsten Sicherheitsniveau ASIL D (Automotive Safety Integrity Level). Die aber sind auf solchen leis-tungsstarken Prozessoren nicht ohne Weiteres umsetzbar. Eine Mischung verschiedener Kontrollerarchitekturen als Ausfhrungsplattform fr zuknf-tige Fahrerassistenzfunktionen ist not-wendig. Im optimalen Fall werden diese heterogenen Rechnerarchitekturen in der Automobilindustrie so umgesetzt, dass die Funktionen hardwareunabhn-gig sind und die Entwickler keine Kenntnisse davon haben mssen, wo und wie ihre Funktionsanteile ausge-fhrt werden.

    VERNDERTE SOFTWAREARCHITEKTUR

    Ein Beispiel fr eine solche Hardware-Plattform ist die Drive PX von Nvidia, bestehend aus einem Infineon-Aurix-Prozessor als Safety-Kontroller und zwei Tegra-K1-Prozessoren als Performance-Kontroller. Die zugehrige Software lie-fert Elektrobit mit der Basissoftware

    BILD 2 Softwareschichten in Kombination mit leistungsstarken Hardware-Plattformen (zum Beispiel die Drive PX von Nvidia) bilden die Basis fr einen integrativen Systemansatz ( EB)

    BILD 1 Die unter-schiedlichen Stu-fen zum automati-sierten Fahrzeug erfordern eine Ver-nderung in der Systemarchitektur ( EB)

    ENTWICKLUNG FAHERASSISTENZSYSTEME

    44

  • 01I2016 11. Jahrgang 45

    2015

    Cooling andThermal Management

    U5855A TrueIR Thermal Imager

    Keysight Technologies, Inc. 2015

    Nur fr begrenzte Zeit: 5 Jahre Garantie KOSTENLOSwww.keysight.com/find/TrueIRimager

    U5855A U5856A U5857A

    160 x 120 (19.200 Pixels)

    320 x 240 (76.800 Pixels)

    Temperatur-Messbereich 20 bis +350 C 20 bis +650 C 20 bis +1200 C

    0,07 C bei 30 C

    Gehen Sie Wrmeproblemen auf den Grund mit den Keysight TrueIR Wrmebildkameras. Vermeiden Sie ungewollte Ausfallzeiten mit diesem leichten, benutzerfreundlichen, tragbaren Gert. Mit der hohen kam-

    Ausfallzeiten knnen Sie sich nicht leisten aber die Keysight TrueIR Wrmebildkamera schon.

    Keysight TrueIR Wrmebildkamera!

    5 Jahre Garantie kostenlos.

    Kontakt: +49 (0)7031 464 6333 0800 6270999 (kostenfreie Rufnummer fr Anrufe aus Deutschland)

    Agilents Electronic Measurement Group heit jetzt Keysight Technologies.Embedded World 2016 Hall 4 / Booth no. 208Embedded World 2016 Halle 4 / Stand Nr. 208

  • EB tresos, die in diesem Fall sowohl auf dem klassischen Autosar basiert als auch auf einer Variante dieses Stan-dards, die erstmals im Sinne des neuen Adaptive Autosar mit einem dynami-schen Betriebssystem (in diesem Fall Linux) auf dem Tegra-Prozessor die Laufzeitumgebung bildet.

    Als Anwendung luft auf diesem Sys-tem ein von EB entwickeltes Framework fr Fahrerassistenzanwendungen. Die-ses Framework implementiert Module zur Fusion von Sensordaten, Trajekto-renplanung und -regelung sowie Stan-dardmechanismen zur Synchronisation und Koordination mehrerer Fahrerassis-tenzfunktionen im Rahmen eines Situa-tions- und Entscheidungs-Moduls. Die im Framework laufenden Assistenz-funktionen wie eine automatische Einparkfunktion, sttzen sich auf die Sicherheitsmechanismen, die von der darunterliegenden Infrastruktur zur Verfgung gestellt werden: Funktiona-les Management und die berwachung der Einhaltung funktionaler Randbe-dingungen werden als Softwaremodule rckwirkungsfrei auf dem Safety-Kon-troller ausgefhrt, BILD 2. Das gewhr-leistet einen zuverlssigen Betrieb. Zustzlich ist auf einem Steuergert gleichzeitig die Ausfhrung von Soft-ware mit hohem ASIL-Sicherheitslevel mglich sowie von nicht sicherheits-kritischen Algorithmen mit hohen Leistungsanforderungen (sogenannte Mixed-Criticality-Systeme).

    Auf dynamischen Softwareplattfor-men, wie die von Elektrobit auf der Drive PX umgesetzte EB-tresos-Umge-bung, sind die Kommunikationswege zwischen den einzelnen Funktionen transparent und flexibel. Ob Anwen-dungen ber eine Classic Autosar RTE mit ihrer Umgebung auf demselben Steuergert kommunizieren oder diese Kommunikation ber die passenden Softwareschichten und Kanle zu belie-bigen Sendern und Empfngern dyna-misch auf- und abgebaut wird, ist fr die Anwendung zuknftig nicht rele-vant. Diese Flexibilitt in der Kommu-nikation ermglicht die Umsetzung von Redundanz-Mechanismen in der Funktionsausfhrung fr Fail-Opera-tional-Systeme, beispielsweise durch die Umsetzung von Hot- oder Cold-Standby-Funktionalitt. Das bedeutet, dass Funktionen redundant auf einer weiteren Ausfhrungsumgebung im

    Standby sind und dann aktiviert wer-den, wenn die Hauptfunktion ausfllt. Beim Cold-Standby werden sie erst bei Ausfall der Hauptfunktion aktiviert, sie verdrngen dann gegebenenfalls un- wichtigere Anwendungen auf diesem Steuergert. Beim Hot-Standby laufen sie parallel zur Hauptfunktion, was ein sehr schnelles Umschalten ermglicht, jedoch dauerhaft Ressourcen wie CPU-Zeit und Speicher bindet. Damit einher geht ein dynamisches Umleiten der Sen-sor- und Aktor-Signale, je nach Ausfh-rungsort der Funktion, BILD 3.

    In einer Steuergertearchitektur, die diese Dynamik zulsst, kann man durch intelligente Verknpfung mehre-

    rer solcher Steuergerte auf der Sys-temebene eine Ausfallsicherheit von dedizierten Funktionsumfngen gewhrleisten. Hierzu mssen natrlich auch physikalische Redundanzen in der Stromversorgung und in den Kom-munikationskanlen umgesetzt wer-den. Mit dem Einzug von Ethernet und mehreren Batterien, beispielsweise in einem Elektrofahrzeug, sind hier erste Grundlagen vorhanden, die es ermg-lichen werden, eine Software-Infrastru-ktur-Plattform fr zuknftige hoch-auto matisierte Fahrfunkt

Search related