PDF herunterladen

Technische Fachartikel

zur Entwicklung von Embedded Electronics

Mehr Informationen

www.vector.com

6. Auflage | Deutsch

V 6.0 07/2016 - pressbook_de

Besuchen Sie unsere Website für: > News > Produkte > Demo Software > Support > Schulungen > Adressen

Vector – Automotive. Embedded. Engineering.

Liebe Leserin, lieber Leser,

Messen/Testen/Tools Funktionale Sicherheit

Alle Bilder: Vector Informatik GmbH

die Darstellung von besonderen Herausforderungen und deren Lösungen, aber auch die Vermittlung grundlegender technologischer Konzepte der E/E-Entwicklung ist uns ein besonderes Anliegen. In Fachartikeln und Anwenderberichten stellen Experten von Vector, häufig in Zusammenarbeit mit unseren Kunden, die vielfältigsten Aspekte unserer Arbeit vor. Damit zeigen wir Ihnen mögliche Lösungen für Ihre täglichen Herausforderungen in der Elektronikentwicklung auf.

Safety systematisch verankern

Vor Ihnen liegt heute die 6. Ausgabe der Sammlung von Vector Fachartikeln. Über 30 neue Beiträge sind seit der letzten Auflage vor 18 Monaten neu hinzugekommen. Die Themen bilden die aktuellen Trends unserer Branche ab: neben Embedded Software Entwicklung im AUTOSAR-Umfeld sind dies vor allem funktionale Sicherheit, Cyber Security und Elektromobilität. Wir wünschen Ihnen eine anregende Lektüre.

Stuttgart, Oktober 2016

Stand: Oktober 2016 Verantwortlich für den Inhalt: Vector Informatik GmbH, Stuttgart Alle genannten Produktnamen sind entweder eingetragene oder nicht eingetragene Marken ihrer jeweiligen Inhaber. Die ständige weltweite Verfügbarkeit aller Produkte oder Dienstleistungen wird nicht gewährleistet. Irrtümer und Auslassungen vorbehalten. Nachdruck nur mit schriftlicher Genehmigung der Vector Informatik GmbH, Stuttgart. Bitte beachten: einige der genannten Weblinks in diesem Artikel können veraltet sein. Sie waren zum Zeitpunkt der initialen Fachartikel-Veröffentlichung gültig. Die vorangegangen Auflagen 1–3 sind ausschließlich auf Englisch erschienen. Illustration & Design: Cirek Mediendesign, Stuttgart, Germany

Dr. Thomas Beck

Modellbasierte funktionale Sicherheit in der E/E-Systementwicklung

Um funktionale Sicherheit als integralen Bestandsteil der Entwicklung von E/E-Systemen zu ermöglichen, sind neue Ansätze nötig. Schließlich gilt es, alle Ebenen von Systementwürfen zu berücksichtigen und sicherzustell dass die Sicherheitsziele der Systeme nachweislich und gemäß der „Safety-Norm“ ISO 26262 umgesetzt sind Autoren: Albert Habermann und Dr. Simon Burto

D

ie Einführung der internationalen Norm ISO 26262 zur funktionalen Sicherheit von elektrisch/elektronischen Systemen im Automobil hat das Bewusstsein für dieses Thema in der Industrie deutlich verstärkt. Viele Hersteller und Lieferanten suchen daher nach Ansätzen, die Vorgaben aus der Norm pragmatisch und effizient zu erfüllen und gleichzeitig der steigenden Komplexität sicherheitsrelevanter Funktionen gerecht zu werden. Das Entwickeln sicherheitskritischer Systeme führt im Vergleich zu herkömmlichen Entwicklungen zu erhöhten Aufwänden. So sind zusätzliche Aktivitäten bei gleichbleibenden Rahmenbedingungen hinsichtlich Zeitplänen, Ressourcen und Kosten, unvermeidbar. Bestehende Entwicklungs-, Analyse- und Testmethoden sowie die dazugehörenden Werkzeuge sind oft fragmentiert und lassen sich nur mit großem Aufwand in einen durchgängigen Prozess integrieren.

Ganzheitliche Betrachtung von Systemarchitekturen Eine wesentliche Forderung aller gängigen Sicherheitsnormen im Automotive- sowie im Non-Automotive-Bereich (zum Beispiel IEC 34

34_Vector.indd 34

Automobil ElEktronik 02/2012

61511 Prozessindustrie, IEC61513 Kernkraftwerke, EN 50128 E bahn) besteht darin, das Erfüllen der Systemsicherheitsziele d das entwickelte Systemkonzept nachzuweisen. Sicherheitsziele den typischerweise durch Gefährdungs- und Risikoanalysen au funktionalen Systemebene identifiziert. Die aus den Sicherheitsz abgeleiteten funktionalen und technischen Sicherheitsanforderu sind dann Systemkomponenten zuzuordnen. Das korrekte Umse dieser Sicherheitsanforderungen ist durch eine geeignete Kom nation von Reviews, Analysen und Tests sicherzustellen. Das Erreichen der Systemsicherheitsziele hängt von einer Vie verschiedener Faktoren ab. Ein Beispiel hierfür sind fehlerhaft prog mierte Software-Funktionen oder zufällige Hardware-Fehler in k schen Komponenten. Solche isolierten Fehler lassen sich mit gäng Entwicklungsmethoden, wie in der ISO 26262 empfohlen, relativ fach vermeiden oder zumindest entdecken und damit beherrsc Problematischer wird es, wenn eine Kombination verschiedener temfaktoren aus unterschiedlichen Architekturebenen die Sicherh ziele beeinflusst. Mit herkömmlichen, dokumentenbasierten Entw

www.automobil-elektron

Inhalt



Basics, Tipps und Tricks beim Einsatz von CAPL Teil 1: CAPL-Basics

3/4



Basics, Tipps und Tricks beim Einsatz von CAPL Teil 2: CAPL besser verstehen und effektiv anwenden

3/8

1/0



Basics, Tipps und Tricks beim Einsatz von CAPL Teil 3: CAPL für Fortgeschrittene

3/10

Datenkommunikation im Automobil Teil 2 – CAN

1/6

Wege vom klassischen CAN zum verbesserten CAN FD

1/12

Schnelle Wege zur Restbussimulation Virtuelle Netzwerke ohne Programmier-Know-how erstellen

3/14







Schnelles Messen und Reprogrammieren CAN FD liefert hohe Bandbreiten bei moderaten Kosten

1/16



Case Study: GETRAG

3/17

Datenkommunikation im Automobil Teil 3 – LIN

1/22

Steuergeräte modellbasiert entwickeln Software-Simulation mit MATLAB/Simulink und CANoe

3/18

Serielle Bussysteme – LIN



Serielle Bussysteme – FlexRay

Datenkommunikation im Automobil Teil 4 – FlexRay

1/28

Für schweres Gerät Drahtlose Analyse in einer CAN-Multiprotokoll-Umgebung

1/32

Lückenlose Kommunikationstests in der VAG-Steuergeräteentwicklung Identische Testumgebungen für OEM und Zulieferer

3/22

Serielle Bussysteme – Automotive Ethernet



Case Study: Fraunhofer

3/25



Luftbrücke für Busdaten Synchrone Aufzeichnung drahtlos übermittelter Busdaten mehrerer Testfahrzeuge

1/36



Prüfstand für komplexen Steuergeräteverbund Individualität von Omnibus-Ausstattungen erfordert flexibles Testsystem

3/26

Ethernet und IP im Kraftfahrzeug Neue Anforderungen an das Entwicklungswerkzeug durch den Ethernet- und IP-Einsatz

1/40

Hardware-Simulation bei der Unimog-Reifendruckregelanlage Zeitersparnis und neue Möglichkeiten durch Steuergerätetests am Modell

3/30





Case Study: ZF TRW

3/33

Neue Werkzeuge für Automotive Ethernet Flexible Interfaces und Softwarewerkzeuge für die Steuergeräteentwicklung

1/44



ECU-Test mit XCP-Unterstützung Direkt in das Steuergerät blicken

3/34



Validierung von IP-Netzelementen Neue Aspekte der Restbussimulation für Netzwerke mit SOME/IP

1/50



Effiziente Steuergerätetests mit dem Fehlerspeicher

3/36





Case Study: Bertrandt

3/39



AUTOSAR lernt Ethernet

1/52



Wie Sie Steuergeräte mit flexiblen Prüfsystemen effizient testen

3/40



Neue Kommunikationsarten in der Automobilvernetzung Ethernet und CAN FD sind die Wegbereiter

1/56



Porsche validiert Gateway-Steuergeräte automatisch Echtzeitanalyse bei den Erprobungsfahrten ergänzt Labortests

3/44

1/62



Leichter Einstieg in die Busanalyse

3/48



Testfahrten lückenlos Aufzeichnen Datenlogger erfassen zuverlässig Fahrzeugdaten

3/50

Diagnose

Automatische Validierung der Diagnoseservices bei General Motors Europe

4/0



Die Standard-Mischung macht’s Diagnose mit AUTOSAR und ODX – Teil 1: Diagnose mit AUTOSAR

4/6

Firmenprofil

Vector – das Unternehmen

Management Interview

Trends 2016: Brauchen wir autonomes Fahren? Ausblick von Dr. Thomas Beck (Mitglied der Geschäftsführung)

Serielle Bussysteme

Datenkommunikation im Automobil Teil 1 Architektur, Aufgaben und Vorteile serieller Bussysteme

Serielle Bussysteme – CAN

Für den nötigen Durchblick Automotive-Ethernet-Schnittstelle Serielle Bussysteme – ITS-G5

Testen von C2X-Applikationen Anforderungen an Testwerkzeuge am Beispiel Baustellenwarnung

1/66



Car2x – Von der Forschung zur Serienentwicklung Wie Fahrzeughersteller und Zulieferer Car2x-Serienprojekte erfolgreich abschließen

1/70

Serielle Bussysteme – MOST

Datenkommunikation im Automobil Teil 5 – MOST

1/74

Die Standard-Mischung macht’s Diagnose mit AUTOSAR und ODX – Teil 2: ODX im AUTOSAR Entwicklungsprozess

4/10



Diagnosewerkzeuge für WWH-OBD Umsetzung der neuen Anforderungen für OEMs und Zulieferer

4/14

Serielle Bussysteme – K-Line K-Line: Flexible Lösungen für ein klassisches Protokoll Vom genauen Monitoring bis zur Datenmanipulation für generische Byte-Protokolle

1/78

Entwicklung verteilter Systeme

Design und Analyse funktional sicherer Hardware in einem EBS

2/0



Von den Diagnose-Requirements zur Kommunikation

4/16

Nutzung von Entwicklungsdaten bei der Wartung Von der Definition neuer Features bis in die Werkstatt

2/6



Case Study: KTM

4/19



So liegt der Kabelbaum richtig Gemeinsame Entwicklung von Elektrik/Elektronik und Mechanik im Fahrzeugbau



Diagnose aus der Ferne Fahrzeuge weltweit interaktiv diagnostizieren

4/20

2/14



Case Study: Opel

4/23

Steuergeräte-Test

In Rekordzeit ZF TRW testet weltweit Steuergeräte mit neuem Konzept

3/0



Datengetriebene automatisierte Diagnose-Applikations-Validierung

4/24

Diese Artikel wurden seit der letzten Pressbook-Auflage hinzugefügt.

Inhalt

Steuergeräte-Kalibrierung

Trends bei der Steuergeräte-Applikation

5/0

Automotive Cyber Security

Verschlüsselte Signalübertragung mit AUTOSAR in einem CAN-FD-Netzwerk

8/0



Große Messdatenmengen rationell und flexibel analysieren

5/4



Integrierte Entwicklung von Safety- und Security-Anforderungen

8/4



Verifikation von Fahrerassistenzsystemen im Fahrzeug und Labor

5/8

Kalibrierdatenverwaltung: Ein Puzzlespiel? Effizienzsteigerung bei der Steuergeräte-Kalibrierung

5/12

Cyber Security mit überschaubarem Aufwand umsetzen Funktionale Sicherheit braucht Informationssicherheit

8/10





Security mit Sicherheit: Praxisbeispiel für automotive Systeme

8/14



Ein Ritt auf der Rasierklinge Optimale Parametrierung eines Motorsteuergerätes für Rennsportanwendungen

5/16



Praxiserfahrungen zur Anwendung von Cyber Security Risiko-orientierte Methodik

8/20



Case Study: HOERBIGER

5/19



Analyse des Modellverhaltens bei der ECU-Funktionsentwicklung

5/20



Case Study: BMW

5/23



Hochgeschwindigkeitsmessungen für Elektro- und Hybridfahrzeuge Neue Messkonzepte für hohe Datenraten und kurze Messraster



Induktives Laden für E-Fahrzeuge Elektromobilität ISO/IEC-15118-Standardisierung

9/0

Smart-Testing für Smart-Charging Durchgängige Testfallabdeckung

9/4

5/24



5/27

Smart Charging Ein Schlüssel zur erfolgreichen Elektromobilität

9/8

Case Study: Bosch



AUTOSAR-Steuergeräte-Software mit XCP analysieren Komfortable Fehlersuche durch Erweiterung der AUTOSAR-Basissoftware



Steuergerätetest für E-Fahrzeuge Intelligentes Messen der dynamischen Stromaufnahme

9/12

6/0



Case Study: FAW



Case Study: ZSW

9/15

6/5

Plug-and-Play-Lösung für AUTOSAR-Software-Komponenten

6/6



Neue Bus-Schnittstellen für die Elektro-/Hybrid-Fahrzeugentwicklung

9/16



AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector

6/12



Elektromobilität auf dem Vormarsch 626,6 Kilometer unter Realbedingungen mit einer Batterieladung

9/20



Case Study: Entwicklung eines Referenzsystems für AUTOSAR-Steuergeräte und Systemuntersuchungen



AUTOSAR-Methodik in der Praxis Die Partner Daimler, Hella und Vector berichten über Erfahrungen aus der Einführung der AUTOSAR-Entwicklungsmethodik

6/20



Komfortables Laden Intelligentes Laden mit MICROSAR IP ermöglicht Ladevorgänge und einfache Bezahlung

9/24

6/19

OBD meets AUTOSAR OBD-Funktionen in der AUTOSAR-Basissoftware vereinfachen die Diagnoseimplementierung

6/24

Entwickeln mit J1939 Steuergeräte-Vernetzung in Nutzfahrzeugen

10/0



Offene Protokolle – SAE J1939

Quo Vadis SAE J1939 Überblick über die Standardisierungsaktivitäten bei SAE J1939

10/6



AUTOSAR im Nutzfahrzeug

6/26



Integration von J1939-Systemen in der Praxis

10/10



AUTOSAR – Für alles gewappnet?

6/30

Komfortable Konfiguration von AUTOSAR-Steuergeräten

6/34

CAN und J1939 unter extremen Einsatzbedingungen Garantierte Funktion bei Kälte, Eis und Schnee

10/14





AUTOSAR goes Multicore – mit Sicherheit

6/38



Entwicklungstrends in der NFZ-Vernetzung Erfolgsfaktoren bei der Elektronikentwicklung

10/20



AUTOSAR-compliant Development of an In-car Radio Product Using MICROSAR for the European Market

6/42



Case Study: BOMAG

10/24

High-Rate Task Scheduling within AUTOSAR

6/46

Offene Protokolle – ISOBUS

Gesicherte Kompatibilität Automatische Interoperabilitätstests für ISO-11783-Systeme

10/25



Neue Chancen mit AUTOSAR

6/50

Safety systematisch verankern Modellbasierte funktionale Sicherheit in der E/E-Systementwicklung

7/0

Neue Wege beim Testen Simulationen ersetzen unflexible und zeitintensive Praktiken beim Testen von Isobus-Task-Controllern

10/28

Funktionale Sicherheit





Koexistenz von sicherer und nicht-sicherer Software auf einem Steuergerät

7/4



Mit automatisiertem HiL-Testsystem zur ISOBUS-Funktion von Landmaschinen 10/32

Mixed-ASIL-Systeme praktisch realisieren Ein zertifiziertes Betriebssystem vereinfacht das Entwickeln sicherheitsrelevanter Software

7/8



Entwicklung eines kooperativen Traktorgespanns

10/36



Offene Protokolle – CANopen

Prototyping und Test von CANopen-Systemen

10/40

Durchgängige Realisierung von Steuergerätesoftware nach ISO 26262

7/12

Beratung

Lean Requirements Engineering

11/0



Sieht so die Zukunft aus? Fehlertolerante Systemarchitekturen mit AUTOSAR-Basissoftware realisieren

7/18



Improving Engineering Efficiency with PLM/ALM

11/4



AUTOSAR

Diese Artikel wurden seit der letzten Pressbook-Auflage hinzugefügt.

Vector the Company

Vector – das Unternehmen Informationen im Überblick

Das Vector Portfolio Vector Informatik ist der führende Hersteller von Soft-

Entwicklung verteilter Systeme

Steuergeräte-Test

Werkzeuge und Dienstleistungen für den Entwurf und die

Werkzeuge und Dienstleistungen, die Steuergeräte in allen

Entwicklung von Steuergeräte-Netzwerken.

Entwicklungsphasen testen, die Funktionalität von Proto-

Werkzeuge zur Simulation, Analyse und zum Test der Netz­

typen prüfen oder Regressions- und Konformitätstests

werkkommunikation.

durchführen. Hauptprodukte: CANoe, CANalyzer, Daten-

Hauptprodukt: PREEvision

logger, vTESTstudio, VT System

Diagnose

Steuergeräte-Kalibrierung

Werkzeuge und Dienstleistungen zur Beschreibung, Imple-

Werkzeuge, mit denen der Zugriff auf das Steuergerät zur

Automobilindustrie. Weltweit setzen Kunden aus der Auto-

mentierung sowie Validierung und Test der Diagnosefunk-

Laufzeit möglich ist. Erfassung und Modifikation von Mess-

mobil-, Nutzfahrzeug-, Luftfahrt-, Transport- und Steuer-

tionalitäten in Fahrzeugsteuergeräten.

daten und Parameter mit dem Ziel der Optimierung von

ungstechnik auf die Lösungen und Produkte der unabhän-

Hauptprodukte: CANdelaStudio, CANoe.DiVa, Indigo, vFlash

ware-Werkzeugen und -Komponenten für die Entwicklung elektronischer Systeme und deren Vernetzung mit verschiedensten Systemen von CAN bis Automotive Ethernet. Seit 1988 ist Vector der Partner von Herstellern und Zulieferern der Automobilindustrie und verwandter Branchen. Vector Tools und Services verschaffen Ingenieuren den entscheidenden Vorteil, um ein anspruchsvolles und hochkomplexes Themenfeld so einfach und überschaubar wie nur möglich zu machen. Jeden Tag aufs Neue arbeiten Vector Mitarbeiter an den elektronischen Innovationen der

Mitarbeiter > 1.700 weltweit

Niederlassungen 20 Standorte in 12 Ländern

Steuergeräte-Algorithmen. Hauptprodukte: CANape, vCDM, VX1000, vSignalyzer, vADASdeveloper

gigen Vector Gruppe zur Entwicklung von Technologien für die Mobilität von Morgen. Zuverlässiger Partner mit Qualität Unser Ziel ist Exzellenz in allen Bereichen! Die Vector Prozesse werden weltweit regelmäßig bewertet und zertifiziert und erfüllen erfolgreich die aktuellen Standards: >>Qualitätsmanagement - ISO 9001 >>Automotive SPICE >>Funktionale Sicherheit - ISO 26262 >>Bekannter Versender

Kunden > 6.400 Firmen in 60 Ländern

Verbände Teilnahme in 15 Ausschüssen

Steuergeräte-Software

Beratung

Embedded Software, die im Steuergerät eingesetzt wird:

Vector bietet Ihnen Beratung zur Optimierung der tech-

Basissoftware für AUTOSAR; Echtzeit-Betriebssysteme;

nischen Produktentwicklung, der zugehörigen Geschäfts-

Kommunikationsmodule für z.B. CAN, LIN, FlexRay, MOST

prozesse und Werkzeuge, sowie zur erfolgreichen Um­­setzung

und Ethernet; Software zur Re-Programmierung von

von Veränderungen.

Steuergeräten; Entwicklungsdienstleistungen für Soft-

Unser Angebot: Consulting Services, Engineering Services

warekomponenten. Hauptprodukte: MICROSAR, Embedded Software, VC Controller, Customer Projects

TOOL-HERSTELLER, DIENSTLEISTER

TOOL-HERSTELLER, DIENSTLEISTER

Dr. Thomas Beck, Vector Informatik:

Brauchen wir autonomes Fahren? W er sich über die Trends der kommenden Jahre Gedanken macht, kommt dieser Tage am „autonomen Fahren“ nicht vorbei. Dieses Thema ist omnipräsent und dominiert alle anderen. Die Luftfahrt hat dieses Problem bereits gelöst, aber in einem deutlich einfacheren Umfeld und mit verbindlichen gesetzlichen Vorschriften zur Ausrüstung von Zivilflugzeugen. Jedes Flugzeug muss einen Transponder (Sekundärradar) an Bord haben, der die anderen Luftverkehrsteilnehmer über die Flughöhe informiert. Moderne Transponder, die von 2017 an verbindlich sind, senden weitere Daten wie Geschwindigkeit, Position, Kurs und Sink- oder Steigrate. Aus diesen Informationen können sich andere Verkehrsteilnehmer ein vollständiges Bild des Luftraums machen, da oberhalb von 3000 bzw. 5000 Fuß (rund

915 bzw. 1524 Meter) keiner ohne Transponder unterwegs ist. Der Luftraum in diesem Bereich wird zusätzlich noch von Luftraum-Controllern durch das sogenannte Primärradar überwacht.

Straßenverkehr sicherer machen

Die Automobilindustrie hat ein deutlich schwierigeres Problem zu lösen. Eine 100-prozentige Abdeckung mit gesetzlich vorgeschriebener technischer Ausrüstung, wie Transpondern, ist unsinnig, da es noch genügend andere Verkehrsteilnehmer gibt, die ohne Technik unterwegs sind. Zu allem Übel muss man sich am Boden an die vorgesehenen Verkehrswege halten. Es bleibt dem Automobil nichts anderes übrig, als sich mittels Sensoren wie Radar, Lidar und Kameras über komplexe Algorithmen ein Modell der Umgebung zu machen, um dann unter Anwendung ebenso komplexer Strategie- und Planungsalgorithmen sich einen Weg durch das Verkehrsgetümmel zu suchen. Ich möchte zum Thema „Weltverstehen durch Computer“ Richard Szeliski, einen Pionier im Bereich der Bildverarbeitung, zitieren, der 2011 Folgendes geschrieben hat: „However despite of all the advances (er bezieht sich auf die vielen Fortschritte im Bereich der Bildverarbeitung) the dream of having a computer interpret an image at the same level as a two-year-old remains elusive.“ Aber wahrscheinlich muss man auch nicht die gesamte Welt verstehen, um ein Fahrzeug autonom durch den Verkehr zu steuern. Aber ungeachtet der Fragen, inwieweit sich Dr. Thomas Beck ist seit 2001 Gesellschafter und Geschäftsführer bei Vector Indie technische Herausforderung in ihrer Vollenformatik. Zuvor war er von 1997 an Geschäftsführer der ETAS-Gruppe. aus Elektronik automotive 1.2016

dung lösen lässt oder inwieweit man in jeder Situation autonom fahren möchte, produzieren die Entwicklungstätigkeiten zum autonomen Fahren Ergebnisse, die den Straßenverkehr durch verbesserte Assistenzfunktionen wesentlich sicherer machen werden. Und diese Entwicklungstätigkeiten bringen die Automobilindustrie und mit ihr die E/E-Branche – und das ist mindestens genauso wichtig – ein gutes Stück näher an die IT-Branche, die heute von Firmen wie Google oder Apple dominiert wird. Vor diesem Hintergrund möchte ich die eingangs aufgeworfene Frage mit einem uneingeschränkten „Ja, wir brauchen autonomes Fahren“ beantworten. Die Entwicklung der dafür benötigten Technologie wird die Automobilindustrie im Umgang mit Software oder IT auf ein höheres, dringend benötigtes Kompetenz-Level heben. In eine vergleichbare Richtung treiben die Entwicklungen im Bereich Konnektivität – die Verbindung des Fahrzeugs mit Servern im Internet. Um die Vision vom autonomen Fahren umzusetzen oder die Potenziale einer Verbindung mit einem Server Backbone auszuschöpfen, müssen wir alle flexibler, sicherer und schneller werden: Künftige Funktionen und Algorithmen benötigen leistungsfähigere Prozessoren und Betriebssysteme mit höherer Funktionalität. ➜ E/E-Systeme der Zukunft müssen im Feld möglichst einfach und robust geändert werden können. ➜ Höhere Datenmengen und sich über die Lebensdauer des Fahrzeugs ändernde Dateninhalte sind zu erwarten. ➜ Das Fahrzeug wird Teil des Internets (IoT). Das Fahrzeug ist vor Angriffen zu schützen; die zu übertragenden Daten müssen gegen unberechtigten Zugriff geschützt werden. ➜ Über das Internet werden laufend neue Services angeboten. Auch das sich bereits im Feld befindliche Fahrzeug muss durch geänderte Software befähigt werden, neue Services zu nutzen oder verbesserte oder sicherere Funktionen anzubieten.

Anforderungen erfüllen Dieser Anforderungsliste dlassen sich die Technologien und Konzepte gegenüberstellen, die eine wichtige Rolle bei der Realisierung der Anforderungen spielen. Nachfolgen sind einige genannt, zu denen Vector beitragen wird: ➜ AUTOSAR Adaptive Plattform ➜ Ethernet mit dynamischen Kommunikationskonzepten und CAN FD ➜ On-Board-Flashen und Remote Software Update ➜ Eine noch zu standardisierende oder OEM-spezifische Service-Schnittstelle im Auto und am Server Backbone, die es ermöglicht, Services des Fahrzeugs vom Backbone oder Services eines Backbone im Auto zu nutzen. Alle Technologien und Konzepte treiben uns in die gleiche Richtung: Sie bringen die Automobilindustrie in Richtung IT.

AUTOSAR Adaptive Platform Die AUTOSAR Adaptive Platform mit dem Adaptive AUTOSAR API soll Steuergeräte (ECU) – oder Rechnerplattformen – im Fahrzeug für die Anforderungen der Zukunft fit machen. Sie wird nicht auf den „Deeply Embedded“-ECUs zum Einsatz kommen, die Regelungs- und Steuerungsfunktionen übernehmen. Ihr Einsatzgebiet werden die Rechner im Fahrzeug sein, die zum Beispiel Services aus dem Internet nutzen, taktische Algorithmen für Fahrmanöver rechnen oder dem Nutzer eine intuitive Bedienung ermöglichen und so mehr Flexibilität vom darunterliegenden Betriebssystem fordern. Das dynamische Erzeugen von Tasks oder die temporäre Allokation zusätzlicher Speicherbereiche sind einige Beispiele. Dazu ist geplant, eine Untermenge des POSIX-Standards (IEEE 1003.13) zu definieren.

Ethernet und CAN FD Die im Fahrzeug zu bewegenden Datenmengen steigen. Daher sind Bussysteme mit höherer Bandbreite notwendig. CAN FD und Ethernet werden daher ihren Einsatz in den Fahrzeugnetzwerken kontinuierlich verbreitern. Der zweite Aspekt ist die Flexibilisierung der Kommunikation. Heute sind alle Kommunikationsbeziehungen inklusive der Daten für ein E/E-Netzwerk bei Produktionsbeginn des Autos bekannt und werden im Feld nicht geän-

Die Entwicklungstätigkeiten zum autonomen Fahren werden den Straßenverkehr durch verbesserte (Bilder: Vector Informatik) Assistenzfunktionen wesentlich sicherer machen. dert. Dieses Verfahren hat seine Grenzen, wenn einzelne Funktionen während der Lebensdauer des Fahrzeugs verändert werden, um neue Services aus dem Internet zu nutzen. Dazu muss der starre Kommunikationsmechanismus durch einen dynamischen ersetzt werden, der wesentlich unempfindlicher gegenüber Änderung ist und bei dem Änderungen nur lokale Auswirkungen, zum Beispiel nur auf Sender und Empfänger, haben und nicht wie heute sich durch einen großen Teil des Kommunikationsnetzes ziehen. Hierfür wird neben der Broadcast- und MulticastKommunikation auch die Punkt-zuPunkt-Kommunikation Einzug halten.

Service-Schnittstelle betrachten Heute schon werden von den Fahrzeugherstellern über Internet-Services Dienste im Fahrzeug angeboten. Live Traffic Information ist ein Beispiel für einen Dienst mit einem hohen Nutzen für den

Die Entwicklungstätigkeiten zum autonomen Fahren produzieren Ergebnisse, die den Straßenverkehr durch verbesserte Assistenzfunktionen wesentlich sicherer machen werden.

Remote Software Update Wenn heute Software und die dazugehörigen Daten im Fahrzeug verändert werden sollen, dann muss es in die Werkstatt und an einen Tester angeschlossen werden. Der Tester übernimmt die Aufgabe über das Kommunikationsnetzwerk des Fahrzeugs, die Steuergeräte des Autos zu flashen. Diese Vorgehensweise muss durch die Möglichkeit ergänzt werden, das Auto aus dem Internet über ein Kommunikationsmodul (GSM, LTE, WLAN) mit neuer Software und Daten zu versorgen. Dazu wandert ein Teil der Tester-Funktionen ins Fahrzeug, um „on-board“ die über das Internet empfangenen Software Updates auf die betreffenden ECUs zu flashen. Nur so erreichen wir die geforderte Flexibilität, um zeitnah auf Neuerungen zu reagieren und Angebote, Funktionen oder Fehlerbehebungen zur Verfüng zu stellen.

Fahrer. Aber auch das Fahrzeug kann „dem Internet“ Dienste anbieten und Informationen kontinuierlich an einen Server melden oder auf Anfrage Daten, zum Beispiel zur Verbesserung des Kartenmaterials oder Echtzeit-Verkehrsinformationen, liefern. Dieses Angebot an Diensten wird in den kommenden Jahren stark ausgebaut. Ein aus Vector-Sicht interessanter Dienst ist der Diagnosedienst. Mit ihm wird es möglich sein, von einem Server den Zustand des Fahrzeugs abzufragen oder Checks durchzuführen. Vector wird dazu die benötigte Software sowohl für das Fahrzeug als auch für die Server-Seite anbieten. Die Treiber des autonomen Fahrens und Car2X entwickeln die Automobilindustrie und mit ihr die E/E-Entwicklung in Richtung State-of-the-Art IT. Vector wird seine Kunden mit pfiffigen Lösungen unterstützen. eck

Trend kompakt Autonomes Fahren wird den Straßenverkehr sicherer machen. Die Entwicklung der dafür benötigten Technologie wird die Automobilindustrie im Umgang mit Software oder IT auf ein höheres Kompetenz-Level heben.

aus Elektronik automotive 1.2016

die Vielzahl der Stecker zum Problem wurden, nicht zu

Im Gegensatz dazu werden bei der empfängerselektiven

sprechen von den logistischen Herausforderungen bei der

Adressierung nicht die Steuergeräte, sondern die zu versen­

Herstellung, Wartung und Weiterentwicklung.

den Informationen identifiziert. Man spricht deswegen hier auch nicht von Adressen, sondern Identifiern. In unseren

Was bedeutet „Bus“?

Briefkästen sind solche Zustellungen an Akronymen (Identi­

Eine bahnbrechende Lösung all dieser Probleme war die

fiern) zu erkennen, welche die jeweilige Super- oder Bau­

Einführung des sogenannten Busses. Das Wort Bus stammt

marktkette bezeichnen. Jeder Empfänger entscheidet

vom lateinischen Wort „omnibus“, was auf Deutsch ledig­

selbst, ob die empfangenen Informationen gebraucht wer­

lich „für alle“ bedeutet. Man ersetzte also all die vielen ein­

den oder nicht.

zelnen Leitungen durch eine gemeinsame Leitung für alle

Damit Informationen und Adressen bzw. Identifier für den

Informationen aller Steuergeräte (Bild 2).

Empfänger erkennbar zusammengehören, packt der Sen­

Allerdings musste man jetzt Wege finden, die Übertragung

der beides zu einer Einheit zusammen. In der Übertra­

dieser Vielzahl von Informationen über nur einen gemeinsa­

gungstechnik nennen wir diese Einheit „Frame“, Englisch für

men Draht zeitlich zu organisieren. Dabei entstanden un­

„Rahmen“, weil die Adressen und Informationen mit einer

terschiedliche Technologien, die wir als serielle Bussysteme

Anfangs- und Endkennung eingerahmt sind, die vor allem

bezeichnen.

der fehlerfreien Übertragung zwischen Sender und Emp­

Bevor wir in den nächsten Folgen dieser Artikelreihe auf die

fänger dienen. Man spricht auch von Nachricht, Botschaft

speziellen Charakteristika der einzelnen Bussysteme einge­

oder Packet.

hen, erklären wir hier zunächst die technischen Grundlagen

Datenkommunikation im Automobil Teil 1: Architektur, Aufgaben und Vorteile serieller Bussysteme

Die Sicherheit der Daten

gen Anwendung finden, und vergleichen deren unterschied­

Zu den wichtigsten Aufgaben eines seriellen Bussystems

liche Konzepte.

gehören die rechtzeitige, für die jeweilige technische An­

Alle Busse haben gemeinsam, dass die angeschlossenen

wendung hinreichend schnelle Datenübermittlung und vor

Steuergeräte jeweils einen gemeinsamen Ein- und Ausgang

allem die Sicherheit der Daten bei der Übertragung. Der

haben, und die Informationen nicht wie bei einem Netzwerk

Einsatz eines seriellen Bussystems im Automobil hängt

durch die Steuergeräte hindurch müssen. Sendet also ein

entscheidend davon ab, welches Maß an Sicherheit benö­

Steuergerät an einem Bus, so empfangen alle anderen die

tigt wird und welche Menge an Daten pro Zeiteinheit über­

Information fast gleichzeitig — wobei die Einschränkung

tragen werden muss.

„fast“ lediglich der Laufzeit eines elektrischen Signals auf

Die Sicherheit eines seriellen Bussystems hängt davon ab,

Kupfer geschuldet ist, die ca. 5 ns/m beträgt.

wie gut es Fehler bei der Übertragung von Daten vermei­ det, und wie gut es Verfälschungen erkennt. Die Restfehler­

Geschichtliches

sicher am dass Fahrzeuge autonom, also ohne Fahrer, ­

Bereits die ersten mit Ottomotor betriebenen Fahrzeuge

Straßenverkehr teilnehmen können. Auch sollen sie unterei­

Adressen wie bei der Post

wahrscheinlichkeit gilt als Maß für diese Sicherheit. Sie ist

verfügten notwendigerweise über elektrische Bauteile wie

nander und mit Einrichtungen der Straßeninfrastruktur, so­

Für einen reibungslosen Informationsaustausch braucht

das Produkt der Wahrscheinlichkeit A, mit der die zu über­

Zündspule, Unterbrecher und Zündkerzen. Rasch folgten

wie dem Internet vernetzt und über WLAN verbunden sein.

man eine eindeutige Zuordnung der zu versendenden ­Daten

tragenden Daten verfälscht sind, und der Wahrscheinlich­

andere elektrische Einrichtungen, wie Licht, Bremsleuch­

Jedoch wären alle diese Funktionen im Automobil ohne Da­

zu ihren Sendern und Empfängern. Wir nennen sie Adres­

keit B, mit der verfälschte Daten unerkannt bleiben. Je klei­

ten, Richtungsanzeiger, Innenbeleuchtung und Scheiben­

tenaustausch zwischen elektronischen Komponenten nicht

sierung. Grundsätzlich unterscheidet man zwischen sen­

ner diese Restfehlerwahrscheinlichkeit, desto höher ist die

wischer. Mit Komponenten zur Unterhaltung und Informa­

realisierbar. Und genau an diesem Punkt lag und liegt die

derselektiver und empfängerselektiver Adressierung. Wir

Sicherheit der Datenübertragung.

tion wie Radio und Plattenspieler, später Kassettengerät

eigentliche Herausforderung. Zunächst hatte man für die

kennen beide aus unserem Briefkasten. Bei der sender­

Ursachen für Datenverfälschungen sind vielfältig. Am stärks­

oder CD-Player, waren auch bald elektronische Komponen­

Übertragung jeder Information ein eigenes Kabel vorgese­

selektiven Adressierung bestimmt der Sender den ge­

ten stören Funken in Zündkerzen und Elektromotoren. Aber

ten in Fahrzeugen enthalten. Seit den 1970iger Jahren folg­

hen (Bild 1). Jedoch wuchsen mit der Menge der Informati­

wünschten Empfänger über eine eindeutige Zieladresse.

auch andere galvanische, kapazitive oder induktive Wech­

te Elektronik, welche Funktionen des Fahrzeugs selbst ver­

onen die Kabelbäume so stark, dass schon ihr Gewicht und

Das entspricht dem Standardbrief mit Absender- und

selwirkungen bzw. elektromagnetische Felder kommen in

Zieladresse.

Frage. Selbst durch Reflexionen an den Enden der Buslei­

besserte, bereicherte oder das Fahren erleichterte. Der nächste Schritt in den 1980igern galt der Fahrsicherheit

tung kann ein serieller Bus von innen gestört werden. Je

wie etwa ABS und Airbags oder dem Ausbau des Komfort­

besser es gelingt, solche Ursachen auszuschließen oder zu

bereichs

durch

Klimaanlage,

Spiegelabblendung

und

­-einstellung, Fensterheber und Tempomat.

vermeiden, desto sicherer ist die Datenübertragung. Knoten A

Knoten B

Knoten C

Knoten A

Knoten B

Knoten C

Einige wichtige Maßnahmen sichern die Daten. Dazu ge­

Die zunehmende Globalisierung sorgte durch steigenden

hört die Abschirmung des Übertragungsmediums (Leitung,

Wettbewerb für immer mehr Innovation. Mit der Elektronik

Draht) sowie sämtlicher elektrischer und elektronischer

begegneten die Kfz-Hersteller dieser vielseitigen Herausfor­

Komponenten. Das Prinzip der differenziellen Signalüber­

derung. In den 1990iger Jahren wurde die Entwicklung elek­ tronischer Komponenten so rasant, dass eine Aufzählung der einzelnen Schritte hier zu weit führen würde. Inzwischen geht es um immer mehr Umweltfreundlichkeit und darum,

1/0

dieser seriellen Bussysteme, die in modernen Kraftfahrzeu­

Knoten E

Bild 1: Punkt-zu-Punkt-Verbindungen

Knoten D

Knoten E

Bild 2: Busvernetzung

Knoten D

tragung (Bild 3) erreicht ein hohes Maß an Übertragungssi­ cherheit, ohne dabei eine echte, physische Abschirmung zu benötigen. Sie wäre zu teuer und erfüllt nicht hinreichend Anforderungen an Biegsamkeit und Hitzebeständigkeit.

1/1

Datenkommunikation im Automobil Teil 1

Dabei wird die Information mit Hilfe von Spannungspegeln

den empfangenden Steuergräten. Im Automobil setzt man

rung besteht die Gefahr, dass Botschaften mit niederer

auf zwei verdrillten Leitungen seriell übertragen, wobei die

keine solchen Korrekturverfahren ein, sondern verwirft die

Priorität lange verzögert und nicht mehr rechtzeitig emp­

ment, also das konzertierte Einschlafen oder Aufwachen

Pegel genau spiegelsymmetrisch entgegengesetzt sind.

fehlerhafte Botschaft und fordert deren erneute Übertra­

fangen werden.

aller Steuergeräte, oder die Diagnose und Konfiguration

Geht auf einem Draht die Spannung um einen Wert X Volt

gung an.

Für manche Aufgaben, wie beispielsweise das Busmanage­

von Steuergeräten, reichen die Funktionen der physikali­

noch oben, geht er gleichzeitig auf dem anderen um X Volt

Architektur serieller Bussysteme

schen Schicht und die der Sicherungsschicht nicht aus.

nach unten. Dadurch sind die elektrischen Felder in den Lei­

Werden Informationen hinreichend schnell übermittelt?

In Anlehnung an das von der ISO (International Standardi­

Dann nutzt man die höheren Schichten des ISO-Referenz­

tungen genau entgegengesetzt und die resultierenden ma­

Ein Bussystem gilt als fähig zur Übertragung in Echtzeit [1],

zation Organization) spezifizierte Referenzmodell für Da­

modells für höhere Kommunikationsprotokolle, um so die

gnetischen Felder um die Drähte heben sich somit gegen­

kurz echtzeitfähig, wenn es die Übertragung sämtlicher für

tenkommunikation wird die serielle Schnittstelle eines

benötigte Kommunikationsfunktionalität zu erzielen.

seitig fast völlig auf. Ein solches System strahlt daher kaum

eine Anwendung anfallenden Daten hinreichend schnell ga­

Steuergeräts zum Bus im Automobil in der Regel auf zwei

Störungen ab. Als Signal wird die Differenz der Pegel beider

rantieren kann. Die wesentlichen Faktoren sind dabei An­

(Kommunikations-)Schichten verteilt. Auf der physikali­

Herstellerübergreifende Bustechnologien

Drähte genommen, wobei störende Einstrahlungen von

zahl und Größe der Botschaften, die zur Verfügung stehen­

schen Schicht (Physical Layer) wird die physische Busan­

Der verschärfte Wettbewerb sorgt für immer mehr Sicher­

­außen wegsubtrahiert werden.

de Übertragungsgeschwindigkeit, auch Bandbreite ge­

kopplung bis hin zur physikalischen Signalübertragung auf

heits- und Komfortfunktionen im Automobil. Die Folge ist

Ein ausreichend großer Abstand zwischen Datenübertra­

nannt, und die Art des Buszugriffs der Steuergeräte. Bei

dem Bus organisiert. Darüber liegt die Sicherungsschicht

nicht nur ein permanenter Anstieg der Anzahl an elektroni­

gungs- und Energieversorgungsleitungen sowie zwischen

Letzterem unterscheidet man zwischen kontrolliertem und

(Data Link Layer) mit ihren Aufgaben wie Adressierung,

schen Komponenten in den Fahrzeugen, sondern auch ein

elektrischen und elektronischen Komponenten ist hilfreich.

zufälligem Buszugriff (Bild 4).

Framing, Buszugriff, Synchronisation sowie Fehlererken­

deutlich höherer Vernetzungsgrad mit rasant steigendem

Weiterhin gilt es, die Datenübertragungsgeschwindigkeit

Bei kontrolliertem Buszugriff ist das Buszugriffsrecht eines

nung und -korrektur (Bild 5).

Datenaufkommen, weil die meisten neuen Automobil-­

sowie die Anzahl und die Steilheit der Datensignalflanken

Steuergeräts bereits vor seinem Buszugriff festgelegt.

Die physikalische Busankopplung geschieht mit Hilfe eines

Funk­tionen ohne Datenaustausch nicht mehr auskommen.

zu begrenzen und die beiden Bus-Enden mit dem Wellenwi­

Man nennt solche Systeme deterministisch, weil exakt

Transceivers. Die Aufgaben der Sicherungsschicht über­

Die so entstehende Herausforderung ist die Beherrschung

derstand des Übertragungsmediums abzuschließen, um

­determiniert, also berechnet werden kann, wann welches

nimmt ein Kommunikationscontroller. Benutzen alle Steu­

der zunehmenden Komplexität, damit die Qualität und Zu­

Reflexionen zu vermeiden.

Steuergerät welche Daten überträgt. Determinismus ist

ergeräte am Bus die gleichen Transceiver und Kommunika­

verlässigkeit der Funktionen gewährleistet bleiben. Dazu

Dennoch lassen sich Übertragungsfehler nie vollständig

eine wichtige Voraussetzung für die Verwirklichung von

tionscontroller, sind die grundlegenden Voraussetzungen

hat die Automobilindustrie Standards geschaffen, wie z. B.

ausschließen, weshalb man Mechanismen benötigt um Feh­

Echtzeit. Da der gesamte Kommunikationsablauf planmä­

für einen reibungslosen Datenaustausch gegeben.

„AUTOSAR“ (AUTomotive Open System ARchitecture, Bild 6),

ler zu erkennen. Dazu wird am häufigsten das Prüfsum­

ßig abläuft und kaum beeinflussbar ist, zeichnen sich Bus­

Bei der seriellen Kommunikation übergibt die Applikation

was auf der System- bzw. Funktionsebene für die nötige

menverfahren genutzt. Dabei berechnet der Sender mit

systeme mit kontrolliertem Buszugriff durch ein schlechtes

des Senders dem Kommunikationscontroller den zu versen­

Transparenz sorgt. Herstellerübergreifende Kommunikations­

einem definierten Algorithmus aus den zu versendenden

dynamisches Verhalten aus.

denden Datenblock nebst Adressen oder Identifier. Dieser

stan­dards wie die seriellen Bussysteme CAN  [2], LIN  [3],

Daten eine Prüfsumme, die er am Ende der Botschaft über­

Diesen Nachteil vermeiden Bussysteme mit unkontrollier­

ergänzt beide um Prüf- und Synchronisationsinformatio­

FlexRay  [4], MOST  [5] und Ethernet  [6] sorgen für mehr

trägt. Diese Prüfsumme kann der Empfänger mit derjeni­

tem Buszugriff. Jedes Steuergerät hat zu jeder Zeit das

nen, sowie Anfangs- und Endkennung, so dass ein Frame

Transparenz auf den unteren Kommunikationsebenen.

gen vergleichen, die er selbst aus den empfangenen Daten

Recht, Daten zu übertragen. Daraus folgt einerseits ein

entsteht. Der Transceiver sendet nun den Frame auf den

CAN (Controller Area Network) wird hauptsächlich in den

berechnet hat. Stimmen beide nicht überein, liegt ein Feh­

sehr schneller Buszugriff, andererseits aber auch folgende

Bus.

Bereichen Antrieb, Fahrwerk und der Bedienung des Fahr­

ler vor. Je ausgeklügelter der Algorithmus und je länger die

Gefahr: Abhängig von Dichte und Länge der Botschaften

Die meisten Busse im Automobil haben die Gestalt einer

zeugs eingesetzt. Über LIN (Local Interconnect Network)

Prüfsumme, desto besser die Fähigkeit, Fehler zu erkennen.

und der zur Verfügung stehenden Bandbreite resultiert eine

Leitung, an die über kurze Stichleitungen die Steuergeräte

werden einfache Komfortfunktionen gesteuert, wie etwa

Allerdings darf eine Prüfsumme nicht zu lang sein, weil jede

mehr oder weniger akute Kollisionsgefahr. Sie ist keine gute

angeschlossen sind. Man nennt dies Linien- oder Bustopo­

Klima, Sitze, Spiegel und Fenster. MOST (Media Oriented

Botschaft entsprechend länger wird und auf dem Bus we­

Voraussetzung für Echtzeit.

logie. Auf der Empfängerseite nimmt wieder der Transceiver

System Transport) bestritt lange den Bereich Infotainment

niger Daten übertragen werden können.

Überwachen alle Steuergeräte den Bus ständig und senden

den Frame entgegen und übergibt ihn dem Kommunikati­

mit der Übertragung von Video- und Audiosignalen, die

Wird ein Fehler erkannt entsteht die Frage nach Korrektur.

nur, wenn er frei ist, reduziert sich die Kollisionsgefahr er­

onscontroller, welcher die an ihn übertragenen Informatio­

hohe Bandbreiten erfordern. Hier kommt zunehmend auch

Man kann anhand der in einer Botschaft enthaltenen Prüf­

heblich, allerdings nicht völlig. Man vermeidet sie gänzlich

nen überprüft und im Falle des korrekten Datenempfangs

Ethernet ins Spiel. Zurzeit ist Diagnose inklusive Flashen

summe Fehler korrigieren. Allerdings erfordert dies längere

durch das zusätzliche Einführen von Prioritäten der Infor­

den Datenblock an die Applikation weitergibt.

die Hauptanwendung für Ethernet, jedoch soll sie zukünftig

Prüfsummen und vor allem immense Rechenkapazitäten in

mationen, beim CAN-Bus erkennbar am Identifier. Aller­

im Bereich Fahrerassistenz liegen, mit seinen Untersparten

dings können auch diese Buszugriffsverfahren keine Recht­

Parkassistent und autonomes Fahren. FlexRay schließlich

zeitigkeit (Echtzeit) garantieren. Denn durch die Priorisie­

sollte anspruchsvollste Kommunikation in sicherheitskriti­

Spannung

schen Anwendungen ermöglichen wie etwa elektronisch Sample Punkt

Draht 1 Draht 2

ΔVnormal

ΔVgestört Störung symmetrisch auf beiden Drähten

Kontrollierter Buszugriff

Zentral

Dezentral

– Polling – Delegated Token

Zeit

Bild 3: Differenzielle Übertragung auf zwei verdrillten Drähten

1/2

„Vor dem Buszugriff ist Buszugriffsrecht vergeben“

– Token Passing – Time Division Multiple Access (TDMA)

Zufälliger Buszugriff

Nicht kollisionsfrei – Carrier Sense Multiple Access (CSMA)

Bild 4: Kontrollierter und zufälliger Buszugriff

„Vor dem Buszugriff ist Buszugriffsrecht nicht vergeben“

Kollisionsfrei – CSMA with Collision Avoidance (CSMA/CA)

Busknoten

Busknoten

Applikation

Applikation

Kommunikation

Kommunikation

geregeltes Lenken und Bremsen. Allerdings tun sich Ge­ setzgeber wie Autobauer schwer, in diesen Bereich vorzu­ stoßen, weil niemand Risiken in diesen für Sicherheit hoch­ kritischen Bereichen eingehen will.

Communication Controller

Kommunikationsprotokoll

Communication Controller

Transceiver

Physical Layer Definition

Transceiver

Bus

Bild 5: Architektur serieller Bussysteme

Bild 6: AUTomotive Open System ARchitecture

1/3

CAN wurde Anfang der 1980er Jahre von der Robert Bosch

Unterscheidungskriterium gelten die unterschiedlichen Fol­

GmbH entwickelt und 1994 international standardisiert

gen einer Verletzung der Echtzeitanforderungen: >>harte Echtzeitanforderungen: Überschreitet das System

(ISO 11898). Die Gründer von Vector waren an dieser Ent­ wicklung maßgeblich beteiligt. LIN (ISO  17987), FlexRay

die geforderte Antwortzeit, hat es versagt. Echtzeit­

(ISO 17458) und MOST gingen aus den herstellerübergrei­

systeme müssen das korrekte Ergebnis immer innerhalb

fenden Organisationen LIN-Konsortium, FlexRay-Konsor­

dieser geforderten Antwortzeit liefern, worauf man sich

tium und MOST Kooperation hervor.

beim Einsatz eines harten Echtzeitsystems verlassen

Vector  [7] unterstützt Fahrzeughersteller und -zulieferer

können muss. (Beispiel Motorsteuerung: Werden die

bei der CAN-, LIN-, FlexRay-, MOST- und Ethernet-Vernet­

Anforderungen verletzt, stottert der Motor oder es

zung mit einer durchgängigen Werkzeugkette aus Designund Entwicklungstools sowie mit Softwarekomponenten

kommt sogar zu Schäden.) >>weiche Echtzeitanforderungen: Solchen Systeme erfüllen

und Basissoftware für AUTOSAR-Steuergeräte. Beratung,

die geforderte Antwortzeit nur typischerweise. Die

Consulting Services und Werkzeuge für das Prozessma­

geforderte Antwortzeit erreicht also zum Beispiel nur

nagement ergänzen die Anwendungsgebiete. Abgerundet

einen Mittelwert oder genügt einem anderen statisti­

werden die Leistungen durch ein umfangreiches Schulungs­

schen Kriterium. Die Zeitanforderungen werden hier

angebot, wie beispielsweise Grundlagenseminare zu CAN,

nicht absolut streng, sondern als Richtlinien gesehen. Ein

LIN, FlexRay und Ethernet.

Überschreiten der geforderten Antwortzeit gilt nicht als

Die Teile zwei bis fünf dieser Reihe befassen sich detailliert

Versagen. Sie kann häufig überschritten werden, solange

mit den seriellen Bussystemen CAN, LIN, FlexRay und MOST.

sie noch in einem Toleranzbereich liegt. Oder sie kann in seltenen Fällen sogar stark überschritten werden.

Noch ein Nachwort zum Begriff „Echtzeit“

(Beispiel Videokonferenz: Werden die Anforderungen

Sehr häufig wird der Begriff „Echtzeit“ lax oder ungenau

verletzt, „ruckelt“ das Bild, aber es kann weiter

verwendet, weil er nicht ganz einfach zu fassen ist. Da ich

­gearbeitet werden.)

ihn eingangs verwenden musste, möchte ich in Form eines kleinen Nachwortes hier einige wenige Sachverhalte zu die­

Links:

sem Thema klarstellen. Wer mehr wissen muss, kann weite­

[1] de.wikipedia.org/wiki/Echtzeit

re Quellen heranziehen. [1]

[2] de.wikipedia.org/wiki/Controller_Area_Network

Die Definition der inzwischen durch DIN ISO/IEC 2382 ab­

[3] de.wikipedia.org/wiki/Local_Interconnect_Network

gelösten Norm DIN  44300 (Informationsverarbeitung),

[4] de.wikipedia.org/wiki/FlexRay

Teil  9 (Verarbeitungsabläufe) lautet: „Unter Echtzeit ver-

[5] www.mostcooperation.com

steht man den Betrieb eines Rechensystems, bei dem Pro-

[6] de.wikipedia.org/wiki/BroadR-Reach

gramme zur Verarbeitung anfallender Daten ständig be-

[7] www.vector.com

triebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.“ Für ein echtzeitfähiges System genügt es also nicht, ein Mess- oder Berechnungsergebnis mit dem richtigen Wert zu liefern, sondern dies muss obendrein auch noch in einer vorgegebenen Antwortzeit erfolgen. Ist dies nicht der Fall, hat das System versagt. Die geforderte Antwortzeit muss gemäß der Theorie der Echtzeitsysteme für eine auf dem System laufende Anwendung berechnet werden. Oft wird recht leichtfertig von „Echtzeit“ gesprochen, wenn ein Programm ohne spürbare Verzögerung arbeitet. Jedoch ist diese Definition nicht sehr sauber. Falsch ist es, „Echtzeit“ als Synonym für „besonders schnell“ zu verwenden, weil Echtzeitsysteme sogar Leerläufe ein­ planen müssen, um auch unter hoher Last die Anforderun­ gen an Echtzeit erbringen zu können. Es wird zwischen harter Echtzeit (engl. hard real-time) und weicher Echtzeit (engl. soft real-time) unterschieden. Als

1/4

Ernst Christmann, Physiker, Mathematiker ist Senior Technical Trainer im Bereich Software Tools für Steuer­ gerätetests und Steuergeräteentwicklung und seit 2004 bei der Vector Informatik GmbH in Stuttgart tätig.

CAN-High-Speed kommt vor allem in Antriebs- und Fahr­

Diese Form der Nachrichtenverteilung bietet folgende Vor­

werksapplikationen zum Einsatz. Man realisiert ihn im

teile: >>Kosteneinsparung durch gemeinsame Nutzung von

­Wesentlichen durch den CAN-High-Speed-Transceiver, der CAN-Low-Speed Physical Layer wurde hauptsächlich im

Sensoren durch alle Steuergeräte am Bus >>Einfache Realisierung von verteilten Funktionen

Komfortbereich eingesetzt. Dort wurde er in Türen, Sitze

>>Die empfängerselektive Adressierung erlaubt unter­

eine maximale Datenrate von 1 Mbit/s unterstützt. Der

und Schiebedächer verlegt, wo er Biegungen unterliegt,

schiedliche Konfigurationen ohne Anpassung von Hard-

wodurch Leitungen brechen können. Man nutzte hier den

oder Software

fehlertoleranten CAN-Low-Speed-Transceiver mit einer maximalen Datenrate von 125  kbit/s, der auch mit einem

Ereignisse veranlassen die Übertragung von Nachrichten

Draht auskommen kann. Inzwischen wird dieser CAN-Bus-

Ereignet sich in unserem Alltag ein berichtenswertes Ereig­

Typ kaum noch verbaut.

nis, so entstehen Nachrichten darüber. Auch in der Welt se­ rieller Busse spricht man von einem Ereignis, wenn Infor­

Die CAN-Schnittstelle besteht also aus einem CAN-Cont­

mationen übertragen werden müssen. Für eine schnelle

roller und einem CAN-Transceiver (Bild 2).

Übermittlung der Informationen ist es am besten, wenn

Der CAN-Controller wickelt das CAN-Protokoll ab, der

das zugrundeliegende Ereignis die Übertragung der jeweili­

CAN-Transceiver übernimmt die Aufgabe, den CAN-Cont­

gen Daten unmittelbar auslöst. Man spricht von ereignis­

roller physikalisch an die beiden CAN-Leitungen anzukop­

gesteuerter Übertragung.

peln und die Spannungspegel auf den beiden Drähten zu

Die Alternative wäre, Informationen immer nach einem

messen oder zu erzeugen.

vorgeschriebenen Zeitplan oder -raster zu übertragen. Wenn nun eine Information anfällt, das entsprechende

Datenkommunikation im Automobil Teil 2: Sicherer Datenaustausch mit CAN

Steuergerät jedoch nicht an der Reihe ist zu senden, muss

CAN nutzt eine empfängerselektive Adressierung. Die Iden­

gewartet werden.

tifier (ID) bezeichnen nicht das Ziel, sondern den Inhalt der

Um dieses Warten zu vermeiden wurde CAN als ereignisge­

übermittelten Daten. Eine Botschaft kann also von allen

steuertes Bussystem entwickelt. Jeder CAN-Knoten ist be­

Steuergeräten am Bus empfangen und ausgewertet wer­

rechtigt, sofort nach Auftreten eines Ereignisses auf den

den (Nachrichtenverteilung). Die Applikation eines emp­

CAN-Bus zuzugreifen, und die anfallenden Daten zu sen­

fangenden Steuergeräts entscheidet darüber, ob sie eine

den. Einzige Ausnahme dabei ist, wenn bereits ein anderes

Botschaft

Steuergerät Daten überträgt. Die Höflichkeit gebietet, an­

auswertet.

Sie

kann

sogar

in

ihrem

­CAN-Controller beim Start einen Akzeptanzfilter setzen,

dere nicht zu unterbrechen.

Wie im Teil 1 unserer Artikelreihe dargelegt, erfordern die

Drähte weiter funktioniert, wenn auch mit geringerer Si­

der nicht benötigte CAN-Botschaften anhand ihrer Identi­

Wichtig ist dabei, dass diese anderen nicht beliebig lange

komplexer werdenden elektronischen Systeme im Auto­

cherheit. Die beiden Teile 2 und 3 decken den Physical Layer

fier aus dem Nachrichtenstrom ausblendet. CAN bietet

sprechen. Bei CAN hat man die Nachrichtenlänge auf ma­

mobil ein höheres Maß an Datenaustausch zwischen den

des ISO­-Referenzmodels ab, darunter die physikalische

zwei Größen von Identifiern an: 11 und 29 Bit. Die kleinere

ximal 130 Bit (bei 11-Bit-Identifiern) begrenzt. Bei der in

Steuergeräten. Damit dieser mit hinreichender Sicherheit

Busankopplung, Datenraten und die Spannungspegel auf

Variante (Standardformat) wird in Pkw verwendet und bie­

Pkw üblichen Datenübertragungsrate von 500 kbit/s be­

und Schnelligkeit gewährleistet werden kann, wurde der

den beiden CAN-Leitungen.

tet 2048 verschiedene Botschaften, während die größere

deutet dies eine Übertragungsdauer von ca. einer Viertel

CAN‑Bus entwickelt. CAN steht für Controller Area Net­

CAN nutzt Differenzsignalübertragung, welche die Stör­

Variante 536 870 912 bietet. Letztere wird hauptsächlich in

Millisekunde. Danach ist der Bus wieder verfügbar. Dies ist

work, und wie der Name bereits vermuten lässt, kann der

empfindlichkeit verbessert und zwei Kommunikationslei­

Nutzfahrzeugen für auf CAN basierende Softwareproto­

eine wichtige Voraussetzung für eine Datenübertragung,

CAN‑Bus ein größeres Gebiet vernetzen, er kann bis zu

tungen erfordert (CAN-High- und CAN-Low-Leitung), die

kolle z. B. wie SAE  J1939 benötigt, ist aber inzwischen im

die für Anwendungen wie Antrieb und Fahrwerk hinrei­

mehreren Kilometer lang sein.

zur Vermeidung von Reflexionen an beiden Enden mit dem

Pkw-Bereich auch anzutreffen.

chend schnell sein muss.

Der von Bosch  [1] entwickelte CAN‑Bus ist seit 1993

Wellenwiderstand RT von 120 Ω abgeschlossen werden. Da­

genormt und liegt als ISO-Norm 11898 vor (Bild 1). Sie ist in

ab, dem sogenannten OSI-Schichtenmodell (OSI: Open Systems Interconnec­tion). Zur Abwicklung des CAN-Proto­ kolls wurde der sogenannte CAN-Controller entwickelt. Die Teile 2 und 3 der ISO-Norm 11898 beschreiben zwei Aus­ prägungen des Physical Layer, nämlich CAN-High-Speed und CAN-Low-Speed. Letzterer wird oft auch Fault-Tole­ rant-CAN genannt, weil er beim Bruch einer seiner beiden

mehrere Steuergeräte gleichzeitig mit dem Senden von Botschaften beginnen wollen. Diese Gefahr steigt mit zu­

Anwendungssoftware, die mit anderen Steuergeräten mittels Botschaften kommuniziert

(Framing, Adressierung, Buszugriff, Datensicherung) und des ISO  7498 Referenzmodells der Datenkommunikation

wenn beim Freiwerden des Busses nach einer Übertragung Microcontroller

CAN-Protokoll und deckt vollständig den Data Link Layer die physikalische Signalcodierung als Teil des Physical Layer

Allerdings bleibt die Gefahr von Kollisionen, nämlich dann,

rüber haben wir in Teil 1 bereits geschrieben.

mehrere Teile ge­ gliedert. Der erste Teil umfasst das

1/6

Was muss von wo nach wo?

ISO 7498

CAN

CAN-Standard

Implementierung

2 LLC Data Link MAC Layer

CANProtokoll

ISO 11898-1

CANController

CAN Physical Layer

ISO 11898-2 ISO 11898-3

CANTransceiver

1 Physical Layer LLC MAC PLS PMA MDI

PLS PMA MDI

Logical Link Control Medium Access Control Physical Signalling Physical Medium Attachement Medium Dependant Interface

Bild 1: CAN-Standard

ISO 11898-1 CAN-Protokoll ISO 11898-2 CAN-High-Speed Physical Layer ISO 11898-3 CAN-Low-Speed Physical Layer

nehmender Buslast. Würden Botschaften bei einer Kollision

CAN-Controller

zerstört, wäre die Folge ein Anstieg der Buslast, und somit

Vervollständigt Botschaften Regelt Buszugriff sowie Tx, Rx von Botschaften, Bit-Timing

ein Teufelskreis, der eine hinreichende Geschwindigkeit bei der Datenübertragung in Frage stellt. Um dies zu vermei­

CAN-Transceiver

Senden: Übersetzt Bits in Spannungspegel Empfang: Spannungspegel abtasten und an Controller geben

RT

CANSteuergerät

CANSteuergerät

den setzt man im CAN-Netzwerk das CSMA/CA-Bus­ zugriffsverfahren ein (Carrier Sense Multiple Access / Colli­

CAN_H

CAN_L

sion Avoidance). RT

Bild 2: Aufbau eines CAN-Steuergeräts

1/7

Datenkommunikation im Automobil Teil 2

tät der betreffenden CAN-Nachricht. Die Botschaft mit

auch noch zur Arbitrierung herangezogen wird. Ist RTR = 1

Will ein Steuergerät senden, muss es prüfen, ob der Bus frei

dem kleinsten Identifier (ID = 0) wird deshalb ohne Verzö­

liegt ein Remote Frame vor, anderenfalls ein Data Frame.

ist (Carrier Sense — CS). Ist er belegt, muss es warten.

gerung übertragen. Botschaften mit numerisch höheren

Wird der Bus wieder verfügbar, kann es sein, dass noch wei­

ID-Werten haben bei Kollisionen ein Risiko der Verzögerung

Bitte ein Bit zum Uhrenvergleich

bits mehr eingefügt werden, ist das EOF eine eineindeutige

tere Steuergeräte darauf gewartet haben. In diesem Fall

durch das Verlieren der Arbitrierung.

Grundvoraussetzung für die Übertragung von Data und

Kennung für das Ende der Botschaft. Nach dem EOF fol­

dürfen alle Steuergeräte mit dem Senden beginnen

Bei niedriger Buslast ist die Wahrscheinlichkeit von Kollisio­

Remote Frames ist ein Gleichlauf zwischen Sender und

gen drei rezessive Bits, die allerdings nicht mehr zur Bot­

(Mul­ ­ tiple Access — MA). Um die sich nun anbahnenden

nen klein, und diese Art des zufälligen, zerstörungsfreien

Empfänger. Aus Kosten- und Aufwandsgründen verzichtet

schaft gehören. Man nennt sie Intermission (ITM) oder ­Inter

Schäden bei dieser Kollision zu vermeiden (Collision Avoi­

und prioritätengesteuerten Buszugriffs sorgt für einen ge­

man bei CAN auf eine Taktleitung. Man realisiert den

Frame Space (IFS). Erst danach darf eine weitere Bot­

dance — CA oder Collision Resolution — CR) wird nun etwas

rechten und sehr schnellen Buszugriff. Mit zunehmender

Gleichlauf mit Signalflanken und einem definierten Mecha­

schaft gesendet werden.

getan, was man als bitweises Arbitirieren bezeichnet. Das

Buslast häufen sich Kollisionen und die Verzögerungen vor

nismus zur Synchronisation. Wird bei CAN nichts gesendet

Wort stammt vom englischen „arbiter“, auf Deutsch

allem von niederprioren Botschaften wachsen an. Im

(Bus-Idle) ist der Bus-Pegel rezessiv, also wie wenn nur Bits

Fehlererkennung und der Elefant im Porzellanladen

„Schlichter“.

schlimmsten Fall kommen dann Informationen zu spät

mit dem Wert 1 gesendet würden. Eine Botschaft beginnt

Die Wahrscheinlichkeit, dass Fehler in CAN-Nachrichten

Alle Steuergeräte mit Sendeauftrag senden gleichzeitig

oder gar nicht mehr bei ihren Empfängern an. Deswegen ist

daher mit dem Übertragen eines dominanten Synchronisa­

unerkannt bleiben, ist mit 4,7 * 10-11 oder kleiner sehr gering

den Identifier ihrer jeweils zu übertragenden CAN-Nach­

es notwendig, bereits bei der Planung und Entwicklung ei­

tionsbits (Start of Frame — SOF) auf dessen fallende Sig­

[2]. Das CAN-Protokoll verfügt über definierte Fehlererken­

richt bitweise vom höchst- zum niederwertigsten Bit.

nes CAN-Busses eine nicht zu hohe Buslast sicherzustellen.

nalflanke alle Empfänger ihre Uhren justieren.

nungsmechanismen. Dazu gehören auf der Empfängersei­

Ein Bit mit Wertigkeit 0 ist am CAN-Bus dominant. Das

Das bitweise Arbitrieren hat noch einen weniger offen­

Jeder Empfänger stellt während der gesamten Übertra­

te neben dem CRC die Überprüfung des Formats (Form

bedeutet, wenn zwei Steuergeräte gleichzeitig unterschied­

sichtlichen Nachteil: Ein Bit muss zeitlich lang genug sein,

gung durch Auswertung jeder fallenden Signalflanke die

Check) und die Prüfung gemäß der Bitstuffing-Regel (Stuff

liche Bitwerte übertragen, setzt sich auf den Busleitungen

damit die Verzögerungen beim Senden keine Probleme be­

Synchronisation sicher und passt gegebenenfalls sein eige­

Check). Der Sender prüft per Bitmonitoring, ob ein Bitpegel

die 0 gegenüber der 1 durch. Man nennt dies „Wired-­AND-

reiten. Ein elektrisches Signal breitet sich in Kupfer mit ca.

nes Zeitraster (Bit Timing) an. Lange Folgen gleichwertiger

am Bus dem Sendeauftrag entspricht, und er wertet den

Buslogik“ (0 = dominant, 1 = rezessiv). Mit dem Senden eines

200 000 km/s oder 0,2 m/ns aus. Dazu kommen noch Ver­

Bits weisen keine Signalflanken auf. Deswegen unterbricht

ACK-Slot aus.

jeden ID-Bits vergleicht jedes Steuergerät den Buspegel

zögerungen durch die CAN-Controller und -Transceiver. Ein

CAN diese und fügt nach fünf gleichen Bits ein komplemen­

Weist zum Beispiel an einem CAN-Bus statistisch jede tau­

mit dem von ihm gesendeten Pegel. Man nennt dies

Bitpegel muss daher lange genug auf dem Bus anliegen,

täres Bit ein und erzeugt somit eine Signalflanke. Man

sendste Botschaft einen Fehler auf, und ist er jährlich 1000

­Bitmonitoring. Die Regeln der sogenannten Arbitrierungs­

damit auch die vom Sender am weitesten entfernten Steu­

nennt dies Bit Stuffing. So erzwingt man eine fallende

Stunden im Betrieb bei einer Datenrate von 500 kbit/s, ei­

logik entscheiden, ob ein Steuergerät weiter senden darf

ergeräte ihn beim Arbitrieren noch rechtzeitig feststellen

Flanke nach spätestens 10 Bits. Nach dem Synchronisieren

ner mittleren Buslast von 25 % und einer durchschnittlichen

oder das Senden einstellen muss (Bild 3).

und auswerten können. Daraus folgt ein reziproker Zusam­

verwerfen die Empfänger diese Stuffbits.

Nachrichtenlänge von 80 Bit, so würde nach den Regeln der

Ein Bit nach der Übertragung der Identifier endet die

menhang zwischen Buslänge und Übertragungsrate.

Nach dem SOF folgt der entweder 11 Bit oder 29 Bit lange

Statistik nur alle 4000 Jahre eine fehlerhafte CAN-Bot­

ID. Seine Länge ist am IDE-Bit (Identifier Extension) er­

schaft auftreten, deren Fehler unerkannt bleibt.

Prioritäten anstatt Kollisionen

­Arbitrierung. Alle Steuergeräte, die beim Senden ihres Iden­

ACK-Delimiter mit dem 7 Bit langen, rezessiven EOF (End of Frame) abgeschlossen. Weil nach dem CRC keine Stuff­

tifiers eine logische 1 übertrugen, jedoch eine 0 am Bus vor­

Daten bestellen und liefern

sichtlich. IDE = 0 bedeutet kurze IDs, IDE = 1 die langen.

Sobald ein Steuergerät einen Fehler bemerkt, bricht es die

fanden, mussten das Senden einstellen. Nur ein Steuerge­

Es gibt im Straßenverkehr Linienbusse, die regelmäßig nach

Zur Übertragung von Nutzinformationen stellt CAN das

Nachrichtenübertragung ab, indem es sechs dominante

rät musste nicht stoppen und kann nun seine gesamte Bot­

Fahrplan fahren, und Charterbusse, die nur auf Bestellung

maximal 8 Byte breite Data Field zur Verfügung. Mittels

Bits sendet. Dieses sogenannte Error Flag ist der sprich­

schaft unangefochten zu Ende übertragen.

fahren. Beide Modelle finden wir auch bei CAN. Botschaf­

DLC (Data Length Code) wird die genaue Anzahl der Nutz­

wörtliche Elefant im Porzellanladen des CAN-Protokolls.

Verlierer einer Arbitrierung wechseln zunächst in den Emp­

ten können in regelmäßigen Abständen zyklisch gesendet

bytes angegeben. Nach dem Data Field folgt das 15 Bit

Denn wo immer es auftaucht, verletzt es bewusst geltende

fangsmodus und warten, bis der Gewinner seine Botschaft

werden, oder aber nur auf Anforderung.

große Check Field oft auch Prüfsumme oder Cyclic Redun­

Regeln, zumeist die Bitstuffing-Regel. Dadurch wird die be­

fertig übertragen hat. Sobald der Bus wieder frei ist, grei­

CAN-Busse in Fahrzeugen leben hauptsächlich von zykli­

dancy Check — CRC genannt.

troffene CAN-Übertragung so deutlich zerstört, dass alle

fen sie für einen erneuten Sendeversuch darauf zu. Die Bus-

schen Übertragungen. CAN-Busse sind im Pkw kürzer als

Aus allen zu übertragenden Bits errechnet der Sender diese

Steuergeräte am CAN-Bus selbst nur lokal feststell­ bare

und die Arbitrierungslogik verhindern so nicht nur Kollisio­

40m und im Lkw kürzer als 200m. Somit sind hohe Über­

Prüfsumme. Mathematisch formuliert tut er dies mittels

Fehler wahrnehmen. Es folgt ein zweites Error Flag, weil ja

nen (Collision Avoidance), sondern sorgen auch für einen

tragungsraten möglich, die ein zyklisches Senden erlauben,

einer Division der zu übertragenden Bitfolge durch das Po­

nun alle übrigen Steuergeräte den durch das erste Error

prioritätengesteuerten Buszugriff; denn je kleiner der nu­

ohne dass die Buslast zu hoch wird.

lynom 15-ten Grades 0xC599 oder 1x15 + 1x14 + 1x10 + 1x8 + ­1x7 

Flag erzeugten Fehler sehen. Danach wird für 8 rezessive

merische Wert eines Identifiers, desto höher ist die Priori­

Lange CAN-Busse wie in Gebäudekomplexen oder Indus­

+ 1x4 + 1x3 + 1x0 auf dem binären Körper, also x ∈ {0,1}.

Bits gewartet. Man nennt diese Error Delimiter. Die beiden

trieanlagen jedoch ermöglichen aufgrund ihrer Länge von

Jeder Empfänger tut dasselbe mit den ankommenden Bits.

Error Flags und den Error Delimiter nennt man ­Error Frame

Kilometern nur kleine Übertragungsraten. Dort macht ein

Danach vergleicht er beide Sequenzen und bewertet die

(Bild 5). Er ist unverzichtbar für die netzweite Datenkonsis­

zyklisches Senden von Botschaften nur mit entsprechend

empfangene Botschaft nach dem rezessiven CRC-Delimi­

tenz.

langen Zyklen Sinn. Jedoch können Daten auf Bestellung

ter im Acknowledge Slot (ACK-Slot). 0 steht für gut, 1 für

Wired-AND-Buslogik: 0 = dominant

Arbitrierungslogik

Sender A

Sender B

Buspegel

Sender

Bus

Deutung

0

0

0

0

0

Weiter

0

1

0

0

1

Fehler

1

0

0

1

0

Stopp

1

1

1

1

1

Weiter

ID 10 ID 9 Sender A

1

1

ID 8

ID 7

ID 6

ID 5

ID 4

ID 3

ID 2

ID 1

ID 0

0

0

1

0

0

1

1

0

0

CAN-Bus

1

1

0

0

Sender C

1

1

0

1

ID 8

ID 7

ID 10 ID 9

1

0

0

1

1

0

CAN-Knoten C verliert Arbitrierung Einstellung des Sendens und Übergang in Empfangszustand

Bild 3: Dominanz des Null-Bits und die Arbitrierung

1/8

Fehler. Eine CAN-Botschaft wird nach dem rezessiven

0

gesendet werden. Zum Übertragen von Daten gibt es den Data Frame (Bild 4), zum Anfordern von Daten den Remote Frame. Weil der Identifier den Inhalt der Daten bezeichnet, wird in ei­ nem Remote Frame derselbe Identifier zum Anfordern von Daten benutzt wie im Data Frame für die Übertragung der angeforderten Daten. Damit es beim Arbitrieren nicht zu Problemen kommt, wenn ein Remote Frame und der dazu­ gehörige Data Frame kollidieren, gibt es am Ende des Iden­ tifiers das Remote Transmission Request Bit (RTR), welches

Error

S R I O Identifier T D F R E

r

DLC

Data Field

Checksum

1

1

4 Bits

0-8 Byte

15 Bits

11 Bits

1

Arbitration Field

1

Control Field

Bild 4: CAN Data Frame

Data Field

Check Field

D A D E C E L K L

EOF

1

7 Bits

1

1

ACK Field

Error Frame

CAN Message

(Primary) Error Flag

(Secondary) Error Flag

Error Delimiter (8 bits)

Bild 5: CAN Error Frame

1/9

Datenkommunikation im Automobil Teil 2

Fehler müssen korrigiert werden! Der Sender der fehlerhaf­

Note Gut aus, um die Korrektheit der Nachrichtenübertra­

Im ersten Teil dieser Reihe [5] befassten wir uns allgemein

ten Botschaft tut dies durch Wiederholung, sobald der

gung zu bestätigen. Schlechte Noten anderer Steuergeräte

mit seriellen Bussystemen. In weiteren Folgen werden die

CAN-Bus wieder frei ist, also nach dem Error Frame und

würden dadurch überschrieben und blieben zunächst unge­

seriellen Bussysteme LIN, FlexRay und MOST behandelt.

ITM. Allerdings gibt es keine Garantie für sofortiges Wie­

hört. Jedoch senden diese nach dem ACK-Delimiter ein

Der interessierte Leser findet zu den bereits veröffentlich­

derholen, denn nach jedem ITM darf jedes Steuergerät be­

­Error Flag.

ten Themen auf der Vector E-Learning Plattform [6] ergän­

ginnen zu senden und die Arbitrierung entscheidet, welche

Liegt überhaupt keine gute Bewertung vor und bleibt der

zende und vertiefende Informationen.

Botschaft sich durchsetzt. Die Fehlererholzeit hängt also

ACK-Slot rezessiv, stellt der Sender einen ACK-Fehler fest

von der Nachrichtenpriorität und der Buslast ab.

und bricht seine Nachrichtenübertragung mit einem Error

Literatur und Links:

Was würde passieren, wenn ein Steuergerät per Error Flag

­Flag ab.

[1] de.wikipedia.org/wiki/Controller_Area_Network

Fehler signalisiert, wo keine sind? Laufende Nachrichten­

[2] Unruh, J.; Mathony, H. J.; Kaiser, K.H: Error Detection

übertragungen würden grundlos abgebrochen und die

Die Grenzen von CAN

Analysis of Automotive Communication Protocols. SAE

Kommunikation würde erliegen. Man vermeidet dies durch

Noch immer ist CAN die am häufigsten verbaute Bustech­

­International Congress 1990.

Selbstüberwachung der CAN-Controller mittels Fehlerzäh­

nik im Automobil. Jedoch hat CAN systemische Grenzen.

[3] www.vector.com

ler. Erkennt ein Steuergerät einen Fehler als erstes, d.h. es

Durch das Prinzip Arbitrierung ist CAN selbst bei zykli­

[4] www.vector-academy.de

sendet das erste der beiden Error Flags, dann muss es sei­

schem Senden von Botschaften nicht deterministisch. Das

[5] Christmann, E.: Datenkommunikation im Automobil Teil 1:

nen Zähler um 8 Punkte erhöhen. Als Sender des zweiten

bedeutet, dass sehr zeitkritische Anwendungen mit CAN

Architektur, Aufgaben und Vorteile serieller Bussysteme.

Error Flags muss es nur um 1 hochzählen. Wird eine Bot­

nicht hinreichend sicher funktionieren. Zudem können mit

[6] elearning.vector.com

schaft ohne Fehler empfangen, darf der Zähler um 1 redu­

CAN maximal nur eine Million Bits pro Sekunde übertragen

ziert werden. Erkennt das Steuergerät den Fehler beim

werden. Zum anderen ist CAN durch das hohe Maß an Si­

Senden, erhöht es den Transmission Error Counter (TEC),

cherheit zu teuer für einfache Anwendungen, die darauf

anderenfalls den Receive Error Counter (REC). Übersteigt

verzichten können.

einer dieser Zähler den Wert 127, schaltet der CAN-Control­

Fahrerassistenz oder autonomes Fahren aber auch Kom­

ler in den Modus Error Passive um. Nun kann er kein Error

fortanwendungen im Bereich Audio und vor allem Video er­

­Flag bestehend aus dominanten Bits mehr senden, also

fordern deutlich höhere Datenübertragungsraten und er­

kein anderes Steuergerät mehr unterbrechen oder stören.

heben dadurch höhere Ansprüche bzgl. rechtzeitiger Ver­

Er kann jetzt nur noch Error Flags mit rezessivem Pegel er­

fügbarkeit von Daten. In diesen Bereichen haben sich

zeugen und dadurch lediglich sich selbst beim Senden stö­

Bussysteme wie FlexRay und Netzwerke wie MOST und

ren. Der TEC wird im Fehlerfall weiter inkrementiert, bis er

Ethernet etabliert. Aber auch CAN wurde weiterentwickelt,

beim Wert 255 das Abschalten des Steuergeräts erzwingt

und mit CAN FD ist eine Erweiterung von CAN geschaffen

(Bild 6).

worden, welche deutlich höhere Übertragungsraten er­

CAN-Botschaften werden benotet

Standard ISO 11898‑1:2015 vor, in dem CAN FD enthalten ist.

Jede Nachrichtenübertragung wird von allen Empfängern

Auf der anderen Seite füllt LIN (Local Interconnect Net­

gleichzeitig benotet. Sie alle senden in die Übertragung des

work) die Lücke bei der kostengünstigen Vernetzung von

Senders, exakt im ACK-Bit eine Bewertung zurück. Man

Sensoren und Aktoren im Komfortbereich, wie beispielswei­

nennt so etwas eine In Transmission Response oder auch In

se der Steuerung von Fensterhebern, Sitzen, Außenspiegeln,

Frame Acknowledgement. Ein dominanter Pegel entspricht

Schiebedächern oder der Klimaanlage.

Ernst Christmann, Physiker, Mathematiker ist Senior Technical Trainer im Bereich Software Tools für Steuer­ gerätetests und Steuergeräteentwicklung und seit 2004 bei der Vector Informatik GmbH in Stuttgart tätig.

möglicht. Seit Dezember 2015 liegt der überarbeitete CAN

der Note Gut, ein rezessiver Pegel der Note Mangelhaft. Da der Sender den ACK-Slot rezessiv sendet, reicht nur eine

Zuverlässige Steuergerätevernetzung Unsere Spezialisten von Vector [3] unterstützen Hersteller und Zulieferer der Fahrzeug- und anderen Branchen nicht nur bei der CAN-Vernetzung, sondern auch bei den Kommu­ nikationssystemen wie LIN, FlexRay, CAN FD und Ethernet.

Reset

Error Flag

Error Active

REC > 127 oder TEC > 127

Error Passive

TEC > 255

REC < 128 und TEC < 128 Error Flag

Error Delimiter Software Reset nach 128 x 11 rezessiven Bits Bus OFF

Bild 6: Zustände eines CAN Controllers

1/10

Error Delimiter

Wir bieten durchgängige Ketten aus Werkzeugen für Pla­ nung, Design, Entwicklung und Wartung, aber auch Soft­ warekomponenten und Basissoftware für AUTOSAR-Steuer­ geräte. Für den Einstieg in die Steuergerätevernetzung vermitteln wir Grundlagen zu CAN, LIN, FlexRay und Ether­ net in Seminaren. Für die notwendigen Fertigkeiten im Um­ gang mit oben genannten Werkzeugen lernen Ingenieure und Techniker in Workshops mit den vielfältigen Entwick­ lungsaufgaben rund um die Elektronik im Automobil ver­ traut zu werden [4].

1/11

1/12

1/13

1/14

Bild 1: Kalibrieren über CAN FD mit CANape

Schnelles Messen und Reprogrammieren CAN FD liefert hohe Bandbreiten bei moderaten Kosten Seit jüngstem bietet sich das neue CAN-FD-Protokoll (CAN mit flexibler Datenrate) neben FlexRay und Ethernet als kostengünstige Alternative zum Übertragen großer Datenvolumen an. Wichtige Einsatzgebiete sind das Programmieren von Flash-Speichern und das Kalibrieren von automotive Steuergeräten. So ist im Kalibrier-Protokoll ASAM XCP in der aktuellen Ver-sion 1.2 bereits die XCP-Transportschicht für CAN FD integriert. Mit den beiden genannten Anwendungsfällen haben sich die Netzwerkspezialisten von Vector Informatik auseinandergesetzt. Dabei wurde untersucht, wie CAN FD sich gegenüber den verfügbaren Alternativen bewährt.

nungen bildet die Annahme einer 100%igen Busauslastung

(Bild 4, Bild 7) belegen die Übereinstimmung der mathemati­

sowie die in Bild 2 und Bild 3 aufgeführten Feldgrößen der

schen Prognosen mit den praktisch ermittelten Messwerten.

CAN- und CAN-FD-Frames. Allerdings lässt sich die Größe

Vergleicht man die gewonnen Messdaten von CAN FD mit

der Frames weder für CAN noch für CAN FD eindeutig vor­

einer Messung über CAN zeigt sich, dass der Datendurchsatz

hersagen. Um das Synchronisieren der Busteilnehmer auf

von CAN FD um den Faktor 1,3 bis 5,4 ­höher ist (Bild 6).

Signalflanken zu gewährleisten, wurde in die zu sendenden Frames inhaltsabhängig zusätzlich eine variable Anzahl

Paketverknüpfungen mit CAN FD

Füll-Bits eingefügt, weshalb ein Best- und Worst-Case-­

XCP on CAN FD birgt darüber hinaus weiteres Optimie­

Berechnung durchgeführt wurde.

rungspotenzial: So ist es wahrscheinlich, dass die Kommu­

Die Ergebnisse der Datendurchsatzberechnung lassen sich in

nikationspfade bestehender Steuergeräte-Software nach

Form eines Bandes veranschaulichen (Bild 4, Bild 5). Um die­

einer Migration zu CAN FD weiterhin auf eine acht Byte

se theoretisch ermittelten Werte zu verifizieren, wurde mit

Datenübertragung beschränkt sind und XCP somit lediglich

Hilfe einer Simulationsumgebung ein realistischer Kalibrier­

von der höheren Übertragungsfrequenz profitieren kann.

vorgang in der Praxis nachgebildet. Der Laboraufbau – be­

Um die Nutzdatenübertragungsrate zu optimieren, könn­

Seit Jahren steigt der Code-Umfang der immer leistungs­

Protocol), in dessen aktueller Version 1.2 CAN FD als neue

stehend aus der Kalibrier-Software CANape, geeig­ neter

ten bei XCP on CAN FD die Nutzdaten kleiner XCP-Pakete

fähiger werdenden Steuergeräte im Automobil kontinuier­

XCP-Transportschicht integriert ist. XCP erlaubt es Mess-

Schnittstellen-Hardware sowie einer PC-basierten Steuerge­

zusammengefasst und in einem CAN FD Frame als Paket

lich an, so dass größere Datenmengen beim Kalibrieren der

und Kalibrierwerkzeugen, wie beispielsweise CANape (Bild 1)

räteemulation – ermöglichte es, die Kommunikationszeiten

verschickt werden Bild 8. Vector erarbeitet derzeit einen

Steuergeräte und beim (Re)Programmieren ein ständig

von Vector, Parameter während des Betriebs in Echtzeit zu

zwischen Sender und Empfänger jeweils am Aus- und Ein­

Vorschlag, in einer zukünftigen XCP-Spezifikation Paket­

wachsender Zeit- und Kostenfaktor ist. Neue und schnellere

verändern und die Auswirkungen auf den Algorithmus mes­

gang des CAN-/CAN-FD-Treibers zu messen. Die Ergebnisse

verknüpfungen für CAN FD zu ermöglichen.

Bussysteme wurden daher seit dem CAN-Bus eingeführt,

stechnisch zu erfassen. Je nach Komplexität der Anwen­

um den Bandbreitenengpass zu beheben. Die Einführung

dung und Anzahl der gemessenen Signale kann dabei die

von CAN FD als weiterer Lösungsansatz für diese Aufga­

Bandbreite des Übertragungsmediums schnell an Grenzen

benstellung wird im Weiteren beleuchtet und den etablier­

stoßen. Mit bis zu 64 Bytes Nutzdatenlänge und Daten­

ten Bussystemen gegenüber gestellt.

raten bis zu mind. 5 MBit/s in der Datenphase erweitert CAN FD gegenüber CAN die Nutzungsmöglichkeiten von

In-Vehicle Messung und Kalibrierung

XCP on CAN spürbar.

Im Rahmen der Steuergeräteentwicklung stellt das Kali­

1/16

brieren der zahlreichen Parameter von Regel- und Steuer­

XCP on CAN FD Datendurchsatz in Theorie und Praxis

algorithmen einen maßgeblichen Anwendungsfall dar. Die

Um den maximal möglichen Datendurchsatz von XCP on

Steuergeräteentwickler bedienen sich dazu vorzugsweise

CAN FD abschätzen zu können, wurden die Frame- bzw.

des vom ASAM e.V. standardisierten Mess- und Kalibrier­

Nutzdatengrößen bei der Ausführung einer Steuergeräte­

protokolls XCP (Universal Measurement and Calibration

messung verglichen. Basis für die Datendurchsatzberech­

Bild 2: Die Struktur ­eines CAN-Frames

Bild 3: Die Struktur ­eines CAN-FD-­ Frames

1/17

Schnelles Messen und Reprogrammieren

Bild 5: Berechnete ­Datendurchsätze eines Kalibriervorgangs mit CAN FD (fA = 500 kBit/s)

zur Verfügung. Im zyklischen Kommunikationsablauf des Time Triggered Protokolls sind alle PDUs (Protocol Data Unit) in Slots fest vordefiniert. Reserviert man viele Slots für Diagnose Service Requests wie den Download, be­ Bild 4: Gemessener und berechneter CAN-FD-Datendurchsatz ­einer Steuergerätemessung

schneidet das die Bandbreite für die Nutzdaten. Realisti­ sche Konfigurationen sehen pro Zyklus 4...8 PDUs mit je

Bild 8: Schnellere Datenübertragung durch XCP-Paketverknüpfungen bei CAN FD

42...255 Bytes für Diagnose Services vor. Unter Anwendung von Pipelined Programming haben die Vector Ingenieure Download-Raten von 40...60 KByte/s ermittelt.

Flash-Programmierung

Auch Ethernet eignet sich mit Diagnostics over IP (DoIP)

Das (Re)Programmieren von Flash-Speichern ist der zweite

nach ISO 13400-2 zum Reprogrammieren von Steuerge­

bei 270…370 KByte/s bei vier MBit/s in der CAN-FD-Daten­

treffen zu können, müssen weitere Tests mit leistungsfähi­

Anwendungsfall, bei welchem von schnelleren Netzwerk­

räten. Im Test mit 100-MBit-Ethernet und einem typischem

phase. Die real gemessenen Werte liegen jedoch deutlich

geren CPUs durchgeführt werden. Die wesentliche Erkennt­

protokollen wesentliche Verbesserungen zu erwarten sind.

Mikrocontroller mit einer reinen Flash-Schreibrate von

darunter (Bild 9). Erstaunlicherweise wirken die Optimie­

nis der Messungen ist jedoch, dass CAN FD gegenüber CAN

In den drei Flash-Phasen „Löschen“, „Download/Program­

180  KByte/s sind die Ergebnisse deutlich von der Puffergrö­

rungsstrategien Kompression und Pipelining mit der ver­

einen deutlich höheren Datendurchsatz liefert (Bild 9); da­

mieren“ und „Verifizieren“ ist bei konventionellen CAN-Bus­

ße des TransferData-Service abhängig. Mit 16 KByte Puffer

wendeten Testumgebung bei CAN FD kontraproduktiv. Hin­

bei sind die Migrationsaufwände überschaubar.

systemen die Download-Zeit ein wesentlicher Faktor, der

erreicht der Durchsatz circa 150 KByte/s und liegt so bereits

tergrund dafür ist, dass die Programmierzeit des internen

durch schnellere Bussysteme wie FlexRay, Ethernet und

nahe am Limit des im Test verwendeten Flash-Speichers.

Flash-Speichers beim verwendeten Laboraufbau zum be­

Fazit und Ausblick

grenzenden Faktor des Flashvorgangs wird und somit Op­

Insgesamt ist ein objektiver Vergleich der Bussysteme CAN

CAN FD beeinflusst werden kann. Unabhängig vom Übertragungsprotokoll sind beim Down­

Reprogrammierung via CAN FD

timierungen der Download-Phase wirkungslos bleiben. Um

FD, FlexRay und Ethernet aufgrund verschiedener Mikro­

load zusätzliche Optimierungsstrategien wie Datenkom­

Da von Seiten der Halbleiterhersteller noch keine Mikrocon­

allerdings allgemeinere Aussagen über den Datendurch­

controller und Randbedingungen momentan noch schwie­

pression und Pipelined Programming sinnvoll. Durch das

troller mit CAN-FD-Unterstützung verfügbar sind, setzen

satz sowie die Wirksamkeit von Optimierungen für CAN FD

rig, dennoch sind Tendenzen klar erkennbar. Bei FlexRay

Komprimieren mit einem LZSS-(Lempel-Ziv-Storer-Szy­

die Netzwerkspezialisten von Vector für Messungen bei

manski)-Algorithmus verringert sich zwar das zu übertra­

CAN FD ein Mikrocontroller-Board ein, bei dem der

gende Datenvolumen, allerdings hängt seine Effizienz stark

CAN-FD-Controller in einem FPGA implementiert ist. Der

von der Datenstruktur ab und das Entpacken erzeugt im

Software-Stack auf dem Board besteht aus einem Stan­

Steuergerät zusätzlich eine nicht unerhebliche CPU-Last.

dard Vector UDS Boot-Loader. Die ISO 15765-2 Transport­

Das Pipelined Programming hingegen stellt eine Art Paral­

schicht und der CAN-Treiber wurden für die Unterstützung

lelisierung dar: Während ein Datensegment im Steuergerät

von CAN FD erweitert. Für einen schnellen Versuchsaufbau

noch geschrieben wird, erfolgt bereits die Übertragung des

wurde zum Download das Simulations- und Testwerkzeug

nächsten Segments. Der mögliche Performance-Gewinn

CANoe verwendet, da zu diesem Zeitpunkt bereits die

dieses Verfahrens ist daher am Größten, wenn die Pro­

CAN-FD-Unterstützung vorhanden war. Diese Software

grammierzeiten kleiner als die Datenübertragungszeiten

nutzt eine externe DLL, die die Flash-Programmier-Sequenz

sind.

und Transport Layer Funktionen bereitstellt. Zukünftig

FlexRay und Ethernet

Verfügung stehen.

FlexRay bietet eine Übertragungsrate von 10 MBit/s, diese

Mit der verwendeten Transportschicht liegt die theoretisch

steht jedoch für die (Re)Programmierung nicht vollständig

erreichbare Übertragungsrate beim Flashen über CAN FD

wird für CAN FD das Vector Flash-Werkzeug vFlash zur

Bild 6: Vergleich ­gemessener Daten­ durchsätze einer XCP Messung über CAN und CAN FD

1/18

Bild 7: Gemessene Datendurchsätze eines Kalibriervorgangs mit CAN FD (fA = 500 kBit/s)

Bild 9: Vergleich Download- und ­Programmierzeiten bei CAN und CAN FD

1/19

schränken sich hohe Download-Geschwindigkeiten und hohe Performance für Echtzeitnutzdaten gegenseitig aus. 100-MBit-Ethernet liefert die höchsten Übertragungsra­

Armin Happel (Dipl.-Ing.) arbeitet seit 1997 bei Vector Informatik GmbH im Bereich Embedded Software-Entwicklung und ist dort für den ­Produktbereich Flash Bootloader verantwortlich.

ten, erfordert aber eine komplexe Software-Konfiguration und im Vergleich zu CAN FD fallen höhere Hardware-Kos­ ten an. CAN FD präsentiert sich am ausgewogensten, es erreicht hohe Datenraten und ermöglicht weiteres Verbes­ serungspotenzial zu moderaten Kosten. Zusätzlich ermög­ licht die enge Verwandtschaft zwischen CAN und CAN FD eine vergleichsweise einfache Migration auf den neuen

Erik Sparrer (Dipl.-Ing.) arbeitet seit 2013 Vector Informatik GmbH als Software-­ Entwickler im Bereich Calibration and Measurement mit ­Fokussierung auf die Integration von Kommunikations-Hardware und Datenaquisesystemen für CANape.

CAN-Standard: Beide Protokolle basieren auf dem gleichen Physical Layer, dies ermöglicht eine Wiederverwendung von Transceivern, Verkabelung und Bustopologien. Da sich auch das Kommunikationsprinzip nicht geändert hat, kann be­

Peter Decker (Dipl.-Ing. (FH)) ist seit 2002 bei Vector Informatik GmbH und arbeitet als ­Product Manager im Bereich Multibusentwicklung für CANoe/CANalyzer.

stehendes Know-how weiter verwendet werden. Anpas­ sungen auf den bei der Kalibrierung und Reprogrammie­ rung betroffenen Software-Schichten fallen vergleichswei­ se gering aus. Mit CAN FD sind sowohl beim Messen und Kalibrieren als

Vector Informatik: CAN FD durchgängig unterstützt

auch bei dem Reprogrammieren von Steuergeräten signifi­

Steuergeräte-Software für CAN FD lässt sich nur effizi­

kante Durchsatzgewinne zu erreichen. Beim (Re)Program­

ent entwickeln, wenn sämtliche Komponenten der

mieren verlagert sich damit der Engpass zunehmend auf

Werkzeugkette das verbesserte CAN-Protokoll unter­

den Flash-Speicher. Weiterentwicklungen der verwendeten

stützen. Aus Sicht von Vector wird CAN FD in Zukunft

MCUs hinsichtlich der Speicherzugriffszeiten versprechen

eine strategische Rolle bei der Fahrzeugvernetzung ein­

damit eine weitere Leistungssteigerung. Auch die Bestre­

nehmen. Entsprechende Priorität wird auf die Unter­

bungen von Vector, die XCP-Spezifikationen um eine Paket­

stützung des neuen Systems gelegt und kann aktuell

verknüpfung bei CAN FD zu erweitern, zeigt die noch vor­

bereits eine durchgängige CAN-FD-Werkzeugkette an­

handenen Möglichkeiten zur Leistungssteigerung des neu­

bieten: dazu zählen die Analyse- und Simulationswerk­

en Protokolls auf.

zeuge CANoe und CANalyzer ab Version 8.1, die Daten­

Weiterentwicklungen der verwendeten MCUs hinsichtlich

bank CANdb, das Mess- und Kalibrierwerkzeug CANape

der Speicherzugriffszeiten versprechen damit eine weitere

ab Version 12.0 sowie das Flash-Werkzeug vFlash ab

Leistungssteigerung. Auch die Bestrebungen von Vector,

Version 2.6. Das Portfolio der dazu passenden Schnitt­

die XCP-Spezifikationen um eine Paketverknüpfung bei

stellen-Hardware reicht vom einfachen Bus-Interface

CAN FD zu erweitern, zeigt die noch vorhandenen Möglich­

mit USB-Anschluss über aktive High-Performance-Inter­

keiten zur Leistungssteigerung des neuen Protokolls auf.

faces mit eigener CPU bis hin zum VT System, der mo­ dularen Test-Hardware von Vector. Auch in MICROSAR,

Deutsche Übersetzung der englischen Veröffentlichung im

der AUTOSAR-Basissoftware von Vector, wird CAN FD

CAN Newsletter, Ausgabe September/2014.

zukünftig enthalten sein. Abgerundet wird das Portfolio

Erstklassige Lösungen für Ihre CAN- und CAN-FD-basierten Projekte Alles aus einer Hand

mit der Prozesslösung PREEvision. Bildrechte: Alle Bilder Vector Informatik GmbH

Steigern Sie die Effizienz in Ihren Projekten mit dem Einsatz der kompletten Werkzeugkette von Vector:

Literaturhinweis:

> Werkzeuge zum Testen, Flashen und Kalibrieren

> Komfortabel konfigurierbare AUTOSAR-Basis-

von Steuergereräten > Flexible Netzwerk-Interfaces

software > Weltweite Engineering Services und Trainings

CAN-FD-Spezifikation V1.0, Robert Bosch GmbH

> Leistungsfähiges Scope zur bitgenauen Signaldarstellung

Informationen und Downloads: www.can-solutions.de

Mehr CAN-Power: Profitieren Sie von über 25 Jahre CAN-Erfahrung von Vector.

CAN / CAN FD Poster kostenlos bestellen: www.vector.de/can_fd_poster

1/20

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Datenkommunikation im Automobil Teil 3: Kostengünstiger Datenaustausch mit LIN

1/22

des LDF erzeugen Generierungswerkzeuge die Software-­

Verzicht auf alles Entbehrliche

Komponenten für die LIN-Kommunikation. Zusätzlich ist

Besonders beim Design des Physical Layer ist das Streben

das LDF die Basis für Analyse-, Mess- und Testwerkzeuge

nach Kosteneinsparung unübersehbar. Eine gewöhnliche

oder Restbus-Emulatoren (Bild 1).

Eindrahtleitung (Single Wire) muss reichen. Auf Span­

Zwei Merkmale unterscheiden LIN von allen anderen Bus­

nungsteiler wird verzichtet und man verwendet als Span­

systemen. Erstens gibt es zwei Arten von Steuergeräten,

nungspegel für LIN-Bits die Versorgungsspannung für ei­

nämlich einen LIN-Master pro LIN-Bus und weitere LIN-­

nen Bit-Wert von 1 und die Fahrzeugmasse für den Bit-

Slaves, sowie zweitens die Möglichkeit Slave-Steuergeräte

Wert von 0. Ein Kommunikationscontroller ist auch nicht

in sehr hohen Stückzahlen zu fertigen und als Massenware

erforderlich und als Clock bedarf es nicht immer eines teu­

„von der Stange“ an Fahrzeughersteller zu verkaufen. Diese

ren, geeichten Quarzes, sondern ein preiswerter On-Chip-­

hohen Stückzahlen verringern den Preis weiter und der

Resonator mit einer Frequenz-Toleranz von bis zu ±14% tut

Markt bietet Herstellern Steuergeräte, für die sie keine ei­

es auch. In der Praxis ist man jedoch zunehmend von den

genen Entwicklungsaufwände betreiben müssen. So finden

billigen RC-Clocks abgerückt und LIN-Controller gibt es in­

sich z. B. in jedem Fahrzeug viele kleine Elektromotoren in

zwischen auch.

Sitzen, Spiegeln, Fenstern und Schiebedächern. Und wozu

Ein LIN-Transceiver sorgt für die physikalische Busankopp­

sollte jeder Hersteller zu deren Ansteuerung eigene Steuer­

lung. Ein Pegel von weniger als 40% der Versorgungsspan­

geräte entwickeln?

nung wird vom Empfänger als logische Null interpretiert,

Große Zulieferer bieten solche Slave-Steuergeräte an, de­

oberhalb von 60 % der Versorgungsspannung als Eins. Die­

ren Fähigkeiten sie mittels einer einheitlichen Syntax, der

ser große Unterschied zwischen Null und Eins macht die

sogenannten Node Capability Language, im standardisier­

Bits recht störfest, jedoch sind die Flanken sehr steil, was

ten Node Capability File (NCF) beschreiben. So beschreibt

immer elektromagnetische Störungen zur Folge hat. Um sie

das NCF Leistungsmerkmale eines LIN-Slaves, wie etwa

gering zu halten wurde die maximale Datenrate auf 20 kBit/s

die Frame- und Signaldefinitionen, Bitraten oder Diagnose­

und die maximale Gesamtkapazität auf 2  µF begrenzt.

parameter und ist im Rahmen des Systemdesigns die Grund­

Wegen der Leitungskapazitäten sowie der Kapazitäten der

lage zur automatisierten Erstellung eines LDF.

Transceiver kann ein LIN-Bus von 40  m Länge maximal

Die detaillierte und übersichtliche Spezifikation für LIN

16 Steuergeräte verbinden.

­leistete einen weiteren Beitrag zum Erfolg. Die zum Jahres­ wechsel 2010 auf 2011 vorliegende LIN-Spezifikation

Wie in der Schule

2.2A [2] definiert den Physical Layer, das Kommunikations­

Ein Cluster besteht aus einem LIN-Master und mindestens

protokoll, den LIN-Work-Flow, die LIN-API sowie die Diag­

einem LIN-Slave. Die Kommunikation wird vom Master ge­

Lange Zeit war es üblich, immer größer werdende Zahlen

Konsortium verhilft LIN zum Durchbruch

nose und Konfiguration der LIN-Knoten. Seit Januar 2016

regelt. Software in den Mikrocontrollern übernimmt die

von Sensoren, Aktoren und Motoren direkt mit einem zent­

Ein wesentlicher Grund für die schnelle Etablierung von LIN

liegt der ISO-Standard für LIN vor (ISO 17987). Part 1, 2, 3,

Aufgabe des fehlenden Kommunikationscontrollers. Jedes

ralen Steuergerät zu verbinden. Jedoch stieß diese Ent­

war die Gründung des LIN-Konsortiums  [1], in dessen

4 und Part 6 werden in den nächsten 2 Monaten publiziert.

LIN-Steuergerät, auch der Master, verfügt über eine soge­

wicklung rasch an Grenzen: Der Verkabelungsaufwand stieg,

­Rahmen sich namhafte Kfz-Hersteller und Zulieferer sowie

Part 7 folgt kurz darauf.

begleitet von größerem Platzbedarf, zunehmendem Ge­

Halbleiter- und Tool-Hersteller zusammengeschlossen hat­

Master-Task, mit deren Hilfe er die Kommunikation steuert

wicht und mehr Störanfälligkeit. Es wurden immer mehr

ten, um einen globalen Kommunikationsstandard für den

(Bild 2).

unterschiedliche Kabelbaum- und Steckervarianten nötig,

Sensor-/Aktor-Bereich zu schaffen. Mit der Definition eines

Wie in der Schule darf am LIN-Bus nicht unaufgefordert

was wiederum die Produktion, Installation und Wartung er­

einfachen und kostengünstigen Physical Layer, der sich an

gesprochen werden. Wie ein Lehrer stellt die Master-Task

schwerte. Man erkannte bald, dass auch in diesem Bereich

der K-Line (ISO 9141) orientiert, sowie eines einfachen und

Fragen, die von der jeweils zuständigen Slave-Task zu be­

eine Vernetzung der Komponenten über ein Bussystem ideal

schlanken Kommunikationsprotokolls, legte das LIN-­Kon­

sein würde.

sortium das Fundament für die Realisierung einfacher und

Jedoch bietet CAN bei diesen Anwendungen mehr Sicher­

kostengünstiger Steuergeräte.

heit als nötig, wie etwa Sitz-, Fenster-, Spiegel- und Klima­

Dabei hatte das LIN-Konsortium nicht nur die eigentliche

steuerungen. Für solche Komponenten ist der Preis von

LIN-Kommunikation im Blick, sondern auch eine ­einheit­liche

CAN zu hoch. Hersteller suchten folglich nach billigeren

Entwicklungsmethodik, den sogenannten ­LIN-Work-Flow.

­Lösungen. Einfache Busse mit kleinen Übertragungsraten

Jedoch setzt sich manchmal selbst gut Gemeintes und gut

wurden entwickelt. Allerdings kochte jeder Hersteller sein

Geplantes in der Realität nicht durch. Der LIN-Work-Flow

eigenes Süppchen, bis der Preisdruck zu mehr Einheit

ist ein Beispiel dafür.

zwang. Ende 1999 wurde LIN (Local Interconnect Network)

Zur Beschreibung eines gesamten LIN-Clusters dient eine

geboren. Der folgende Beitrag erklärt den Siegeszug von

einheitliche Syntax, die LIN Configuration Language, und

LIN im Automobil und erläutert seine Funktionsweise.

das in dieser Syntax verfasste LIN Description File (LDF).

Inzwischen hat sich diese Technologie auf breiter Front

Das LDF beschreibt alle Eigenschaften eines LIN-Clusters,

durchgesetzt, so dass man LIN in fast jedem Fahrzeug findet.

besonders die Kommunikation der Steuergeräte. Mit Hilfe

nannte Slave-Task. Der LIN-Master besitzt zusätzlich eine

antworten sind. Manchmal stellen Lehrer rhetorische Fra­ NCF

NCF

LIN Node Capability Language Specification

LINSlave

LIN-Cluster Design-Tool

LINSlave

LIN-Cluster

ter-Task Fragen stellen, die von der Slave-Task des Masters

LIN Configuration Language Specification LIN-Cluster Generator

LINSlave

LINMaster

ge, die sie selbst beantworten. Genauso kann die Ma­ beantwortet werden.

LDF

Busanalyzer Emulator LIN-Bus

LIN-Master

LIN-Slave 2

LIN-Slave 3

Slave-Task

Slave-Task

Slave-Task

Slave-Task Master-Task

Bild 1: LIN-Cluster

LIN-Slave 1

LIN-Bus

Bild 2: LIN-Master und LIN-Slaves

1/23

Datenkommunikation im Automobil Teil 3

t0 t1 t2

t0

LINSchedule

t1

Frame Slot 1

LINHeader 1 Master

Frame Slot 1

LINSlave 1

Frame Slot 2

Frame Slot 2 Header 2

LIN-Bus

Receive Response Frame Header

Frame Response

IFS Frame Header

LIN-Frame 1

ohne weitere Bedingung mit einer LIN-Response beantwor­

wird ein Fehler erkannt, weil zu diesem Zeitpunkt ja norma­

tet werden. Deswegen bezeichnet man solche LIN-Frames

lerweise das rezessive Stopp-Bit folgen müsste. Aufgrund

als Unconditional Frames.

dieses Fehlers schaltet der LIN-Slave in einen Modus, um

Jedoch ermöglicht die LIN-Spezifikation, diese Starrheit zu

Receive Response

das nun folgende Sync Byte auszumessen. Es enthält den

lockern und Frames nur im Bedarfsfall zu senden. Dafür

Wert 0x55, also einen Wechsel von Nullen und Einsen, deren

stehen die beiden Frametypen „Sporadic Frame“ und „Event

Receive Response

fallende Flanken gemessen werden, um die Sendegeschwin­

­Triggered Frame“ ab der LIN-Version 2.0 zur Verfügung.

digkeit des Masters zu bestimmen. Am Ende sind alle

Ein Sporadic Frame ist ein Unconditional Frame, der sich

LIN-Slaves mit ±1,5 % Genauigkeit auf den Master geeicht.

mit anderen Unconditional Frames denselben Frame Slot

Header 3

Send Response

LINSlave 3

malen“ SCI-Frame sehen. Jedoch im 13-ten dominanten Bit Frame Slot 3

Send Response

LINSlave 2

Frame Slot 3

t2

Receive Response

IFS (Inter Frame Space)

Frame Response

Frame Header

LIN-Frame 2

Send Response

teilt und vom LIN-Master bedarfsabhängig übertragen

Frame IFS Response

LIN-Frame 3

Kommunikationszyklus

Bild 3: LIN-Kommunikationszyklus

wird (Header und Response). Kollisionen sind ausgeschlos­

Der nun folgende ID besteht aus sechs Bit, die durch zwei

sen weil nur der Master als einziges Steuergerät solche

Paritätsbits gesichert sind. Der ID und die beiden Paritäts­

­Frames senden darf. Liegt kein Bedarf beim Master vor,

bits werden zusammen als Protected Identifier (PID) be­

bleibt der entsprechende Frame Slot leer.

zeichnet. Die ersten 60 IDs (0 bis 59) stehen für die Nutz­

Event Triggered Frames kommunizieren sporadische Ver­

datenkommunikation zur Verfügung. ID=60 und ID=61 sind

änderungen oder Ereignisse auf Seiten der LIN-Slaves. Auch

Die zeitliche Abfolge der Fragen erfolgt mittels einer oder

CAN wird bitweise gesendet, bei LIN byteweise. Das SCI

für Diagnose. Die letzten zwei Identifier, ID=62 und ID=63,

sie entsprechen Unconditional Frames, die sich einen ge­

mehrerer LIN-Schedules, die in sogenannten Frame Slots

sendet jedes Byte mit dem Least Significant Bit (LSB)

sind reserviert.

meinsamen Frame Slot teilen, doch mit dem Unterschied,

organisiert sind. Jeweils zu Beginn eines Frame Slots über­

­zuerst und rahmt es mit einem dominanten Start-Bit (0)

Die Frame Response besteht aus mindestens einem und

dass einem gemeinsamen Frame Header mehrere Frame

trägt die Master-Task einen Frame Header, welcher den

und einem rezessiven Stopp-Bit (1) ein. Man nennt dies

maximal acht Datenbytes, gefolgt von einer acht Bit gro­

Responses von unterschiedlichen LIN-Slaves zugeordnet

Frame-ID beinhaltet. Da dieser ID jedem Slave bekannt ist,

­SCI-­Frame. Ein LIN-Frame setzt sich folglich aus einer An­

ßen Checksumme für die Fehlererkennung. In den ersten

sind. Welcher Slave den Event Triggered Frame ­Header mit

wird ein Slave den Header als (An)Frage erkennen und ant­

zahl von SCI-Frames zusammen, die wegen des Start-Bits

LIN-Versionen wurde die klassische Checksumme einge­

einer Response beantwortet, hängt vom Bedarf der ent­

worten (Bild 3).

mit einer fallenden Flanke zur Synchronisation beginnen

führt, ab LIN-Version 2.0 gilt die erweiterte.

sprechenden LIN-Slaves ab. Ein Bedarf liegt vor, wenn neue

Am Identifier erkennen die Slave-Tasks ihre jeweilige Rolle:

(Bild 4).

Die klassische Checksumme entspricht dem Inversen der

Daten zu übertragen sind. Damit die Empfänger wissen,

Eine Slave-Task erkennt, dass sie nun die Daten zum gefor­

Im Header steckt allerdings mehr als nur der ID. Wegen der

Modulo-256-Summe aller Datenbytes. Ein Empfänger bil­

welche Daten sie erhalten, wird im ersten Byte der Frame

derten ID in der sogenannten Frame Response bereitstellen

billigen, nur ungenau geeichten RC-Clocks können die

det seinerseits ebenfalls die Modulo-256-Summe der an­

Response des Event Triggered Frame der PID des zugrunde

muss, andere sehen, dass sie die nun zu erwartenden Daten

LIN-Slaves einen ID erst verstehen, nachdem sie einem hin­

kommenden Bytes und addiert als letztes die ankommende

liegenden Unconditional Frame mitgeteilt.

auswerten müssen, die übrigen stellen erleichtert fest, dass

reichend genauen Eichprozess unterzogen wurden.

Checksumme. Ist das Ergebnis nicht 0xFF, liegt ein Fehler

Senden mehrere Slaves, folgt eine Kollision für deren Auflö­

vor. Die erweiterte Checksumme bezieht zusätzlich den

sung der LIN-Master verantwortlich ist. Er unterbricht die

PID mit in die Berechnung ein.

Schedule nach der Kollision und schiebt eine weitere Sche­

sie nichts tun müssen. Frame Header und Frame Response ergeben zusammen­

Erst nach einer Eichung wird LIN verständlich

genommen einen LIN-Frame. Wie bei CAN steckt im ID eine

Zum Eichen überträgt der LIN-Master zunächst eine Sync

Nachrichtenadressierung und jedes LIN-Steuergerät darf

Break, um alle LIN-Slaves von dessen Beginn in Kenntnis zu

Üppige Pausen für langsame Mikrocontroller

enthalten sind, die sich den Unglücks-Frame-Slot teilen.

die Daten lesen (Broadcast).

setzen. Die Sync Break ist mit mindestens 13 dominanten

Kostengünstige Mikrocontroller sind einfach und oft lang­

Zur Diagnose von LIN-Slaves stellt LIN zwei reservierte Un­

dule ein, in der die Header für alle Event Triggered Frames

Bits und einem Stopp-Bit bewusst in der Länge so über­

sam. Deswegen erlaubt LIN, die Übertragung der Frame

conditional Frames zur Verfügung. Sie haben die ID= 60 für

Datenübertragung mittels LIN-Frames

SCI-Fehler dehnt, dass der langsamste LIN-Slave einen ­

Response nach dem LIN-Header ein wenig verzögert zu

den Diagnostic Request und ID=61 für die Diagnostic Res­

Weil ein Kommunikationscontroller fehlt, erfolgt die Daten­

feststellen muss. Selbst bei 12 dominanten Bits plus ein

beginnen (Response Space), und auch Sendepausen ­

ponse. LIN nutzt das auch bei CAN übliche ISO-TP [3] als

übertragung bei LIN über die serielle Schnittstelle (Serial

Stopp-Bit würde ein langsamer LIN-Slave mit der erlaub­

(­Interbyte Spaces) zwischen den einzelnen SCI-Frames ein­

Transportprotokoll und einheitliche Diagnosedienste [4, 5].

Communication Interface — SCI) des Mikrocontrollers. Bei

ten Toleranzabweichung von -14 % noch einen ganz „nor­

zu­legen. Insgesamt darf sich die Frame Response so um

LIN-Frame Frame Header mind. 14 bit

10 bit

Sync Break Sync Byte

Frame Response 10 bit

10 bit

PID

Data 1

Sync Break mind. 13 bit

Sync Break Delimiter (mind. 1 bit)

…

10 bit

10 bit

10 bit

Data 7

Data 8

Check

… Interbyte Space (optional)

Response Space (optional)

StartBit

StoppMSB Bit

LSB

Interbyte Space (optional)

40 % verlängern. Dasselbe gilt für den Frame Header. Aller­

Status- und Netzwerkmanagement

dings braucht ein LIN-Master keine Pausen, denn er ist ein

Die LIN-Spezifikation definiert ein Statusmanagement und

Steuergerät, welches in den allermeisten Fällen auch an

ein Netzwerkmanagement.

einem CAN-Bus angeschlossen ist. Die CAN-seitigen An­

Das Statusmanagement schreibt den LIN-Slaves ab LIN

forderungen erlauben keine Verwendung billiger Mikrocont­

2.0 vor, dass sie dem LIN-Master erkannte Übertragungs­

roller. Der Master nutzt die ihm erlaubten 40 % mehr Zeit

fehler wie Paritäts- oder Checksummenfehler anzeigen

auf ein längeres Sync Break: Er halbiert bei dessen Versen­

müssen. Dazu bedarf es eines Bits in einem Unconditional

dung seine Taktrate, sodass 18 dominante Bits plus zwei

­Frame, den der Slave an den Master sendet (Status ­Frame).

rezessive Bits herauskommen. Die Zeitreserve von 40 %

Weitere Informationen über die Art des Fehlers sind mög­

muss man beim Design der LIN-Schedule unbedingt be­

lich, jedoch keine Pflicht. Auch gibt es keine Anweisungen,

rücksichtigen.

wie Fehler behandelt werden. Diese Verantwortung trägt der Entwickler.

Vier Typen von Frames

Nutz-Bits SCI-Frame

1/24

Nicht so sicher wie CAN

Bild 4: LIN-Frame

Die Aufgabe des LIN-Netzwerkmanagements ist in erster

Durch die LIN-Schedule ist ein starres Zeitraster vorgege­

Linie das Ein- und Ausschalten der Slaves, also der Über­

ben. Jeder Header, der laut Schedule gesendet wird, muss

gang vom normalen Kommunikationszustand (Operational)

1/25

in den Sleep Mode und umgekehrt (Bild  5). Erkennen die

weiteren Folgen werden die seriellen Bussysteme FlexRay

LIN-Slaves für vier Sekunden keine Busaktivität, dürfen sie

und MOST behandelt. Der interessierte Leser findet zu den

vom Operational-Zustand in den Sleep-Zustand wechseln.

bereits veröffentlichten Themen auf der Vector E-Learning

Bei LIN 2.1 und höher müssen sie dies binnen 10 Sekunden

Plattform [10] ergänzende und vertiefende Informationen.

getan haben. Mit einem Sleep-Kommando kann der LIN-­ Master seine Slaves jederzeit in den Sleep Mode schalten.

Literatur und Links:

Umgekehrt durchläuft ein LIN-Slave eine Initialisierung, um

[1] www.lin-subbus.org

vom Sleep Mode in den Operational-Zustand zu schalten,

[2] LIN Specification Package Revision 2.2A

wenn er ein Wake-Up-Signal gefolgt von einem gültigen

[3] Road vehicles — Diagnostics on Controller Area Network

Header erkennt. Das Wake-Up-Signal besteht aus einem

(CAN) — Part 2: Network layer services. International Stan­

dominanten Puls von mindestens 250 Mikrosekunden und

dard ISO 15765-2.4, Issue 4, 2002-06-21.

höchstens 5 Millisekunden Dauer und kann nicht nur vom

[4] Road vehicles — Diagnostics on controller area network

Master, sondern von jedem LIN-Steuergerät gesendet wer­

(CAN) — Part 3: Implementation of diagnostic services. In­

den. Die LIN-Spezifikation begrenzt die Initialisierungspha­

ternational Standard ISO 15765-3.5, Issue 5, 2002-12-12.

se auf 100 Millisekunden, das heißt, der LIN-Master muss

[5] Road vehicles — Diagnostic systems — Part 1: Diagnostic

spätestens nach dieser Zeitspanne mit einem Header be­

services. International Standard ISO  14229-1.6, Issue 6,

ginnen. Bleibt er passiv, sendet der entsprechende LIN-­Slave

2001-02-22.

ein weiteres Wake-Up-Signal. Abstände und Anzahl an

[6] www.vector.com

Wiederholungen solcher Signale sind ebenfalls festgelegt.

[7] www.vector-academy.de [8] Christmann, E.: Datenkommunikation im Automobil Teil 1:

Fragen Sie die Experten

Architektur, Aufgaben und Vorteile.

Unsere Spezialisten von Vector [6] unterstützen Hersteller

[9] Christmann, E.: Datenkommunikation im Automobil Teil 2:

und Zulieferer der Fahrzeugindustrie und anderen Bran­

Sicherer Datenaustausch mit CAN.

chen nicht nur bei der LIN-Vernetzung, sondern auch bei

[10] elearning.vector.com

Kom­munikationssystemen wie CAN, FlexRay, CAN FD und Ethernet. Wir bieten durchgängige Ketten aus Werkzeugen für Pla­ nung, Design, Entwicklung und Wartung, aber auch Soft­

Ernst Christmann, Physiker, Mathematiker ist Senior Technical Trainer im Bereich Software Tools für Steuer­ gerätetests und Steuergeräteentwicklung und seit 2004 bei der Vector Informatik GmbH in Stuttgart tätig.

warekomponenten und Basissoftware für AUTOSAR-Steuer­ geräte. Auch für den Einstieg in die Steuergerätevernet­ zung schulen wir Grundlagen zu CAN, LIN, FlexRay und Ethernet in Seminaren. Wir vermitteln notwendige Fertig­ keiten im Umgang mit oben genannten Werkzeugen in Workshops, mit dem Ziel, Ingenieure schnell mit den vielfäl­

Erfahrung in Serie. Setzen Sie auf die weltweit führende Lösung für LIN!

tigen Entwicklungsaufgaben rund um die Elektronik im Au­ tomobil vertraut zu machen [7]. Im ersten Teil dieser Reihe [8] befassten wir uns allgemein mit seriellen Bussystemen, im zweiten Teil mit CAN [9]. In

Solutions for LIN

Power On

Für Ihre professionelle LIN-Vernetzung finden Sie bei Vector die umfassendste Lösung für jede Entwicklungsphase:

Initialization

Empfang des Wake-Up-Signals oder interner Grund für das Aufwecken des LIN-Clusters

Sleep

Empfang des Sleep-Befehls oder tBus_Idle > 4 s

Bild 5: LIN-Netzwerkmanagement

1/26

Nach spätestens 100 ms

Operational

> Entwerfen Sie LIN-Netzwerke systematisch

> Bringen Sie Steuergeräte zur Serienreife mit aus-

> Simulieren, analysieren und testen Sie effizient

gereiften Kalibrier-, Stress- und Logging-Tools > Vertrauen Sie auf die Vector Service-Teams für

Steuergeräte und Netzwerke mit CANoe und den LIN-Interfaces > Setzen Sie auf die zuverlässigen LIN-Softwarekomponenten

Entwicklung, Schulung und Support Steigen Sie ein: www.lin-solutions.de

Nutzen Sie für Ihre erfolgreichen Projekte die erprobten Werkzeuge, die skalierbaren Module und über 25 Jahre Vernetzungs-Know-how von Vector!

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Bussysteme

IIII FlexRay

Serielle Bussysteme im Automobil Teil 4: FlexRay für den Datenaustausch in sicherheitskritischen Anwendungen FlexRay geht zum ersten Mal mit dem BMW X5 in Serie. Er wurde im August 2006 auf dem Pariser Autosalon der Öffentlichkeit vorgestellt und ist ab März dieses Jahres in Deutschland erhältlich. FlexRay sorgt dabei innerhalb des aktiven Fahrwerksystems für die sichere und zuverlässige Datenübertragung zwischen dem zentralen Steuergerät und den vier jeweils einem Stoßdämpfer zugeordneten Satellitensteuergeräte. Der Beitrag zeichnet den Weg von FlexRay ins Automobil nach und erläutert die wichtigsten Prinzipien des FlexRay-Bussystems. Von Eugen Mayer

L

aut Statistischem Bundesamt [1] war das Fahren auf Deutschlands Straßen noch nie so sicher wie im Jahr 2005. Bei beträchtlichem Zuwachs des Kraftfahrzeugbestandes ereigneten sich im Vergleich zum Vorjahr fast ein Prozent weniger Unfälle mit Personenschäden (336 619). Stark zurückgegangen ist dabei die Zahl der im Straßenverkehr Getöteten (5361, –8,2 %), Schwerverletzten (76 952, –4,6 %) und Leichtverletzten (356 491, –1 %). 2006 setzte sich dieser Trend fort: Zwischen Januar und August wurden 3260 Verkehrsteilnehmer getötet, was einem Rückgang um 7,8 % im Vergleich zum Vorjahreszeitraum entspricht. Die Zahl der Verletzten sank im gleichen Zeitraum um 5,8 %. Entscheidend zur Reduzierung der Unfälle und Minderung der Unfallfolgen tragen aktive Sicherheitssysteme beziehungsweise Assistenzsysteme bei, die den Fahrer beim Führen seines Fahrzeugs unterstützen. Eine Studie namhafter Fahrzeughersteller zeigt zum Beispiel, dass ESP die Anzahl der Schleuderunfälle um bis zu 80 % verringert [2]. Einen ebenso wichtigen

Elektronik automotive 2.2007 1/28

Bussysteme

FlexRay IIII

Beitrag zur Minderung der Unfallfolgen leisten die immer sichereren Fahrgastzellen und optimierten Rückhaltesysteme. Mit dem Ziel, bis 2010 die Zahl der Verkehrstoten zu halbieren, forciert die Kfz-Branche vor allem die Weiterund Neuentwicklung von innovativen aktiven Sicherheits- und Fahrerassistenzsystemen. Da es in diesem Zusammenhang nicht nur um das Informieren und Anweisen geht, sondern vielmehr um korrigierendes Eingreifen und Übernehmen von Fahraufgaben, kommt man ohne elektronische Schnittstellen zum Fahrwerk und zum Antrieb nicht mehr aus. Großes Potential wird der Kombination aus Brakeby-Wire- und Steer-by-Wire-Systemen zugeschrieben.

ten zur Übertragung der zunehmenden Anzahl von Steuer- und Statussignalen. Es handelt sich dabei in erster Linie um Signale, die aufgrund sehr zeitkritischer Regelungen nicht nur äußerst schnell, sondern auch absolut deterministisch zu übertragen sind. Folglich wächst die Bedeutung von Kommunikationssystemen im Automobil, die schnelle und deterministische Datenübertragung garantieren. Wegen des potentiellen Einsatzes von By-Wire-Systemen sind sie zudem mit fehlertoleranten Strukturen und Mechanismen auszulegen. Denn so vielfältig das Potential und die Vorteile von By-Wire-Systemen durch neue konstruktive Freiheiten, vereinfachte Montage oder einer Personalisierung des Fahrzeugs auch sein mögen, sie erhöhen die Anforderungen an die Datenübertragung in erheblichem Maße, weil sie zur Klasse der FailOperational-Systeme gehören. Diese müssen auch im Falle eines auftretenden Fehlers noch einwandfrei funktionieren. Diesen Anforderungen wird CAN mit seinem ereignis- und prioritätengesteuerten Buszugriff der durch physikalische Randbedingungen im Automobil hervorgerufenen beschränkten Übertragungsrate von 500 Kbit/s sowie dem Mangel an fehlertoleranten Strukturen und Mechanismen nicht gerecht [3].

 Erhöhte Anforderungen durch steigende Vernetzung

 FlexRay beantwortet die Frage nach Determinismus und Fehlertoleranz

Die Realisierung von immer anspruchsvolleren Sicherheits- und Fahrerassistenzfunktionen geht einher mit einer immer intensiveren Kopplung der elektronischen Steuergeräte und erfordert deshalb sehr hohe Datenra-

Die Gewissheit, dass CAN den wachsenden Anforderungen an die Datenübertragung im Automobil mittelfristig kaum mehr gerecht werden kann, führte zur Entwicklung mehrerer deterministischer und fehlertoleranter serieller Buswww.elektroniknet.de

systeme mit höheren Datenraten. Dazu gehören zum Beispiel TTP (Time Triggered Protocol) [4], Byteflight [5] oder auch TTCAN (Time Triggered CAN) [6]. Ein wesentlicher Grund für den Erfolg von FlexRay war die Gründung des FlexRay-Konsortiums [8], in dessen Rahmen sich im Jahre 2000 die beiden Kfz-Hersteller DaimlerChrysler und BMW sowie die beiden Chiphersteller Motorola und Philips zusammenschlossen. Basierend auf dem ursprünglich von BMW entwickelten Byteflight-Bussystem schuf das FlexRay-Konsortium den herstellerübergreifenden, deterministischen und fehlertoleranten Kommunikationsstandard FlexRay mit einer Datenrate von 10 Mbit/s für äußerst sicherheits- und zeitkritische Anwendungen im Automobil. Heute setzt sich das FlexRay-Konsortium aus sieben Core-Partnern zusammen: BMW, Bosch, DaimlerChrysler, Freescale, General Motors, Philips und Volkswagen. Nach und nach schloss sich dem FlexRay-Konsortium eine Reihe von Premium Associate Members an, wie beispielsweise Vector Informatik [7] und Associ-ate Members. Einen wichtigen Beitrag zum Erfolg von FlexRay leistet die detaillierte Dokumentation der FlexRay-Spezifikation. Die beiden wichtigsten Spezifikationen, das Kommunikationsprotokoll und der Physical Layer, liegen im Moment in der Version 2.1 vor. Diese und weitere Spezifikationen der FlexRayBustechnologie stehen auf der Homepage des FlexRay-Konsortiums zum Abruf bereit [8].

 Definierter Kommunikationszyklus verbietet unkontrollierten Buszugriff Ebenso wie bei der Datenkommunikation in einem CAN-Cluster liegt auch der Datenkommunikation in einem FlexRay-Cluster eine Multi-MasterKommunikationsstruktur zugrunde. Allerdings dürfen die FlexRay-Knoten nicht wie bei CAN im Zuge von anwendungsbezogenen Ereignissen unkontrolliert auf den Bus zugreifen. Sie müssen sich vielmehr an einen exakt definierten Kommunikationszyklus www.elektroniknet.de

. . . FlexRay- FlexRay- FlexRay- FlexRay- FlexRay- FlexRay- FlexRayZyklus 3 Zyklus 4 Zyklus 5 Zyklus 6 Zyklus 7 Zyklus 8 Zyklus 9 Statisches Segment

Dynamisches Segment

static slot 1

static slot 2

static slot 3

frame 1

frame 2

frame 3

Symbol Statisches NIT Window Segment ...

static slot n frame n

Statische FlexRay-Botschaften werden in jedem Zyklus übertragen

Dynamisches Segment 1 2 3 4

...

Symbol Statisches NIT Window Segment Minislots

frame 4 frame 3 frame 2 frame 1

n

Dynamische FlexRayBotschaften werden nur bei Bedarf ùbertragen

I Bild 1. Die Übertragung von Nachrichten kann bei FlexRay im statischen oder dynamischen Segment erfolgen. Während des „Symbol Window“ wird die Funktion des Buswächters überprüft; die „Network Idle Time“ (NIT) wird zur Uhrensynchronisation genutzt. (Quelle aller Bilder: Vector Informatik)

halten, der jeder FlexRay-Botschaft ein bestimmter Zeitschlitz zuordnet (Time Division Multiple Access, TDMA) und dadurch die Sendezeitpunkte sämtlicher FlexRay-Botschaften vorgibt (Bild 1). Die zeitgesteuerte Kommunikation sorgt nicht nur für deterministische Datenkommunikation, sondern auch dafür, dass alle Knoten eines FlexRayClusters unabhängig voneinander entwickelt und getestet werden können. Zudem wirkt sich das Entfernen oder die Integration von FlexRay-Knoten in ein bestehendes Cluster nicht auf den Kommunikationsablauf aus, was der in der Automobilentwicklung häufig propagierten Wiederverwendung entgegenkommt. Dem Paradigma zeitgesteuerter Kommunikationsarchitekturen folgend, besteht die grundlegende Logik der FlexRay-Kommunikation in der Auslö-

sung aller Systemaktivitäten durch das Erreichen bestimmter Punkte im Zeitablauf. Den dazu erforderlichen netzwerkweiten Gleichlauf der FlexRay-Knoten wird mittels verteiltem, fehlertoleranten Uhrensynchronisationsmechanismus sichergestellt: Alle FlexRay-Knoten korrigieren mittels regelmäßig übertragener Synchronisationsbotschaften nicht nur laufend den Beginn (Offsetkorrektur), sondern auch die Dauer (Steigungskorrektur) der Kommunikationszyklen (Bild 2). Dadurch erhöht sich sowohl die Bandbreiteneffizienz als auch die Robustheit der Synchronisation. Der FlexRay-Kommunikation kann entweder ein elektrischer oder ein optischer Physical Layer zugrunde gelegt werden. Für die elektrische Signalübertragung spricht die Einfachheit, woraus sich Kostenvorteile ergeben. Die vergleichsweise kostenintensive optische Signalübertragung zeichnet sich durch eine im Vergleich zur elektrischen Signalübertragung deutlich Lokale bessere elektromagUhren netische Verträglichkeit FlexRay- FlexRay- FlexRay- FlexRay- FlexRay(EMV) aus. Knoten Knoten Knoten Knoten Knoten Die FlexRay-Kommunikation ist nicht Offset- und Steigungskorrektur an eine bestimmte Topologie gebunden. Zyklusstart Eine einfache passive Globale Uhren Zyklusdauer Busstruktur ist genauso möglich wie eine aktive SterntopoloI Bild 2. Die FlexRay-Knoten führen während des gie oder eine KombiKommunikationszyklus eine Steigungskorrektur nation aus beidem (Bild durch, eine Offsetkorrektur erfolgt bei Bedarf am 3). Die Vorteile der Ende der „Network Idle Time“. aktiven Sterntopologie Elektronik automotive 2.2007 1/29

Bussysteme

FlexRay IIII

IIII FlexRay

statisches und ein dynamisches Zeitsegment (Bild 1). Von zentraler Bedeutung ist das statische Segment, mit dem jeder Kommunikationszyklus beginnt. Es ist in eine frei definierbare Anzahl von maximal 1023 gleich langen statischen Zeitschlitzen (static slots) unterteilt. Jedem statischen Zeitschlitz ist eine FlexRay-Botschaft zugeordnet, die von einem FlexRay-Knoten übertragen wird. Die Zuordnung von statischem Zeitschlitz, FlexRay-Botschaft und FlexRay-Knoten erfolgt mittels Slotnummer, Botschaftskennung (Identifier, ID) und dem Wert des auf jedem FlexRay-Knoten implementierten Slot-Counters. Damit pro Zyklus alle FlexRay-Botschaften in der richtigen Reihenfolge zeitlich korrekt übertragen werden, werden die Slot-Counter zu Beginn eines jeden statischen Zeitschlitzes auf allen FlexRay-Knoten synchron inkrementiert. Wegen der

dem synchronen Inkrementieren der Slot-Counter. FlexRay- FlexRay- FlexRay- FlexRayKnoten Knoten Knoten Knoten Allerdings werden die den Minislots zugewiesenen FlexRay-Botschaften Bus FlexRaynicht zwangsläufig in jedem KommuStern Knoten nikationszyklus übertragen, sondern lediglich bei Bedarf. Wenn kein Bedarf FlexRayvorliegt, werden die Slot-Counter nach Knoten der definierten Zeit eines Minislots inI Bild 3. FlexRay erlaubt Bus- und krementiert. Bei der Übertragung einer Sternstrukturen, oder wie in diesem dynamischen FlexRay-Botschaft verzöBeispiel eine kombinierte Topologert sich die Inkrementierung der Slotgie aus passivem Bus und aktivem Counter um die Zeit der BotschaftsüStern. bertragung (Bild 5). Die Zuordnung einer dynamischen bestehen primär in der Möglichkeit zum FlexRay-Botschaft zu einem Minislot Abschalten von fehlerhaften Kommulegt implizit die Priorität der FlexRaynikationszweigen beziehungsweise von Botschaft fest: Je niedriger die NumFlexRay-Knoten sowie im Aufbau grömer des Minislots, desto höher ist die ßerer Cluster mit idealen BusabschlüsPriorität der dynamischen FlexRaysen, wenn die physikalische SignalüberBotschaft, dementsprechend früher tragung elektrisch erfolgt. erfolgt die Übertragung und folglich Zur Minimierung des Ausfallrisikos ist vor dem Hintergrund eines besieht FlexRay die redundante Auslegrenzten dynamischen gung des Kommunikationskanals vor Zeitsegments auch die FlexRay- FlexRay- FlexRay- FlexRay- FlexRay(Bild 4). Dieser redundante KommuÜbertragungswahrKnoten Knoten Knoten Knoten Knoten nikationskanal kann allerdings auch scheinlichkeit höher. Kanal A zur Erhöhung der Datenrate auf bis zu Diejenige dynamische Kanal B 20 Mbit/s herangezogen werden. Die FlexRay-Botschaft, Wahl zwischen Fehlertoleranz und er- I Bild 4. Um das Ausfallrisiko zu minimieren, arbeitet die dem ersten Minislot FlexRay wahlweise mit zwei getrennten Kommunihöhter Übertragungsrate lässt sich für zugeordnet ist, wird bei kationskanälen. jede einzelne FlexRay-Botschaft treffen. Bedarf auf jeden Fall Schließlich sorgt ein unabhängiübertragen, wenn man ger Kontrollmechanismus (Buswächter garantierten äquidistanten und somit von einem ausreichend langen dyna– Bus Guardian) dafür, dass ein Flex- deterministischen Datenübertragung mischen Zeitsegment ausgeht. Ray-Knoten nur dann Zugang zum Bus ist das statische Segment prädestiniert Beim Kommunikationsdesign muss erhält, wenn er laut Kommunikations- für die Übertragung von echtzeit-rele- man sicherstellen, dass auch die dyzyklus an der Reihe ist. Dadurch wird vanten Botschaften. namische FlexRay-Botschaft mit der die Busmonopolisierung durch einen Im Anschluss an das statische Seg- niedrigsten Priorität übertragen werden defekten FlexRay-Knoten (Babbling ment folgt optional das je Kommuni- kann – zumindest, wenn sonst kein anIdiot) verhindert. kationszyklus gleich lange dynamische derer Bedarf mit höherer Priorität vorSegment. Auch dieses Segment ist in liegt. Der Designer eines FlexRay-CluZeitschlitze gegliedert, aber nicht in sters hat auch darauf zu achten, dass die  Statisches Segment überträgt statische Zeitschlitze, sondern in Minis- Übertragung der längsten dynamischen echtzeit-relevante Daten lots (Bild 1). Die Kommunikation im FlexRay-Botschaft möglich ist. Jeder Kommunikationszyklus ist gleich dynamischen Segment (Minislotting) Der Kommunikationszyklus wird lang und prinzipiell gegliedert in ein basiert ebenfalls auf Zuordnungen und durch zwei weitere Zeitsegmente komplettiert (Bild 1). Das Segment „Symbol Window“ dient zur Überprüfung slot counter Kanal A minislot der Funktion des Buswächters und m m+1 m+2 m+3 m+4 m+5 das Zeitsegment „Network Idle Time“ Frame ID m + 3 Frame ID m + 5 Frame ID m Kanal A t (NIT) schließt den KommunikationsKanal B Frame ID m + 7 Frame ID m + 3 zyklus ab. Während der NIT berechnen m m+1 m+2 m+3 m+4 m+5 m+6 m+7 m+8 die FlexRay-Knoten die zur Synchronislot counter Kanal B dynamic slot mit Übertragung dynamic slot ohne Übertragung sation der lokalen Uhren erforderlichen Dynamisches Segment Korrekturfaktoren. Am Ende der NIT I Bild 5. Im dynamischen Segment arbeitet FlexRay mit Minislots. Dabei ist jedem Minislot genau eine Botschaft zugewird im Bedarfsfall die Offsetkorrektur wiesen, die jedoch nicht zwangsläufig in jedem Kommunikationszyklus übertragen werden muss. durchgeführt (die Steigungskorrektur findet stets über den ganzen KommuElektronik automotive 2.2007 1/30

www.elektroniknet.de

nikationszyklus verteilt statt). Eine Datenübertragung findet während der NIT nicht statt.

 Sichere Datenübertragung durch CRC Die Übertragung von Signalen in einem FlexRay-Cluster erfolgt mittels der exakt definierten FlexRay-Botschaft, wobei es zwischen der im statischen Segment und der im dynamischen Segment übertragenen FlexRay-Botschaft im Aufbau prinzipiell keinen Unterschied gibt. Sie setzt sich stets aus einem Header, der Payload und dem Trailer zusammen (Bild 6). Der Header umfasst das 5 bit breite Statusfeld, die ID, die Payload Length und den Cycle Counter. Die HeaderCRC (11 bit) sichert Teile des Statusfeldes, die ID und die Payload Length mit einer Hamming-Distanz von sechs. Die ID kennzeichnet die FlexRay-Botschaft und korrespondiert mit einem Zeitschlitz im statischen oder dynamischen Segment. Im dynamischen Segment entspricht die ID der Priorität der FlexRay-Botschaft. Die einzelnen Bits des Statusfeldes spezifizieren die FlexRay-Botschaft genauer. Beispielsweise zeigt das „Sync Frame Indicator Bit“ an, ob die FlexRay-Botschaft zur Uhrensynchronisation verwendet werden darf. Im Anschluss an den Header folgt die Payload. Insgesamt lassen sich mit einer FlexRay-Botschaft bis zu 254 byte an Nutzdaten transportieren. Der Trailer umfasst die den Header und die Payload sichernde CRC (24 bit). Bei einer Payload bis zu 248 byte garantiert die CRC eine Hamming-Distanz von sechs, für eine größere Payload liegt die HammingDistanz bei vier [8].

 Durchgängige Lösung für Entwicklung, Simulation und Verifikation Bereits im Jahr 2001 bot die Vector Informatik die erste Lösung für die Entwicklung von FlexRay-Systemen an. In der Zwischenzeit erhält der Entwickler ein umfassendes Portfolio [9]. Dazu gehören Werkzeuge für Design, Entwicklung, Simulation, Analyse, Test und Kalibrierung von Steuergeräten und www.elektroniknet.de

Bussysteme

FlexRay-Botschaft Header ID 5 bit 11 bit

Payload

Trailer

DLC

CRC

cycle Data 0 count

Data 1

7 bit

11 bit

6 bit

0 - 127 Worte [0 - 2032 bit]

Data 2

...

Data n

CRC CRC CRC 24 bit

I Bild 6. Eine FlexRay-Botschaft besteht aus Header, Payload und Trailer. Pro Nachricht können bis zu 254 Bytes an Nutzdaten übertragen werden.

verteilten Netzwerken. Mit dem DaVinci Network Designer FlexRay existiert eine Umgebung zum effizienten Design der Vernetzungsarchitektur und der Kommunikationsbeziehungen. Simulation, Analyse und Test von FlexRay-Systemen erfolgen mit CANoe. FlexRay, dessen Multibus-Konzept den gleichzeitigen Betrieb der Bussysteme FlexRay, CAN, LIN und MOST ermöglicht. Um das Systemverhalten des FlexRay-Netzwerkes bei Fehlern und Störungen genau zu untersuchen, generiert FRstress diese auf einem Kanal im FlexRay-Cluster. Für den direkten Zugriff auf Steuergeräte-interne Größen benötigt der Entwickler ein spezielles Mess- und Verstellprotokoll: XCP on FlexRay. Im Rahmen der Entwicklung des aktiven Fahrwerksystems des neuen BMW X5 setzten die BMW-Ingenieure das Mess-, Kalibrier- und Diagnose-Tool CANape ein. Als XCP on FlexRay Master misst und verstellt CANape einzelne Steuergeräteparameter direkt über FlexRay. Neben Software entwickelt Vector Informatik auch Stacks für Steuergeräte. Mit den FlexRay-Softwarekomponenten lassen sich Applikationen unkompliziert an verschiedene Bus- oder Betriebssysteme anbinden. Für den hardwareseitigen Zugang zu FlexRayBussen sorgen passende Businterfaces für die USB-, PCI- und PCMCIASchnittstelle eines PC oder Notebooks. Das notwendige Basiswissen, um sich mit den vielfältigen Entwicklungstätigkeiten rund um die Steuergerätekommunikation im Automobil vertraut zu machen, werden von der Vector Academy [10] im Rahmen von Seminaren zu CAN, LIN, FlexRay und MOST vermittelt. Die bisher erschienenen drei Teile dieser Beitragsreihe befassten sich allgemein mit dem seriellen Datenaus-

tausch im Automobil, mit CAN und LIN. Im letzten Beitrag wird auf die Übertragung von Multimediadaten mit MOST eingegangen. Der interessierte Leser findet zu den bereits veröffentlichten Themen auf der Internetseite der Vector Academy ergänzende und vertiefende Informationen, unter anderem in Form von E-Books. sj

Literatur und Links [1] www.destatis.de [2] www.bosch.de [3] Mayer, E.: Datenkommunikation im Automobil. Teil 2: Sicherer Datenaustausch mit CAN. Elektronik automotive 2006, H. 8, S. 34ff. [4] www.tttech.com [5] www.byteflight.com [6] www.can-cia.org/can/ttcan [7] www.vector.com [8] www.flexray.com [9] www.flexray-solutions.de [10] www.vector-academy.de

Dipl.-Ing., Dipl.-Techpaed. Eugen Mayer hat nach der Berufsausbildung zum Kommunikationselektroniker an der FH Ravensburg/Weingarten Elektronik und an der Universität Stuttgart Elektrotechnik und Berufspädagogik studiert. Er arbeitet seit 1999 bei der Vector Informatik und ist dort als Senior Trainer tätig.

Elektronik automotive 2.2007 1/31

Entwicklung + Test

IIII Nutzfahrzeug-Elektronik

einschließlich der Tragschicht aufgefräst. Der Universalrotor vermischt das so zerkleinerte Material mit Bindemitteln, um es an Ort und Stelle wieder verwenden zu können (Bild 1).

Für schweres Gerät

(Bild: Bomag GmbH)

 Ohne Elektronik geht nichts

BeiderElektronik-EntwicklungmodernerBaumaschinenlässtsichaufPrüfständen bereits ein großer Teil testen und simulieren. Im fortgeschrittenen Entwicklungsstadium jedoch finden Tests und Probeläufe vorzugsweise unter Realbedingungen auf Baustellen oder in Testgeländen statt. Von Timo Löw, Andreas Nacke und Hans-Werner Schaal

U I Bild 1. Arbeitsprinzip des MPHUniversalrotors: Zerkleinerung und Durchmischung des Materials unter Zugabe von Wasser und Schaumbitumen. (Bild: Bomag GmbH)

Elektronik automotive 2.2008 1/32

Maschinensteuerung

Dieselmotor

Die in Boppard ansässige Bomag GmbH gehört seit 2005 zur Fayat-Gruppe und produziert Maschinen für die Erd-, Asphalt- und Müllverdichtung sowie Stabilisierer/Recycler. Seit 2006 gehören auch Fertiger und Fräsen zum Produktspektrum. Pro Jahr verlassen rund 30 000 Bomag-Maschinen das Stammwerk in Boppard. Bereits im Jahr 1997 wurde erstmals eine Bomag-Maschine mit einer elektronischen Fahr- und Maschinensteuerung ausgerüstet. Seitdem ist ein Großteil des Know-how in der Elektronik verankert, so dass man längst eine eigene Abteilung für Elektronikund Software-Entwicklung unterhält. Bomag orientiert sich hinsichtlich der Vernetzungstechnik an den Standards der Automobilindustrie und setzt den CAN-Bus ein, wo immer es sinnvoll ist. Das Elektronikkonzept wurde zunächst auf den großen 10- bis 15-t-Maschinen etabliert und anschließend auf die kleineren Maschinen portiert. Da Hardwareund Software-Komponenten innerhalb der gesamten Firmengruppe möglichst häufig wiederverwendet werden sollen, steht ein modulares Konzept im Mittelpunkt. Das hat auch eine Vereinheitlichung des Entwicklungs- und Testequipments über die Grenzen der einzelnen Standorte hinweg zur Folge.

Elektronik findet sich überall in den Maschinen, angefangen bei Fernsteuerungen für kleine Maschinen, die wahlweise über Spiralkabel, Infrarot oder Funk gesteuert werden, bis hin zu GPS in den großen Fahrzeugen. Spezielle Drive-by-Wire-Lenkungen mit invertierbarer Lenklogik ermöglichen ein ergonomisches Fahren in jeder Situation und erlauben spezielle Lenkmanöver wie Fahren mit Versatz im Hundegang oder exaktes Fahren an Rändern. Bei der dynamischen Bodenverdichtung durch Vibration erfassen Sensoren kontinuierlich die Bodenbeschaffenheit und reduzieren so die zeitintensiven, konventionellen Verdichtungsmessungen auf ein Minimum. Am Display wird dem Fahrer grafisch signalisiert, wo noch Verdichtungsarbeit notwendig ist. Die Option GPS erlaubt eine satellitengestützte, flächendeckende Verdichtungskontrolle, bei der die Elektronik die Baustellenkoordinaten, Verdichtungsleistung, Bodenbeschaffenheit, Frequenz, Geschwindigkeit und Betriebszustand der Walze über die gesamte Baustelle hinweg dokumentiert. Zukünftig sorgen Funknetze für den Datenaustausch zwischen den im Verbund fahrenden Maschinen. Der neue Stabilisierer/Recycler des Typs MPH 125 mit einem Betriebsgewicht von 24,5 t und einer Leistung von 440 kW ist die Maschine mit dem umfangreichsten Elektroniksystem und den meisten CAN-Knoten. In der Stabilisierung wird er zur Verbesserung und Verfestigung vorhandener Bodenmaterialien durch das Einmischen von Kalk, Flugasche oder Zement eingesetzt. Beim Einsatz als Recycler fräst der MHP 125 alte, beschädigte Schwarzdecken und Wegebefestigungen auf und zerkleinert diese. Dabei wird die gesamte Straßenkonstruktion www.elektroniknet.de

Alle Bomag-Maschinen einer Produktfamilie verfügen über die gleiche Steuerung; durch Bandende-Parametrierung erhalten sie ihren spezifischen Funktionsumfang. Das modulare Produktkonzept haben die Elektronik-Entwickler deshalb in einem modularen CAN-basierten Netzwerk-Cluster abgebildet (Bild 2). CAN 1 als zentraler Body-CAN-Bus ist mit den meisten Busteilnehmern verbunden und arbeitet auf Basis des CANopen-Protokolls, was die Verwendung von StandardAutomatisierungskomponenten erlaubt. Neben dem Fahrzeughauptrechner, dem Datensammler des Vorderrahmens und dem I/O-Modul für den Hinterrahmen zählen zu den CAN-1-Teilnehmern die Bedien- und Anzeigeelemente des Cockpits. Am Datensammler sind herkömmliche analoge und digitale Sensoren angeschlossen, zum Beispiel Hydraulik-Drucksensoren und Füllstandsmesser. Das I/O-Modul auf dem Hinterrahmen ist für die Steuerung des höhenvariablen Rotors, der Querneigung und der für den Transport absenkbaren Kabine verantwortlich. Durch die Anbindung der Anzeige- und Bedienelemente (Joysticks, LC-Display, Schalter) an den Bus konnte der Verkabelungsaufwand deutlich reduziert werden; einen CANopen-Fahrhebel mit Reibbremse hat Bomag speziell für dieses Konzept entwickeln lassen (Bild 3). Der Powertrain-Bus ist als CAN 2 definiert (Bild 2) und verbindet Fahrzeughauptrechner, Motorsteuerung, Lenk- und Fahrhebel inklusive Bedienkonsolen rechts und links. Er bedient bewusst nur eine geringe Zahl von Busteilnehmern, da ein Ausfall dieses Busses die Maschine unweigerlich zum Stillstand bringen würde. Auf CAN 2 können die Protokolle J1939 und CANopen parallel zum Einsatz kommen. Eine Besonderheit der Fahrsteuerung ist die Grenzlastregelung, die dafür sorgt, dass der Deutz-Dieselantrieb immer www.elektroniknet.de

CAN 2

Datensammler

I/O-Modul 2 Bitumen

DosierRechner

I/O-Modul 3 Schaumbitumen

Bedienkonsole links

I/O-Modul 1 Hinterrahmen

Bedienkonsole rechts

LC-Display

Display Dosiersteuerung CAN/USB

Tablet-PC RS 232 GPS

CAN 1

Triebstrang Dosiersystem (Basis) fùr Wasser Grundfunktionen Dosiersystem (Erweiterung) fùr (Mögliche) Peripherie- Bitumen und Schaumbitumen Zusatzfunktionen wie GPS, Diff. GPS, Tablet-PC, WLAN

optimal ausgelastet ist und bei hoher Fräsbelastung nicht überlastet und damit abgewürgt werden kann – beispielsweise beim weiteren Absenken des Rotors in den Boden. In Abhängigkeit von der Bodenbeschaffenheit reduziert oder erhöht die Regelung die Fahrgeschwindigkeit, so dass eine dynamische Leistungsaufteilung zwischen höherer Fräsleistung bei niedriger Geschwindigkeit und niedrigerer Fräsleistung bei hoher Arbeitsgeschwindigkeit gegeben ist. Je nach Ausrüstung des MPH 125 gibt es neben CAN 1 und CAN 2 noch einen dritten Datenbus CAN 3 (Bild 2). Er verbindet den optionalen Dosierrechner mit einem zusätzlichen Display und der notwendigen Aktorik zur Wassereinspritzung. Ebenso wird CAN 3 zur Anbindung der Dosieranlage für Bitumen-Emulsion und Schaumbitumen benötigt

Entwicklung + Test

ErweiterungsFunktionsbus II

Funktionsbus I

Powertrain-Bus

 Netzwerk-Cluster mit mehreren CAN-Bussen

Drahtlose Anbindung von Entwicklungs- und Analysewerkzeugen

m die Bediener in der Fahrerkabine nicht durch MessEquipment abzulenken, wurde für die Entwicklungs- und Analysewerkzeuge CANoe und CANalyzer von Vector Informatik jetzt erstmals eine drahtlose Anbindung realisiert, um die Kommunikation der verschiedenen Fahrzeug-Busse nun aus der Distanz aufzuzeichnen und zu analysieren. Die Qualitätsanforderungen im Erdund Verkehrswegebau nehmen kontinuierlich zu, während für die Bauunternehmer der Kosten- und Zeitdruck ansteigt. Wichtige Aufgabenstellungen und Herausforderungen sind in diesem Bausektor die Verdichtung des Bodens und eine kosten-, rohstoff- und energiesparende Methode der Straßenerhaltung bzw. -erneuerung.

Nutzfahrzeug-Elektronik IIII

GPRS WLAN CAN 3

I Bild 2. Das ElektronikKonzept wird dem modularen Aufbau der Maschinen gerecht, so dass sich nach Kundenwunsch Optionen für Dosierrechner, Wassereinspritzung, Bitumenemulsion oder Schaumbitumen integrieren lassen. (Quelle: Bomag GmbH)

simulation). Im weiteren Verlauf der Steuergeräteentwicklung dienen die Modelle als Grundlage für Analyse, Test und Integration von Bussystemen und Steuergeräten. Die C-ähnliche Programmiersprache CAPL unterstützt den Anwender bei komplexen Projekten durch freie Programmierbarkeit. Ebenso lassen sich benutzerdefinierte Oberflächen zur Steuerung der Simulationen und der Testabläufe oder zur Anzeige der Analysedaten erstellen. Leistungsfähigere Testplätze mit verbesserten Echtzeit-Fähigkeiten lassen sich in einer Realtime-Konfiguration aufbauen. Dazu führt man die Restbussimulation und die eigentliche Testausführung auf einem eigenen Rechner unter einem optimierten Betriebssystem (Windows XP Embedded) aus, während für die grafische Benutzeroberfläche und die Auswertung ein

 Tools für Entwicklung, Analyse und Applikation Bei der Elektronikentwicklung setzt Bomag verschiedene Software-Tools der Vector Informatik GmbH ein. Diese bietet für die verschiedenen Aufgaben im Entwicklungsprozess entlang des V-Modells jeweils zugeschnittene Werkzeuge an, zum Beispiel CANoe für Netzwerkentwicklung und Steuergeräte-Tests, CANalyzer für die Analyse der Busdaten und CANape zur Applikation der Steuergeräte. Bei Entwicklungsbeginn bildet CANoe das Verhalten einzelner Busteilnehmer oder ganzer Teilnetze nach (Restbus-

I Bild 3. Blick in das Cockpit: Die Bedien- und Anzeigeelemente sind über CAN mit der Steuerelektronik verbunden. Durch eine konsequente Vernetzung hält sich der Verkabelungsaufwand in Grenzen. (Bild: Bomag GmbH) Elektronik automotive 2.2008 1/33

Entwicklung + Test

IIII Nutzfahrzeug-Elektronik

Nutzfahrzeug-Elektronik IIII

I Bild 4. Die J1939-spezifische Interpretation der Daten im TraceFenster erfolgt mit dem CANalyzer. J1939. (Bild: Vector Informatik GmbH)

getrennter PC zur Verfügung steht. Das System kann so auch als Testausführungsumgebung für einen Komponenten-HiL-Tester dienen. Das Analysewerkzeug CANalyzer (Bild 4) bietet zahlreiche Funktionen, um alle Arbeiten rund um die Busanalyse zu erleichtern. Diese reichen von der Auflistung des Busdatenverkehrs, der grafischen oder textbasierten Anzeige von Signalwerten, statistischen Auswertungen von Botschaften, Buslasten und Störungen bis hin zum gezielten Generieren von Busstörungen, um das Systemverhalten unter Nicht-Idealbedingungen zu testen. Der primäre Einsatzbereich von CANape liegt in der Kalibrierung elektronischer Steuergeräte, um Parametersätze, Kennlinien und Kennfelder zu optimieren. Unter VerwenI Bild 5. Die Erweiterung für CANalyzer und CANoe erlaubt drahtlosen Zugriff auf die Fahrzeugelektronik des MPH 125. (Quelle: Vector Informatik GmbH)

Dieselmotor

Maschinensteuerung

dung der standardisierten Mess- und Kalibrierprotokolle CCP (CAN Calibration Protocol) oder XCP (Universal Measurement and Calibration Protocol) lassen sich in Echtzeit Messwerte erfassen, Parameter verstellen und alle wichtigen Größen visualisieren. Hilfreich im Zusammenhang mit der Entwicklung von GPS-Anwendungen ist die CANape-Option GPS, die das System um die Visualisierung der aktuellen Fahrzeugpositionen auf einer elektronischen Landkarte ergänzt. Aufgezeichnete Messdaten lassen sich damit bei der Auswertung leichter interpretieren, da die geografischen Gegebenheiten zeitsynchron zu den fahrzeugspezifischen Daten angezeigt werden. Die Durchgängigkeit der VectorTools bewährt sich bei Bomag speziell

Datensammler

I/O-Modul 2 Bitumen

DosierRechner

I/O-Modul 3 Schaumbitumen

Bedienkonsole links

I/O-Modul 1 Hinterrahmen

Bedienkonsole rechts

LC-Display

CAN 2

CAN/USB

Tablet-PC

GPS

CAN 1

GPRS WLAN

Elektronik automotive 2.2008 1/34

Display Dosiersteuerung

CAN 3

bei der Arbeit mit mehreren Bussen und insbesondere der J1939/CANopenMultiprotokoll-Umgebung. Eine der Grundlagen für die Effizienz liegt in einem konsequent verwendeten Datenbankkonzept. Alle Mitglieder der Vector-Werkzeugkette greifen auf dieselben Datenbestände zu, so dass eine konsistente Speicherung aller Daten ohne unnötige Redundanzen und Fehlerquellen gegeben ist. Passend zu den eingesetzten Bussystemen sind zur Netzwerkbeschreibung die jeweils geeigneten Datenbasen bereits integriert oder werden automatisch generiert. Neben CAN unterstützen die Werkzeuge auch die Busse LIN, FlexRay und MOST sowie die höheren Protokolle J1939, J1587, NMEA2000, ISO11783 und CANopen. Bei Bomag kommen CANape sowie die CANalyzer/CANoe-Optionen für J1939 und CANopen zum Einsatz.

zum zu analysierenden Bussystem zwingend notwendig, so ist es jetzt durch eine Erweiterung möglich, per Funk mit dem Prüfling Kontakt aufzubauen. So wird das Transceiver-Kabel zwischen PC und CAN-Bus quasi aufgeschnitten und durch die Funkstrecke ersetzt. Bemerkenswert dabei ist, dass man keine wesentlichen Einschränkungen in Bezug auf Genauigkeit und Messanforderungen hinnehmen muss (Bild 5). Bei der Umsetzung der Erweiterung wurden insbesondere den Anforderungen an das korrekte Zeitverhalten bei der Datenübertragung, geringe Latenzzeiten sowie einer zeitsynchronen Darstellung der Daten auf dem PC Rechnung getragen. Die CAN-Botschaften werden samt Zeitstempel über eine TCP/IP-Verbindung getunnelt, so dass die mit den Botschaften bereitgestellten Zeitstempel als Referenzzeit für CANoe und CANalyzer dienen können (Bild 6).

 WLAN-Lösung mit Vorteilen Die Lösung bietet einige wichtige Vorteile gegenüber den Möglichkeiten einer einfachen CAN/WLAN-Bridge. Für den Aufbau ist nur ein Brückenkopf erforderlich. Als Host genügt ein WLANfähiger Rechner, der über StandardBordmittel und WLAN die Verbindung hält (Bild 5). Der für die Umsetzung von CAN auf WLAN verantwortliche Tastkopf am Prüfling sendet die Botschaften in der streng chronologisch

Entwicklung + Test

richtigen ReihenfolErweiterungsge, indem er die urFunktionsbus II sprünglich auf dem Umsetzung TCP/IPBus festgehaltenen CAN CAN/Wireless- Wireless- Windows Protokoll nach CAN Gateway TCP/IP und Bereitstellung Kopplung Zeitstempel berückder Zeitbasis sichtigt, was über eine PC mit Betriebssystem Windows XP CAN-WLAN-CANBridge nicht möglich CAN 3 wäre. Während des Betriebs auf der Baustelle können die Elektronik-Entwickler automatische Tests errichtet. Das gevon Bomag ohne Leitungsverbindung schlossene, lärmgeschützte Gebäude zur Maschine messen, beobachten und erlaubt Dauertests zu beliebigen Tagesauswerten. und Nachtzeiten, ohne dass Anwohner Dieses und weitere Beispiele [1, 2] durch störende Betriebsgeräusche beaus dem Nutzfahrzeugbereich zeigen, einträchtigt werden. Dank WLAN-Verdass es auch außerhalb der Automobil- bindung sind die Elektronik-Entwickler elektronik der Kfz-Premiumklasse an- in der Lage, das Geschehen auf den respruchsvolle Herausforderungen gibt, levanten Bussystemen mit den genanndie nur durch komplexe Netzwerk-Clu- ten Tools fortlaufend zu beobachten. ster und leistungsfähige Entwicklungs- Das kann vom Schreibtisch im Büro aus und Analysetools in den Griff zu be- geschehen oder über das Internet sogar kommen sind. Die Vector-Werkzeuge von zuhause, was vor allem die Miterlauben Analysen und Simulationen arbeiter erfreut, die die Dauertests undirekt auf den höheren Schichten J1939 ter anderem auch am Wochenende beund CANopen. Multibus-Einsatz und treuen. sj ein gleichzeitiger Einsatz verschiedener Protokolle auf demselben Bus bereiten Literatur keine Probleme. Die Tools sorgen bei [1] Böck, T.; Betz, P.; Hörmann, M.; Felbinger, der Erfassung und Auswertung immer L.: CAN und J1939 unter extremen Einsatzbedingungen – Garantierte Funktion für das korrekte Timing auf derselben bei Kälte, Eis und Schnee. Elektronik Zeitbasis – auch bei drahtloser Kommuautomotive 2006, H. 5, nikation. S. 80ff. Aufgrund dieser Erfahrungen wurde [2] Felbinger, L.; Schaal, H.-W.: CAN und bei Bomag bereits das nächste WLANoffene Protokolle im Nutzfahrzeug – Auf Projekt ins Auge gefasst. Auf dem Firdem Weg zur weltweiten Vereinheitlimengelände in Boppard wurde kürzlich chung. Elektronik automotive 2005, H. eine große Testhalle für umfangreiche 5, S. 60ff.

CANalyzer/ CANoe

I Bild 6. Das erweiterte WLAN tunnelt die CAN-Botschaften samt Zeitstempel über eine TCP/ IP-Verbindung und ermöglicht so eine zeitkonforme Darstellung der Daten auf dem PC. (Quelle: Vector Informatik GmbH)

 Feldtests jetzt drahtlos möglich Schwierig für die Elektronik-Entwickler von Bomag war bisher eine zeitgleiche Analyse der Messdaten während der Feldtests, ohne selbst auf der Maschine mitfahren zu müssen. Sie konnten nur im Nachhinein die aufgezeichneten Daten untersuchen, nicht jedoch testbegleitend. Für solche Fälle gibt es von Vector jetzt eine WLAN-basierte Lösung: War bisher für die Arbeit mit den Tools ein physikalischer Kontakt www.elektroniknet.de

Dipl.-Ing. (BA) Timo Löw studierte Elektrotechnik an der Berufsakademie Mannheim im Rahmen einer dualen Ausbildung bei der Mercedes-Benz AG. Er ist Gruppenleiter im Bereich Software- und Systementwicklung bei der Bomag GmbH. [email protected]

www.elektroniknet.de

Dipl.-Ing. (FH) Andreas Nacke studierte Elektrotechnik an der achhochschule Oldenburg, Ostfriesland, Wilhelmshaven am Standort Emden. Er ist Entwicklungsingenieur im Bereich Software und Systeme bei der Bomag GmbH. [email protected]

Dipl-Ing. Hans-Werner Schaal studierte Nachrichtentechnik in der Universität Stuttgart und Electrical & Computer Engineering an der Oregon State University in Oregon, USA. Er ist Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking. [email protected]

Elektronik automotive 2.2008 1/35

Entwicklung + Test

llll Echtzeit-Kommunikation

Echtzeit-Kommunikation llll

Luftbrücke für Busdaten Synchrone Aufzeichnung drahtlos übermittelter Busdaten mehrerer Testfahrzeuge In der Vergangenheit beschränkte sich die Analyse der Fahrzeugkommunikation in der Regel auf ein einziges Fahrzeug. Diese Situation ändert sich bei der Entwicklung aktueller Fahrerassistenzsysteme zunehmend und wird spätestens mit Car­to­x­Techniken deutlich an Bedeutung gewinnen. In einem aktuellen Projekt zur Validierung eines ACC­Systems der Daimler AG gelang es erstmals, die Busdaten zweier Testfahrzeuge drahtlos zeitsynchron aufzuzeichnen und in Echtzeit am Bildschirm eines stationären Leitstandes darzustellen. Von Jürgen Luther und Hans-Werner Schaal

A

ls spezialisierte Bussysteme wie LIN, MOST und Flex­ Ray die bestehenden CAN­ Netzwerke ergänzten, entstand auch auf der Entwicklungsseite der Bedarf an Werkzeugen zur Handhabung von Multibus­Systemen. Einer der Schwer­ punkte liegt bis heute auf der zeitlich konsistenten Erfassung und Darstel­ lung von Botschaften der verschiede­ nen Systeme sowie der über Gateways vernetzten Buszweige im selben Ana­ lysewerkzeug. Elektronik automotive 7/8.2010 1/36

Aktuelle Entwicklungen im Bereich der Fahrerassistenzsysteme führen derzeit zu einer Zunahme des Funk­ tionsumfangs. Die Vielfalt der Mög­ lichkeiten reicht von einfachen Komfortfunktionen bis zu sicher­ heitsrelevanten Systemen wie dem Bremsassistent und der intelligenten Abstandsregelung ACC (Adaptive Cruise Control). Diese Systeme nut­ zen Sensorprinzipien wie Mikrowel­ len­Radar, Infrarot­Licht oder Ult­ raschall und arbeiten aus Sicht des

einzelnen Fahrzeugs derzeit noch autark. Dennoch sind Entwicklungs­ und Testabteilungen erstmals mit der Situation konfrontiert, dass mehrere Fahrzeuge aktiv am Geschehen betei­ ligt sind. Schon bei der Betrachtung eines einzigen Fahrzeugs sind die Herausforderungen für die Validierung vielfältig [1]. Das Betrachten jedes Fahrzeugs für sich allein reicht jedoch nicht mehr aus, man benötigt die CAN­ Bus­Informationen und Messwerte al­ ler beteiligten Fahrzeug. Allerdings ist die bisher selbst­ verständliche drahtgebundene phy­ sikalische Verbindung zum mobilen mitfahrenden Rechner naturgemäß auf ein Fahrzeug begrenzt. Für die kausal und zeitlich korrekte Darstellung einer fahrzeugübergreifenden Kommunika­ tion ist die Luftschnittstelle ein bei­ nahe unüberwindliches Hindernis. Wesentliche Voraussetzungen zur Verwirklichung fahrzeugübergreifen­ der Bus­datenerfassung fehlten bis­ lang.

ˆ Herausforderung: synchrone Messung über Luftschnittstelle Mit der Problematik der synchronen drahtlosen Messdatenerfassung beschäf­ www.elektroniknet.de

tigen sich auch die Messtechnikspezia­ listen im Hause der Daimler AG, bei­ spielsweise bei aufwändigen Feldtests zur Absicherung von Fahrerassistenz­ systemen. Um derart komplexe Systeme zur Marktreife zu führen, sind zahlreiche Versuche und Fahrtests ein unverzicht­ barer Bestandteil des Entwicklungspro­ zesses. Die Assistenzsysteme müssen ihre Zuverlässigkeit unter allen mög­ lichen Randbedingungen kontinuierlich unter Beweis stellen (Bild 1). Im Hinblick auf eine Effizienzstei­ gerung konkretisierte sich in einem aktuellen ACC­Projekt die Notwen­ digkeit der zeitsynchronen drahtlosen Aufzeichnung der CAN­Daten sowohl des zu testenden Systemfahrzeugs als auch des am Verkehrsgeschehen betei­ ligten Partnerfahrzeugs. Insbesondere die Positions­ und Geschwindigkeitsinformationen einer zeitsynchronen Aufzeichnung sind für die Bewertung und Dokumentation der Testfahrten von hohem Interesse, da sie im Leitstand am Rand des Testgeländes eine Visualisierung in Echtzeit erlauben. Zur Beurteilung und Optimierung der Regelalgorithmen sind möglichst genaue Kenntnisse von Differenzabständen, Ge­ schwindigkeiten und Querbeschleuni­ gungen notwendig. Wo waren die Fahr­ zeuge genau? Mit welcher Latenzzeit hat das Assistenzsystem reagiert? Und

l Bild 2. Für die zuverlässige Validierung der Fahrerassistenzsysteme übernehmen Fahrroboter alle notwendigen Funktionen wie Gas, Bremse oder Lenkung.

noch wichtiger: reagiert das System nur dann, wenn es das auch soll?

ˆ Fahrroboter für reproduzierbare Manöver Die Validierung der Assistenzsysteme bedingt einen hohen technischen Auf­ wand. Sekundenbruchteile entscheiden bei den Aktionen und Reaktionen der

l Bild 1. Typische Testszenarien mit Systemfahrzeug und Partnerfahrzeug, bei denen es auf genaue Datensynchronität ankommt: plötzliche Einscherer, z.B. für ACC-Vermessung (A); knappe Vorbeifahrt, dabei Vollbremsung, z.B. beim Bremsassistenten (B); knappe Vorbeifahrt bei querendem Verkehr als Referenztest mit höchstem Präzisionsanspruch (C). www.elektroniknet.de

Entwicklung + Test

Fahrzeuge über Erfolg oder Misser­ folg, Fahrmanöver müssen absolut reproduzierbar sein. Nicht nur aus Sicherheitsgründen setzt Daimler daher statt menschlicher Testfahrer Fahrrobo­ ter ein (Bild 2). Sie übernehmen alle notwendigen Fahrfunktionen wie Gas, Bremse oder Lenkung und bewältigen auch enge Vorbeifahrten und Beinahe­ Crashs präzise und emotionslos. Die eingesetzten Fahrroboter erlau­ ben es, Trajektorien nach differentiel­ lem GPS­Signal mit einer maximalen lateralen Abweichung von weniger als fünf Zentimetern und einer zeitlichen Abweichung im 100­Millisekunden­ Be­reich abzufahren. Damit ist es mög­ lich bei den ACC­Tests zwei Fahrzeu­ ge mit unterschiedlichen – teilweise erheblichen – Annäherungsgeschwin­ digkeiten auf vorgegebenen Pfaden mit einem extrem geringen seitlichen Abstand von nur zehn Zentimetern aneinander vorbeifahren zu lassen. Auch Ein­ und Ausschermanöver mit verschiedenen Geschwindigkeiten und Abständen werden so getestet. Bisher fehlte den Daimler­Entwicklern aber der Zeitbezug zwischen den verschie­ denen CAN­Bussen von System­ und Partnerfahrzeug. Eine gemeinsame Darstellung im Trace­Fenster war nicht möglich. Eine Zeitabweichung von nur fünf Millisekunden der beiden Fahr­ zeugdatensätze bedeutet bei einer Ge­ Elektronik automotive 7/8.2010 1/37

Entwicklung + Test

llll Echtzeit-Kommunikation

schwindigkeit von 20 m/s einen räum­ lichen Versatz von zehn Zentimetern, also der geforderten Genauigkeit der Fahrmanöver.

ˆ CAN over IP over WLAN Auf Grundlage des in der Automobilin­ dustrie weit verbreiteten Entwicklungs­ und Testwerkzeugs CANoe und der da­ für erhältlichen Option .IP hat Daimler gemeinsam mit der Vector Informatik GmbH eine Lösung zur drahtlosen und synchronen Busdatenerfassung meh­ rerer Fahrzeuge erarbeitet. Damit sind die Daimler­Mitarbeiter in der Lage, die CAN­Botschaften beider Fahrzeu­ ge auf einer gemeinsamen Zeitbasis zu erfassen, zu speichern und zu visuali­ sieren (Bild 3). CANoe.IP ist eine um ethernet­spezifische Funktionen erwei­ terte CANoe­Standardversion. Bereits letztere erlaubt eine effiziente Unter­ suchung mehrerer Fahrzeugbusse über Gateway­Grenzen hinweg. Hochgenau erfasste Informationen lassen sich wäh­ rend Messfahrten oder stationärer Tests sowohl in Echtzeit anzeigen als auch später offline analysieren.

bedingungen kann man mit CANoe unter anderem nun auch IP­Knoten und ­Gateways testen und simulieren sowie die Daten in Bildschirmfenstern grafisch anzeigen und analysieren. Auch im Automotive­Bereich hat IP seit einiger Zeit Einzug gehalten. So lassen sich mittlerweile sogar mehrere Steuergeräte unterschied­ licher Bussysteme via IP über ein Steuergerät flashen. IP begegnet Ent­ wicklern schließlich auch in WLAN­ Form, denn CAN­Botschaften lassen sich, verpackt in Ethernet­Pakete, über WLAN/Ethernet verschicken. Remote CAN ist überall dort interessant, wo man es mit schwer zugänglichen oder mobilen CAN­Bussystemen zu tun hat, beispielsweise zum Fernsteuern oder Fernüberwachen von Motorprüf­ ständen, HiL­Tests oder der drahtlosen CAN­Datenerfassung [2].

ˆ IEEE 1588 schaltet Uhren gleich

Im Fall der Daimler­ACC­Tests er­ gänzte Vector in enger Zusammenar­ beit mit den Messtechnikspezialisten von Daimler das Werkzeug CANoe. IP um die geforderten Funktionen. Dabei wählte man folgenden Lösungsansatz: Unter der theoretischen Vo­ raussetzung, dass in beiden Fahrzeugen exakt synchronisierte Uhren als Zeitrefe­ renzen zur Verfügung stehen, lassen sich sämtliche Datenpa­ kete zusammen mit hochgenauen Zeit­ stempeln verschicken, anhand derer man auf der Empfangsseite die Daten eindeutig l Bild 3. Zeitsynchrone Datenübertragung über WLAN an CANoe.IP chronologisch ein­ mit einer maximalen Abweichung von fünf Millisekunden. ordnet. In der Praxis funktioniert dies je­ Die IP­Programmvariante hingegen doch nicht ohne Zusatzmaßnahmen, kommt bei der Entwicklung, der Simu­ da synchronisierte Uhren wieder aus­ lation und dem Test von Embedded­ einanderdriften. Systemen im IP­Bereich zum Einsatz. Die Hauptanstrengungen konzen­ Anders als bei der Bürokommunika­ trierten sich demnach auf die Nach­ tion geht es bei Embedded­Systemen synchronisation der Uhren sowie auf um verteilte Regelkreise, die sich statt das Verpacken der Botschaften mit z.B. CAN oder LIN nun eines IP­Bus­ Originalzeitstempeln der Remote­ systems bedienen. Unter solchen Rand­ CAN­Busse in WLAN­Pakete. Für Elektronik automotive 7/8.2010 1/38

Echtzeit-Kommunikation llll

die Uhrensynchronisation kommt ein international etabliertes Verfahren zur Anwendung, das in der IEEE 1588 [3] standardisiert und für lokale Netzwer­ ke wie Ethernet konzipiert ist. Wäh­ rend eine als Master Clock definier­ te Referenzuhr die Slave Clocks mit Synchronisationsmeldungen beliefert, berechnet man anhand von Response­ Meldungen die Übertragungszeiten (Delay). Damit lassen sich im nächs­ ten Durchgang die Abweichung (Off­ set) korrigieren und der Gang regeln (Drift), d.h., der Oszillator kann be­ schleunigt oder verlangsamt werden. Mit fortschreitenden Iterationen kon­ vergiert die Synchronisation auf diese Weise. Durch das Verfahren einigt man sich quasi auf eine der beiden Zeiten als Referenz und bildet die Ereignisse des anderen Bussystems korrekt da­ rauf ab [4]. Dies funktioniert auch mit ungenauen Uhren und ist prinzipiell mit Schnittstellen­Hardware jedes be­ liebigen Herstellers möglich, sofern CANoe.IP oder auch CANalyzer.IP in aktueller Version verwendet werden.

ˆ Erweiterte WLAN-Reichweite Weiterhin galt es, das Problem der be­ grenzten WLAN­Reichweite zu lösen. Je nachdem, ob sich die Antenne in­ nerhalb oder außerhalb des Fahrzeugs befand, begrenzte der Einsatz handels­ üblicher WLAN­Antennen die Reich­ weite auf 100 bis 300 Meter. Dieser für das Testgelände zu geringe Wert führte zum Einsatz einer speziellen WLAN­ Antenne mit hohem Antennengewinn von 15 dBi, welche die Reichweite auf 1200 Meter erhöht. Diese Antennen mit einem Durchmesser von vier Zen­ timetern und einer Länge von 80 Zen­ timetern werden mit Magnetfüßen auf dem Autodach befestigt und signalisie­ ren gleichzeitig jedem Testfahrer, dass Roboterfahrzeuge im Einsatz sind. Dank des flexiblen Konzepts von CANoe sowie der nahtlosen Zusam­ menarbeit beider Unternehmen konn­ ten die Vector­Entwickler alle notwen­ digen Modifikationen und Anpassun­ gen umsetzen. Das Ergebnis übertrifft die ursprünglichen Erwartungen der Auftraggeber. Trotz kritischer Luft­ schnittstelle erreicht man bei der ma­ ximalen zeitlichen Abweichung Werte von unter fünf Millisekunden, was für www.elektroniknet.de

Entwicklung + Test

die meisten Anwendungen mehr als ausreichend ist. Über WLAN kann nun vom Leitstand am Rand der Test­ strecke der Busverkehr der koordiniert fahrenden Fahrzeuge beobachtet, be­ wertet, dokumentiert und sofort qua­ lifizierte Aussagen über den erfolgrei­ chen Versuchsablauf abgeben werden (Bild 4).

ˆ Vom intelligenten Fahrzeug zum Car-to-x-Teilnehmer Die Weiterentwicklung heutiger Assis­ tenzsysteme in Richtung Car­to­x­Tech­ nologien hat längst begonnen. Geht man davon aus, dass die Verkehrsdichte wei­ ter zunimmt, ist eine intelligente Fahr­ zeugkommunikation unverzichtbar, um den Verkehrsfluss zu regeln, Straßen besser auszulasten und die Verkehrs­ sicherheit zu erhöhen. Um künftig euro­ paweit eine Kommunikation zwischen Fahrzeugen über WLAN zu ermög­ lichen, arbeitet beispielsweise das „Car 2 Car Communication Consortium“ [5] bereits an einer Standardisierung. Bei Automobilherstellern und ­zu­ lieferern werden sich Fahrzeugtests zunehmend auf mehr als ein Fahrzeug ausweiten. Die Vielzahl künftiger Car­ to­x­Anwendungen und ­Testszenarien ist unüberschaubar groß. Vorausfahren­ de Fahrzeuge senden Warnungen über Gefahrensituationen an nachfolgende Fahrzeuge. Beim Kreuzungsassisten­ ten signalisiert ein eventuell verdecktes Fahrzeug seine Position, die Fahrtrich­ tung und die Geschwindigkeit wie in Bild 1 (C) dargestellt. Gegebenenfalls wird dies durch Infrastruktureinrich­ tungen (Road Site Units) unterstützt. Das bisher verwendete Test­Equip­ ment für die Datenerfassung in einem einzigen Fahrzeug stößt angesichts solcher Entwicklungsherausforde­ rungen endgültig an seine Grenzen. Gleichzeitig bekommen die hier ange­ sprochenen Themen für einen großen Entwicklerkreis zentrale Bedeutung. Typische Timing­Fragen sind künftig für mehrere Fahrzeuge zu beantwor­ ten, beispielsweise beim Blind­Spot­ Monitoring, wann auf dem Busssys­ tem des ausscherenden Fahrzeugs die Information angekommen ist, dass es nicht ausscheren darf. Entwickler müssen sich an den Ge­ danken gewöhnen, Daten über mehre­ www.elektroniknet.de

l Bild 4. CANoe.IP simuliert ein Verkehrsszenario am Beispiel einer empfangenen Schleuderwarnung.

re Fahrzeugdomänen hinweg auf einer einheitlichen Zeitbasis aufzuzeichnen und zu verarbeiten. Dies erfordert, dass man vielfach neue Wege einschlägt und insbesondere die Luftschnittstel­ le fest mit einkalkuliert. Die Rolle von Ethernet, WLAN und IP wird auch in der Automobilindustrie an Bedeutung zunehmen. Um auch den zukünftigen Car­to­x­Anforderungen gerecht zu werden, entwickelt Vector CANoe in Zusammenarbeit mit den Anwendern kontinuierlich weiter. Der nächste Schritt ist die Unterstützung des für die Etablierung von WLAN im Fahrzeug wichtigen Standards IEEE 802.11p. sj

Dipl.-Ing. Jürgen Luther studierte Physikalische Technik an der Fach­ hochschule Lübeck. Er ist wissenschaftlicher Mitarbeiter in der Forschung & Vorentwick­ lung bei der Daimler AG und für die Betreu­ ung und Weiterentwicklung der neuen Prüf­ methodik mit fahrerlosen Roboterfahrzeugen zuständig. [email protected]

Literatur + Links [1] Hurich, H.; Wolfgang, H., Luther, J., Schöner, H.-P.: Koordiniertes Automa­ tisiertes Fahren zum Entwickeln, Prüfen und Absichern von Assistenzsystemen. 10. Braunschweiger Symposium AAET 2009. [2] Löw, T.; Nacke, A.; Schaal, H.-W.: Für schweres Gerät – Drahtlose Anbindung von Entwicklungs­ und Analysewerk­ zeugen. Elektronik automotive. Heft 2.2008. S. 38ff. [3] Einführung in IEEE 1588. http://ieee1588.nist.gov [4] Wiebel, H.: Uhren mit IEEE 1588 synchro­ nisieren. Bulletin SEV/VSE 2004. H. 4. S. 35ff. [5] Car 2 Car Communication Consortium. www.car­to­car.org

Dipl.-Ing. Hans-Werner Schaal studierte Nachrichtentechnik an der Univer­ sität Stuttgart und Electrical & Computer Engineering an der Oregon State University in Oregon, USA. Er ist Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking. [email protected]

Elektronik automotive 7/8.2010 1/39

Bussysteme

IP-Kommunikation llll Bussysteme

llll IP-Kommunikation

Ethernet und IP im Kraftfahrzeug Neue Anforderungen an das Entwicklungswerkzeug durch den Ethernet- und IP-Einsatz Bis vor einigen Jahren herrschte die Meinung, Ethernet komme mit Ausnahme des Diagnosezugangs nie ins Serienfahrzeug. In Kürze nutzen kamerabasierte Fahrerassistenzsysteme als erste Anwendungen Ethernet als Systemnetzwerk. Fahrzeughersteller, Zulieferer und Hersteller von Entwicklungswerkzeugen werden mit neuen Herausforderungen konfrontiert, weil das Internet-Protokoll und Ethernet für das Fahrzeug eine neue Netzwerktechnologie darstellen. Dennoch lassen sich viele Aufgaben bereits lösen. Von Hans-Werner Schaal

N

ach dem Debüt des CAN-Busses in der Mercedes-S-Klasse im Jahr 1991 haben sich die Bussysteme LIN, MOST und FlexRay im Kraftfahrzeug etabliert. CAN kommt in aktuellen Pkw-Netzwerkarchitekturen nach wie vor in allen Domänen (von Powertrain bis Body) zum Einsatz. Der LIN-Bus ist prädestiniert für den einfachen und kostengünstigen Datenaustausch von unkritischen Signalen im Komfortbereich. Dort wo Bandbreiten und Echtzeitanforderungen an ihre Grenzen stoßen, wird CAN – wenn wirtschaftlich vertretbar – durch FlexRay oder MOST ersetzt. In aktuellen Fahrzeugen kommen oft alle genannten Bussysteme zum Einsatz – segmentiert und über Gateways vernetzt. Elektronik automotive 4.2012 1/40

ˆ Motivation für Ethernet In der Bürokommunikation, der Automatisierungstechnik mit dem ODVAStandard Ethernet/IP und ProfiNet sowie in der Luftfahrttechnik mit AFDX ist Ethernet schon seit langem Standard. Im Automobilbereich hatte sich Ethernet im Fahrzeug als Diagnosezugang bewährt. Weitere Einsatzbereiche wurden in den letzten Jahren in den automobilen Forschungs- und Entwicklungsabteilungen verstärkt diskutiert, denn die verfügbare, skalierbare Bandbreite und die Flexibilität sprachen stark dafür. Allerdings fehlte eine für das Kraftfahrzeug geeignete wirtschaftliche Verkabelungstechnologie.

Haupttreiber für den Ethernet-Einsatz im Fahrzeug sind aktuell kamerabasierte Fahrerassistenzsysteme. Bei Kameraanwendungen im Fahrzeug kam bisher die Low-Voltage-Differential-Signaling-Technologie (LVDS) zum Einsatz. Die dort in der Regel verwendeten geschirmten Kabel sorgen zwar für die elektromagnetische Verträglichkeit, sind aber für Branchenverhältnisse teuer und in der Verlegung im Kraftfahrzeug wenig praktikabel. Mittlerweile steht ein Physical Layer zur Verfügung, der 100 Mbit/s auf einem CAN-ähnlichen, verdrillten Zweidraht-Kabel (Unshielded Twisted Pair) im Vollduplex überträgt und sich nach Meinung verschiedener Veröffentlichungen für den Einsatz im Kraftfahrzeug geeignet ist [1, 2, 3].

ˆ Anforderungen an ein IP-Entwicklungswerkzeug Für das Entwicklungswerkzeug ergeben sich zunächst die aus bisherigen Bussystemen bekannten Anforderungen. Erforderlich ist zunächst eine detaillierte Protokollanalyse mit Stimulationsmöglichkeit bis hin zu skriptbasiertem Testen mit automatischer Erstellung von Testprotokollen. Auch erwartet der Anwender, dass die auf dem Markt bewährte Multi-BusFähigkeit auf Ethernet und IP ausgeweitet wird, um Abhängigkeiten zwi-

schen Ereignissen auf verschiedenen Bussystemen optimal untersuchen zu können. Gegenwärtig interessieren solche Zusammenhänge beispielsweise zwischen LIN und CAN, zukünftig zwischen CAN und IP. Der Anwender benötigt bei der Protokollanalyse wie bisher einen einfachen, symbolischen Zugriff auf alle relevanten Applikationssignale sowie die Möglichkeit, diese beliebig logisch und grafisch weiterzuverarbeiten. Hinzu kommen neue Anforderungen, die sich einerseits aus der Busphysik und andererseits aus der Protokollvielfalt von IP ergeben. Anhand des aktuellen Kamerabeispiels und vier weiteren Einsatzbereichen von IP und Ethernet im Kfz wird nachfolgend dargestellt, wie sich diese Messaufgaben aus Sicht der Systemverantwortlichen in der Serienentwicklung stellen und welche besonderen Anforderungen sich daraus für das Entwicklungswerkzeug ergeben.

lassen sich alle KaControl meras direkt mit eiDiagnose- Audio/Video Smart Dienst- Konfiguration Auflösung der Adresse, Kommuni- erkennung der zugang Zeitsync. Grid Signallisierung etc. kation Adressen nem Switch verbinISO 15118 7 Anwendung DoIP SOME/IP Bonjour DHCPv6 ICMPv6 NDP den. Wie bei den bisPart 1 (2) DHCP ICMP ARP her im Kraftfahrzeug 6 Darstellung AVB IEEE verwendeten Bussys1722 5 Sitzung ISO 802.1AS 15118 temen muss der DaPart 2 TCP/IP TCP/IP UDP 4 Transport UDP UDP tenverkehr an verIPv4/ 3 Vermittlung IPv4/IPv6 IPv6 schiedenen Punkten IEEE Ethernet MAC + IEEE Ethernet MAC + VLAN (802.1Q) 2 Sicherung ISO VLAN (802.1Q) 15118 im Netzwerk beob100BroadRAutomotive Ethernet Physical Layer Part 3 1 Übertragung Base-Tx Reach (z.B. BroadR-Reach) achtet, analysiert und zeitsynchron verglichen werden. Die l Bild 2. IP-Protokolle automobiler Anwendungen im OSI-ReferenzMess-Hardware muss modell aufgetragen (Spalten links) inklusive Verwaltungsfunktiodaher zunächst die nen (Spalten rechts): Sowohl neue Protokolle (rot) als auch aus der Bürokommunikation bekannte (blau) werden verwendet. aktuelle Busphysik unterstützen, beispielsweise BroadR-Reach, aber auch kolle in den Spalten Audio/Video und für zukünftige Physical Layer offen Control-Kommunikation. Hinzu komsein. Wünschenswert ist ein mehrka- men Protokolle zur Bandbreitenresernaliger Abgriff über T-Stücke, der das vierung und weitere Netzwerk-MaSystemnetzwerk beim Monitoring nagement-Protokolle, siehe auch die möglichst wenig beeinflusst. Zur Va- vier rechten Spalten in Bild 2. Diese lidierung der Systemfunktion sollte und weitere in der Grafik aufgeführte das T-Stück auch Fehler einfügen kön- Protokolle kommen aufgrund der im nen. Über die Analyse hinausgehend Folgenden betrachteten Anwendungsˆ Ethernet als Systemnetzwerk ist auch die Stimulation oder gar die fälle hinzu. für die Kamera nutzen Simulation ganzer Teile des Netzwerks erforderlich (Restbussimulation). Das Diagnosezugang im Blickpunkt Ein kamerabasiertes Fahrerassistenz- bringt einige Herausforderungen an Über die Technologie Diagnostics over system wird bei BMW die erste Seri- die Mess-Hardware mit sich. Eine Kameraapplikation stellt hohe IP (DoIP) ist es möglich, alle angeenanwendung im Kraftfahrzeug sein, die IP und Ethernet als Systemnetz- Anforderungen an Zeitsynchronisati- schlossenen Steuergeräte verschiedewerk im Fahrzeug einsetzt [1]. OEMs on und Quality of Service (QoS) [4]. ner Bussysteme zentral über einen und Zulieferer nutzen hierfür den Phy- Diese sollen durch Protokollerweite- leistungsfähigen Ethernet-Zugang zu sical Layer BroadR-Reach, um gegen- rungen des Audio-Video-Bridging- flashen (Bild 3). Die Systementwicküber der bisher gängigen LVDS-Tech- Standards (AVB) gelöst werden [7]. lung des OEM muss diesen Dienst nologie Gewicht und Kosten einzuspa- Nachdem sich die Hersteller hinsicht- valide absichern. Weil ein Steuergerät ren [1, 4, 5]. BroadR-Reach wird von lich der Bit-Übertragungsschicht (OSI- als Gateway eingesetzt wird, besteht Layer 1) praktisch einig sind, wird aus großes Interesse, die Übertragung der weiteren Anbietern lizensiert [6]. Ein Kamerasystemnetzwerk ist ex- Kosten- und Testgründen auch eine Diagnosedaten nicht nur auf Seite der emplarisch mit möglichen Messpunk- Vereinheitlichung der höheren Schich- angeschlossenen Bussysteme zu anaten in Bild 1 dargestellt. Alternativ ten angestrebt. lysieren, sondern auch auf IP-Seite. Allein aufgrund Relevant sind die Protokolle ISO der bei der Kamera- 13400 und IPv4, gegebenenfalls auch applikation verwen- IPv6. Netzwerktester deten Protokolle gibt es neue Anforderun- Intelligentes Laden gen an die Mess-SoftEthernet ware, damit beliebige Das intelligente Laden, auch SmartSignale aus der Pay- Charging genannt, geht weit über das Node1 Image load der verschiede- einfache Anstecken an die HaushaltsNode3 T Switch1 T Node2 Processor nen und durchaus steckdose hinaus. Das zu ladende Node4 Switch2 komplexen Protokolle Elektrofahrzeug ist über eine LadestaNode5 Embedded Ethernet System applikationsgerecht tion an das Stromnetz (Grid) angepräsentiert und mani- schlossen. Ladevorgänge starten nicht l Bild 1. Zuverlässige Analyse von kamerabasierten Fahrerassispuliert werden kön- einfach, sondern melden den Bedarf tenzsystemen erfordert das Abgreifen des Datenverkehrs an mehnen. Bild 2 (nach [7] erst einmal an. Durch die Verzögerung reren Stellen des Ethernet-Netzwerks, idealerweise über „T-Stüund Vector) zeigt die einzelner Ladevorgänge um Bruchteicke“ mit geringstmöglichem Zeitversatz und mit Darstellung auf für AVB zum Einsatz le von Minuten lassen sich Überlasgemeinsamer Zeitbasis. kommenden Proto- tungen des Grids vermeiden. Weiter Elektronik automotive 4.2012 1/41

Bussysteme

IP-Kommunikation llll Bussysteme

llll IP-Kommunikation

CAN ECU Diagnose Gateway

LIN ECU MOST ECU FlexRay ECU

se Protokolle unterstützen (Spalte Smart Grid in Bild 2).

Kalibrieren, Debuggen und Flashen

Ethernet mit dem Mess- und Kalibrierprotokoll XCP wird Ethernet CAN Diagnosetester in der Entwicklung LIN für das Kalibrieren, MOST FlexRay Debuggen und FlaNetzwerktester shen der Steuergeräte schon mehrere Jahre l Bild 3. Bei der Validierung von DoIP an einem Gateway ist die Darstellung des Datengenutzt. In der Serie verkehrs sowohl auf der DoIP-Seite (links des Gateways) als auch auf allen angesteht aus Kostengrünschlossenen Bussystemen (rechts des Gateways) wichtig. Idealerweise werden alle den der Ethernet-ZuBotschaften aller Netzwerke auf einer gemeinsamen Zeitbasis abgetragen. gang gar nicht mehr zur Verfügung. Deslassen sich angeschlossene Fahrzeuge halb wird derzeit über das vorliegende als Speicher nutzen; die Abrechnung Arbeitsprotokoll, beispielsweise CCP mit dem Stromversorger kann automa- oder XCP on CAN, kalibriert und retisiert erfolgen. programmiert. Wenn aber in naher Das ermöglicht die Kommunikation Zukunft Ethernet ins Fahrzeug einzwischen Fahrzeug und Ladestation zieht, wäre das Messen und Kalibrieüber Ethernet auf IP-basierten Proto- ren über XCP on Ethernet aufgrund kollen, deren Standardisierung in der der deutlich höheren Messdatenrate Norm ISO 15118 festgelegt ist. Die La- auch in der Serie attraktiv. destation kommuniziert dabei mit dem Grid und dem Fahrzeug. Für den Sys- ˆ WLAN und Car-2-X temverantwortlichen beim Fahrzeughersteller ist die Kommunikation des Car-2-X bezeichnet die externe KomPkw mit der Ladestation wichtig. Um munikation zwischen Fahrzeugen und den Ladeprozess sicherzustellen, ist Infrastruktur. Die Anwendungen reieine detaillierte Analyse und Validie- chen von Komfortfunktionen über rung der Protokolle unumgänglich. Das Verkehrsfluss-Optimierung bis hin Entwicklungswerkzeug muss auch die- zur Erhöhung der Verkehrssicherheit durch Fahrerassistenzsysteme. Die Technologie befindet sich bereits in der Vorserienentwicklung und die Standardisierung ist weit fortgeschritten. Sie ist IP-basiert; als Physical Layer wird der Standard IEEE 802.11p genutzt. Das messtechnische Interesse bei Car-2-X-A nwendungen dehnt sich aus Sicht der Systemverantwor tlichen über die Grenze des eigenen l Bild 4. CANoe.IP unterstützt die Entwicklung, Simulation und Test von Embedded-SysteFahrzeugs hinweg men, die über IP oder Ethernet kommunizieren. auf eine Anzahl von DoIP/Ethernet

Switch/„T”

Elektronik automotive 4.2012 1/42

Fahrzeugen und Roadside-Units (RSUs) im Nahbereich aus. Das zu evaluierende Steuergerät kommuniziert nicht nur mit den an Bord befindlichen Bussystemen, sondern auch über die Luftschnittstelle mit anderen Verkehrsteilnehmern. Das Entwicklungswerkzeug muss daher auch diese IP-basierten Standards unterstützen. Daneben ergeben sich weitere Anforderungen im Hochfrequenzbereich, zum Beispiel WLAN im 5-GHzBand.

ˆ Protokollvielfalt für Anwendungen und Messwerkzeug In Bild 2 sind exemplarisch die verschiedenen, von der Anwendung abhängigen Übertragungsschichten und Protokolle zusammengefasst, die das Entwicklungswerkzeug allein aufgrund der bisher behandelten Fälle unterstützen muss. Einige der im Bereich der Bürokommunikation verwendeten Protokolle finden sich hier wieder. Viele davon sind verzichtbar, andere kommen hinzu. Die blau gekennzeichneten Protokolle können aus der Bürokommunikation übernommen werden. Jene, die aufgrund der neuen, automobilen Anwendung hinzukommen, sind rot dargestellt. Das Messsystem hat die Aufgabe, alle relevanten Protokolle aufzulösen und alle Netzwerkereignisse in einen kausalen Bezug zu stellen (korrekte Reihenfolge). Dabei ist es wünschenswert, alle Busdomänen auf einer gemeinsamen Zeitbasis mit ausreichender Genauigkeit darstellen zu können.

ˆ Absicherung von IP-Serienprojekten Wie die Betrachtung der obigen Anwendungsfälle zeigt, machen es Kausalitäts- oder gar Zeitbetrachtungen über mehrere Bussysteme hinweg schwierig bis unmöglich, StandardEthernet-Tools aus der Bürokommunikation für Multi-Bus-Anwendungen im Fahrzeug nutzen. Ethernet im Bürobereich ist eben nicht gleich Ethernet im Automotive-Bereich. Dasselbe gilt für die jeweils eingesetzten Internetprotokolle. Diese unterscheiden sich je nach Anwendung in Art und Komplexität genauso deutlich wie die Anforderungen an den Physical Layer.

Um die Signalstruktur der Protokolle im Entwicklungswerkzeug darzustellen und den Embedded Code zu generieren, ist ein geeignetes Engineering-Format wichtig. Hierfür haben sich bei CAN das DBC-Format und bei FlexRay FIBEX durchgesetzt. Für das neue Ethernet- und IP-basierte Systemnetzwerk reicht das DBC-Format als Datenbankformat nicht mehr aus. Es wäre aus Sicht der Werkzeugzulieferer hilfreich, wenn sich die OEMs auf ein gemeinsames Engineering-Format einigen könnten. Geeignete Kandidaten wären FIBEX 4.0 und die AUTOSAR System Description. Erfahrungen aus anderen Industriebereichen zeigen, dass danach von Werkzeugherstellern zeitnah geeignete Entwicklungswerkzeuge für Analyse und Code-Generierung zur Verfügung gestellt werden.

ˆ Zukünftige Fahrzeugnetzwerke CAN wird noch deutlich länger als zehn Jahre im Pkw zu finden sein, alle anderen hier besprochenen Bussysteme mindestens zehn Jahre. Dennoch legen die Anwendungen durch steigende Anforderungen in Hinsicht auf Bandbreite, Flexibilität und Wirtschaftlichkeit den Einsatz von IP und Ethernet immer stärker nahe. In den nächsten Jahren werden wie bisher mehrere über Gateways vernetzte Bussysteme vorzufinden sein – Ethernet und IP kommen einfach noch dazu. Wie bei der Kameraapplikation wird es auch bei zukünftigen IP-Anwendungen neue Herausforderungen auf allen Protokollebenen geben, die aber mit geeigneten Entwicklungswerkzeugen zu lösen sind.

ˆ Ausblick auf IP-Entwicklungswerkzeuge Für den Automotive-Bereich empfehlen sich nach wie vor dafür konzipierte Entwicklungswerkzeuge. Diese müssen einerseits alle Protokollebenen unterstützen, sich aber andererseits auch in die branchentypische Werkzeuglandschaft einpassen. Für die Absicherung von Serienprojekten beim OEM sind insbesondere die Zulieferer darauf angewiesen, dass geeignete Entwicklungswerkzeuge zur Verfügung stehen. Das schließt den Support

und idealerweise CANoe.IP auch die UnterstütFall 1 zung bei der Einfüh100/1.000 BT GBE rung durch den Werk100/1.000 BT Fall 2 zeughersteller mit VN56xx USB BroadR-Reach ein. Windows PC 100/1.000 BT Fall 3 Basierend auf dem VN89xx VN56xx USB BroadR-Reach bewährten Simulations- und Testwerkzeug CANoe von l Bild 5. CANoe.IP mit skalierbaren Hardware-Interfaces und optionaler Echtzeitunterstützung (Bilder: Vector Informatik) Vector Informatik deckt die Option IP Vehicle-internal Communications. 1st die genannten Anforderungen an ein Ethernet & IP @ Automotive Technology Ethernet-Entwicklungswerkzeug beDay, BMW, München, 2011. reits ab. Durch die vielfältigen Ether[4] Nöbauer, J., Continental AG: Migration net-spezifischen Funktionen und die from MOST and FlexRay Based Networks Multi-Bus-Fähigkeit kann CANoe.IP to Ethernet by Maintaining QoS. 1st helfen, die Entwicklungszeit zu reduEthernet & IP @ Automotive Technology zieren, wodurch sich wertvolle ResDay, BMW, München, 2011. sourcen zielführend applikationsseitig [5] Powell, S. R., Broadcom Corporation: Ethernet Physical Layer Alternatives for einsetzen lassen (Bild 4). CANoe.IP Automotive Applications. 1st Ethernet & für die automobile NetzwerkentwickIP @ Automotive Technology Day, BMW, lung weist denselben EntwicklungsMünchen, 2011. komfort auf, wie es für die etablierten [6] NXP Develops Automotive Ethernet Bussysteme CAN, LIN, MOST und Transceivers for In-Vehicle Networks. November 09, 2011, www.nxp.com/ FlexRay Standard ist. Dabei ist das news/press-releases/2011/11/nxp-deveEntwicklungswerkzeug in hohem Malops-automotive-ethernet-transceiversße skalierbar und verfügt prinzipiell for-in-vehicle-networks.html. über drei Interface-Möglichkeiten [7] Völker, L., BMW AG: One for all, (Bild 5). Im einfachsten Fall 1 arbeitet Interoperability from AUTOSAR to es mit beliebigen auf einem WindowsGenivi. 1st Ethernet & IP @ Automotive Rechner vorhandenen Netzwerkkarten Technology Day, BMW, München, 2011. zusammen. Kommt BroadR-Reach zum Einsatz oder sollen auch Fehler eingefügt werden, kann als HardwareInterface zukünftig die VN56xx-Familie genutzt werden (Fall 2). Dadurch erhöht sich die Zeitsynchronität zwischen den IP-Kanälen und zu anderen Bussystemen erheblich. Ist Echtzeitverhalten gefordert, dann kann in Zukunft CANoe.IP in Verbindung mit der Echtzeit-Hardware VN8900 betrieben werden, die mit der InterfaceHardware VN56xx nahtlos zusammenarbeitet (Fall 3). eck

Dipl.-Ing. Hans-Werner Schaal

Literatur + Links [1] Bogenberger, R., BMW AG: IP & Ethernet as potential mainstream automotive technologies. Product Day Hanser Automotive. Fellbach, 2011. [2] Neff, A., Matheeus, K, et al.: Ethernet & IP als applikativer Fahrzeugbus am Einsatzszenario kamerabasierter Fahrerassistenzsysteme. VDI-Berichte 2132, Elektronik im Kraftfahrzeug. Baden-Baden, 2011. S. 491 – 495. [3] Streichert, T., Daimler AG: Short and Longterm Perspective of Ethernet for

studierte Nachrichtentechnik an der Universität Stuttgart und Electrical & Computer Engineering an der Oregon State University in Oregon, USA. Er ist Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking. Zuvor war er Entwicklungsingenieur, Projektleiter und Produktmanager in verschiedenen Branchen im Bereich Testwerkzeuge für mehrere Netzwerk-Technologien. [email protected]

Elektronik automotive 4.2012 1/43

10

l

AUTOMOTIVE

3-4. 2 0 13

l

ENGINEERING TOOLS

www.hanser-automotive.de

ENGINEERING TOOLS

l

AUTOMOTIVE

3-4. 2 0 13

l 11

FLEXIBLE INTERFACES UND SOFTWAREWERKZEUGE FÜR DIE STEUERGERÄTEENTWICKLUNG

Bild 1: Neben den aus der Bürokommunikation bekannten Protokollen wie UDP, TCP und IP kommen im automobilen Einsatz auch speziell hierfür optimierte Protokolle zum Einsatz. Diese sind in der ISO CD 17215-1 beschrieben. © automotive

Kostenvorteile. Weiterhin bietet es die Chance, den bewährten automobilen Entwicklungsprozess mit Vorgehensweisen aus der IT-Welt anzureichern.

Neue Werkzeuge für Automotive Ethernet S c h o n i n d i e s e m Ja h r ko m m t i n d e n e rs t e n S e r i e n fa h r z e u g e n E t h e r n e t a l s S y s t e m n e t z we rk z u m E i n s at z . F ü r d i e I n t e g rat i o n we rd e n n u n d r i n g e n d E n t w i ck l u n g s - u n d Te s t we rk z e u g e b e n ö t i g t , m i t d e n e n m a n b e s t e h e n d e B u s s y s t e m e w i e C A N , L I N , F l ex R ay u n d M O S T z u s a m m e n m i t E t h e r n e t N e t z we rke n a n a l y s i e re n u n d t e s t e n k a n n . We l c h e A n fo rd e r u n g e n a n d i e s e

A

ls nächster Schritt in der Fahrzeug-Architektur steht die Integration von Ethernet mit den in der Automobilbranche etablierten Technologien CAN, FlexRay, LIN und MOST an. Für diese gibt es funktionierende Entwicklungswerkzeuge, mit denen Entwickler auch heterogene Netzwerke einfach analysieren. Auf der Ethernet-Seite hingegen gibt es zwar brauchbare Standardwerkzeuge aus der Bürokommunikation. Diese unterstützen aber nicht die speziellen Physical Layer und IP-Protokolle der Automobilwelt. Daher werden hierfür neue Entwicklungs- und Testwerkzeuge benötigt.

1/44

Es ist bereits Stand der Technik, im Kraftfahrzeug Kamerabilder mit 100 Mbit/s über eine kostengünstige, ungeschirmte Zweidraht-Leitung zu übertragen. Diese Technologie heißt BroadR-Reach und wird vom Konsortium OPEN Alliance SIG standardisiert [1]. Im nächsten Schritt wird Ethernet als Netzwerk bei Infotainment und bei Fahrerassistenzsystemen schon 2015 zum Einsatz kommen. Manche OEMs sehen Ethernet bereits ab 2018 als BackboneTechnologie [2]. Wie bereits mehrfach in Fachbeiträgen beschrieben [3, 4], bringt Ethernet im automobilen Einsatz insbesondere in der Kombination mit ausgewählten Internetprotokollen (Bild 1, [5]) Flexibilität, Skalierbarkeit und

Bilder: Vector

We rk z e u g e g e s t e l l t we rd e n , z e i g t d i e s e r B e i t ra g .

Automotive Ethernet-Test-Lösung Ethernet im Kraftfahrzeug erfordert allerdings ein Umdenken bei Entwicklern und Testingenieuren. Erstens wird künftig eine klare Domänenarchitektur angestrebt (Bild 2). Darin ist der Backbone nicht mehr als ein Bussystem, sondern als geswitchtes Netzwerk mit mehreren Full-Duplex Verbindungen realisiert. Um damit echtzeitkritische Anwendungen zu realisieren, sind Synchronisierungstechniken auf höheren Protokollschichten oberhalb der Bitübertragungsschicht (Physical Layer) erforderlich, zum Beispiel AVB (Audio Video Bridging, Bild 1). Ebenso steigen mit der neuen Architektur die Anforderungen an die Analyse: Möchte der Entwickler den gesamten Datenverkehr auf dem Backbone gleichzeitig analysieren, muss der Zugriff auf alle Strecken synchronisiert werden (Bild 2, a, b, c, d). Zweitens müssen sich die Entwickler mit neuen, geeigneten Filterstrategien auseinandersetzen, um die enormen Datenmengen zu verarbeiten. Das wird sich noch verschärfen, da Übertragungsraten im Gigabit-Bereich bereits auf der Wunschliste der OEMs stehen. Ein hierfür geeigneter Physical Layer ist mit RTPGE (Reduced Twisted Pair Gigabit Ethernet) bereits in der Entwicklung. Anders als bei einem Bussystem müssen besondere Maßnahmen ergriffen werden, um den Einfluss einer Messung auf das System zu vermeiden. Hier sind einerseits die Entwickler gefordert, die Testbarkeit schon im Systemdesign zu berücksichtigen (Design-to-Test). Andererseits muss

der Werkzeughersteller den Einfluss des Interfaces minimieren. Im Folgenden werden verschiedene Messaufbauten für Analyse und Testzwecke vorgestellt, unerwünschte Einflüsse beleuchtet, und es wird gezeigt, wie diese Einflüsse minimiert werden können. Grenzen bisheriger Lösungen Ein naheliegender Weg zur Analyse eines Ethernet-Netzwerkes ist das Verwenden eines zusätzlichen Ports (Monitorport) an den eingesetzten Switches im System (Mirroring). An diesen Monitorport werden alle vom Switch empfangenen Pakete weitergeleitet. Dadurch wird zwar der Zugriff auf die ankommenden Datenpakete realisiert, jedoch stehen diese Datenpakete in keinerlei zeitlichem Bezug zueinander – es gibt keine Zeitstempel. Außerdem werden oftmals nur gültige Pakete an den Monitorport weitergeleitet, wodurch eine Fehleranalyse schwer fällt. Des Weiteren wird aus Kostengründen im Seriensy-stem kein zusätzlicher Monitorport am Switch für das Mirroring freigehalten [4]. Steht also kein zusätzlicher Port am vorhandenen Switch zur Verfügung, so kann ein zusätzlicher Switch in eine bestehende Verbindung eingefügt werden. Dieser zusätzliche Hop ist jedoch nicht transparent und verursacht eine Verzögerung der gesamten Übertragungsstrecke. Bei Netzwerken, die durch das AVB-Protokoll synchronisiert werden, stört diese dynamische Verzögerung unter Umständen die Zeitsynchronisation. Für diesen Messaufbau kann man prinzipiell auf gängige Tools und Switches aus dem IT-Bereich zurückgreifen. Bei den in der Automobilbranche üblichen BroadR-Reach-Netz1/45

12

l

AUTOMOTIVE

3-4. 2 0 13

l

ENGINEERING TOOLS

www.hanser-automotive.de

ENGINEERING TOOLS

Methode des transparenten Monitorings ist der Einsatz eines Switches mit AVB-Zeitsynchronisationsunterstützung. Die bei der Weitergabe der Pakete auftretende Latenzzeit wird dann über das AVB-Protokoll kompensiert. Unabhängig davon welche Methode gewählt wird, sind für eine genaue Analyse der Paketdaten genaue Zeitstempel notwendig, die möglichst nahe am Physical Layer genommen werden. Diese Zeitstempel müssen mit anderen Interfaces synchronisiert werden, da oftmals mehr als nur eine Ethernet-Strecke im Fokus der Netzwerkanalyse steht (Bild 2). Ein weiterer wichtiger Punkt ist das transparente Verhalten eines inaktiven Interfaces. Wird die Interface-Hardware beispielsweise für eine Messfahrt im Fahrzeug verbaut, muss das Interface in der Lage sein, auch ohne aktive Messapplikation selbständig einen vorkonfigurierten Standalone Mode einzunehmen. Andernfalls bleiben bestimmte Ethernet-Strecken während der Fahrt unterbrochen.

Bild 2: Mögliche Domänenarchitektur zukünftiger IP-Netzwerke im Kraftfahrzeug. Um alle Ethernet-Pakete analysieren zu können, muss die Analyse-Software auf alle Ethernet-Strecken synchronisiert zugreifen. © automotive

werken ist aber eine Medienkonvertierung auf StandardEthernet (IEEE 802.3) notwendig. Außerdem sind diese Werkzeuge aus Sicht der automobilen Netzwerkentwicklung meist Insellösungen ohne Bezug zu den nach wie vor wichtigen und gebräuchlichen Bussystemen. Transparente Ethernet-Analyse Anstatt einen klassischen Switch als Interface zu verwenden, ist es wünschenswert, das Netzwerk mit einer mög-

lichst transparenten Methode zu überwachen. Hierbei steht im Vordergrund, das System möglichst nicht durch zusätzliche Latenzzeit oder das Ausfiltern fehlerhafter Pakete zu beeinflussen. Dies kann durch einen sogenannten TAP (Test Access Point) erreicht werden (Bild 3), der rein passiv auf dem Physical Layer die Daten abgreift und weiterleitet (Pfad 1 in Bild 4). Hierbei ist die Latenzzeit nicht nur sehr kurz, sondern auch konstant, was vor allem bei der Analyse von AVB-Systemen von Vorteil ist. Eine weitere

Bild 3: Mögliche Verdrahtung von Ethernet-Interfaces für Analyse oder Restbussimulation. Hierbei ist auch die Synchronität zu bekannten automobilen Bussystemen erforderlich. © automotive

1/46

TAP mit Stimulation Neben der reinen Datenanalyse muss das Netzwerk oft durch gezieltes Versenden von Paketen getestet werden.

l

AUTOMOTIVE

3-4. 2 0 13

l 13

Dabei soll – wie auch bei der reinen Überwachung – die Verbindung zweier Knoten möglichst nicht beeinflusst werden. Das Senden dieser zusätzlichen Pakete kann jedoch nicht auf dem Physical Layer (OSI-Schicht 1) erfolgen, da eine zusätzliche Flusskontrolle notwendig wird, die erst ab der Schicht 2 verfügbar ist. Auch hier entstehen dynamische Latenzzeiten, die gegebenenfalls durch eine Protokollunterstützung, wie zum Beispiel AVB, direkt auf dem Interface kompensiert werden können. Eine Anwendung ist das zusätzliche Senden fehlerhafter Daten zu Testzwecken, während die normale Kommunikation beider Knoten läuft (Pfad 3 in Bild 4). Diese Daten werden entweder direkt von einer Testapplikation, beispielsweise von Vector CANoe.IP, bereitgestellt oder über einen Paketgenerator, der direkt auf dem Interface eine definierte Buslast erzeugt (Pfad 2 in Bild 4). Restbussimulation Gerade beim Entwickeln einzelner Steuergeräte ist die Restbussimulation [6] eine flexible Möglichkeit, um beliebige Szenarien zu testen, bevor Steuergeräte in ein reales Netzwerk integriert werden. Dafür ist erstens eine Hardware notwendig, die einen uneingeschränkten und leistungsfähigen Netzwerkzugriff erlaubt. Zweitens muss die Applikation aufgezeichnete oder selbst generierte Daten an die Hardware übergeben können (Pfad 4 in Bild 4). Und drittens muss die Kombination aus Hard- und Software Pakete empfangen, verfälschen und die verfälschten Pakete senden können. Damit wird das Verhalten der Steuergeräte bei konkreten Fehlerfällen, wie zum Beispiel Protokollfehlern, getestet.

Bild 4: Das Ethernet/CAN-Interface VN5610 nimmt in Verbindung mit CANoe.IP/ CANalyzer.IP passiv und aktiv an der Kommunikation in Ethernet-Netzwerken teil. Durch eine flexible Konfiguration werden verschiedene Messaufbauten für Analyseund Testzwecke unterstützt.

© automotive

Wichtige Eigenschaften einer flexiblen Interface-/ Software-Kombination Die genannten Messaufbauten zeigen, dass die Analyse von Ethernet-Netzwerken unterschiedliche Anforderungen an die Hard- und Software stellt. Um InterfaceWechsel bei den verschiedenen Messaufbauten zu vermeiden, muss das Interface flexibel als TAP, Konverter oder als Switch mit Zusatzfunktionalität einsetzbar sein. Dabei sind folgende Eigenschaften wünschenswert: 1/47

14

■

■

■

■

■

■

■

l

AUTOMOTIVE

3-4. 2 0 13

l

ENGINEERING TOOLS

Im einfachsten Fall, beim Einsatz des Interfaces als TAP, dürfen durch den TAP selbst nur minimale und genau spezifizierbare Latenzzeiten verursacht werden. Das Interface muss zwischen allen gängigen Medien wie beispielsweise BroadR-Reach, Fast Ethernet, Gigabit Ethernet und zukünftig auch RTPGE konvertieren können. Damit entfallen die bisher verwendeten externen Medienkonverter. Für Testfahrten muss das Interface im Fahrzeug verbaubar sein und darf im ungenutzten Fall das Netzwerk nicht unterbrechen (Standalone Mode). Paketgeneratoren auf Soft- oder Hardware-Ebene sind wichtig, da der automobile Entwicklungsprozess neben der Analyse auch kontrollierte Stimulation erfordert. In Verbindung mit der Simulationssoftware muss das Hardware-Interface für einen oder sogar mehrere virtuelle Netzwerkknoten den realen Medienzugriff ermöglichen (Restbussimulation). Das Analyse- und Simulationswerkzeug muss auf allen interessierenden OSI-Schichten und über alle Protokollebenen hinweg Daten analysieren und manipulieren können. Zur Unterstützung von heterogenen Netzwerken muss das Interface mit allen gebräuchlichen Bussystemen synchronisierbar sein.

Der Einsatz von leistungsfähigen Analysewerkzeugen aus der Bürokommunikation in Verbindung mit externen Medienkonvertern ist also oft zu kurz gegriffen. Die genannten Anforderungen sind nur mit spezialisierter Hardware realisierbar, die eng mit der Analyse- und Simulationssoftware verzahnt ist. Eine in der Praxis bereits eingesetzte Kombination ist das Ethernet/CAN-Interface VN5610 von Vector zusammen mit dem Entwicklungswerkzeug CANoe.IP. Diese Lösung ist bereits bei einigen Fahrzeugherstellern und Zulieferern im Einsatz. Ausblick In den nächsten fünf bis zehn Jahren werden wie bisher heterogene Netzwerkstrukturen als Cluster aus etablierten Bussystemen im Fahrzeug zu finden sein. Nach der Kameraanwendung wird Ethernet in weiteren Systemdomänen zum Einsatz kommen und zum Teil andere Bussysteme ablösen. Nach dem Einsatz als Backbone werden die Ethernet- und IP-Technologien in weitere Einsatzgebiete im Fahrzeug vordringen.

1/48

Für die Entwickler von Fahrzeugnetzwerken wird die Bedeutung von Multibus-Fähigkeit, Restbussimulation und hardware-nahen Zeitstempeln für alle Datenpakete weiter steigen. Die nächsten Entwicklungsschritte bei Vector im Ethernet- und IP-Bereich sind die Unterstützung des Anwenders bei der Signaldarstellung über alle IP-Protokollschichten (Bild 1) hinweg sowie das umfassende Überprüfen der Echtzeit- und serviceorientierten Kommunikation, wie beispielsweise AVB und SOME/IP. (oe)

Literatur: [1] OPEN Alliance SIG, http://www.opensig.org/ [2] Das IP-basierte Bordnetz kommt, Elmar Frickenstein, BMW AG, SEIS Statusseminar, 20.09.2011, http://www.strategiekreis-elektromobilitaet.de [3] Ethernet und IP im Kraftfahrzeug: Neue Anforderungen an das Entwicklungswerkzeug durch den Ethernet- und IP-Einsatz, Hans-Werner Schaal, Elektronik automotive April 2012 [4] Herausforderungen von Ethernet-Debugging, Helge Zinner, www.elektroniknet.de, Oktober 2012 [5] ISO CD 17215-1 (E) vom 2012-07-02 [6] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Programmier-Know-how erstellen, Stefan Albrecht und Peter Decker, Automobil Elektronik Juni 2012

Dipl.-Ing. Hans-Werner Schaal ist Business Development Manager im Bereich IP, Car2x und offener CAN-Protokolle wie J1939 und ISO11783 bei der Vector Informatik GmbH.

Dipl.-Ing. (FH) Matthias Schwedt ist FPGAEntwickler für Ethernet, FlexRay und MOST150 Netzwerk-Interfaces sowie Gesamtprojektleiter für die Ethernet Netzwerk-Interface Familie VN56xx bei der Vector Informatik GmbH.

@

Vector Informatik www.vector.com

1/50

1/51

1/52

1/53

1/54

1/55

Bild 1: Eine Datenbasis enthält sowohl System- als auch Datenbeschreibungen

Durch CAN FD erhöht sich die bereits erwähnte Komplexität

>>Verwenden der kompletten 64 Nutzdaten-Bytes zur

beim Definieren der Kommunikationsmatrix nochmals deut­

­effizienten Busnutzung. >>Die bisher definierten PDUs dürfen nicht verändert

lich. Um auch in diesem Fall eine effiziente Kommunikation zu erreichen, müssen Netzwerkdesigner die Signale in bis zu 8-mal größeren Nachrichten logisch sinnvoll gruppieren. Bei

werden. >>Das Gateway darf nicht wesentlich komplexer werden.

einigen Szenarien besteht außerdem die Anforderung, bereits

Neue Kommunikationsarten in der Automobilvernetzung Ethernet und CAN FD sind die Wegbereiter In aktuellen Fahrzeugen ist CAN das dominierende Bussystem für die Kommunikation zwischen Steuergeräten. In den letzten Jahren stieg das Kommunikationsaufkommen allerdings dramatisch an und die Fahrzeughersteller stoßen inzwischen an die Grenzen bei der Fahrzeugvernetzung mit CAN. Ethernet und CAN FD bieten eine höhere Bandbreite und übernehmen teilweise die Aufgaben von bestehenden Bussystemen. Dabei spielt nicht nur die höhere Bandbreite eine Rolle, sondern es stehen auch neue Kommunikationsarten im Vordergrund.

Alle genannten Punkte können realisiert werden, indem das

wäre der Vorteil der größeren Nutz­datenlänge verloren. Abhilfe

Gateway mehrere bereits definierte CAN-PDUs in einer

schafft hier der Mechanismus n-PDU-to-Frame-Mapping, der

CAN-FD-Nachricht versendet.

es erlaubt, mehrere PDUs in einer Nachricht zu versenden.

Bisher wurde der Inhalt einer Nachricht durch den jeweili­ gen CAN-Identifier (CAN ID) identifiziert. Diese Möglich­

N-PDU-to-Frame-Mapping anhand eines Gateways

keit hat der Empfänger der Daten nicht mehr, da mehrere

In einem Gateway-Szenario (Bild 2) kann die Bandbreite

PDUs in einer CAN-FD-Nachricht enthalten sind. Eine Lö­

­eines klassischen CAN-Busses nicht mehr ausreichen. An­

sung wäre, den Inhalt der CAN-FD-Nachricht statisch in

genommen, an einem Gateway sind drei CAN-Busse ange­

einer Datenbasis zu definieren. Im Gegensatz dazu wird

schlossen und alle werden schon an der Buslastgrenze be­

beim n-PDU-to-Frame-Mapping in der Datenbasis nur

trieben. An CAN-Bus 3 hängt ein Steuergerät das viele

noch festgelegt, welche PDUs potentiell in der CAN-FD-

Daten der anderen beiden Busse benötigt. Das Gateway ist

Nachricht enthalten sein können. Welche PDUs das Steuer­

für das Routen dieser Daten zuständig. Wenn das Steuer­

gerät tatsächlich versendet, entscheidet sich zur Laufzeit.

gerät an CAN-Bus 3 auf Grund eines Generationswechsels

Das beschriebene Szenario ist in Bild 2 schematisch darge­

zusätzlichen Kommunikationsbedarf hat, reicht die Band­

stellt: Jedes Steuergerät an CAN-Bus 1 und 2 sowie das

Eine klassische CAN-Nachricht überträgt bis zu acht Nutz­

CAN FD, der verbesserte CAN-Bus

breite von CAN-Bus 3 nicht mehr aus. Daher soll stattdes­

Gateway selbst sendet eine PDU, die auf dem CAN-FD-Bus

daten-Bytes. Aus Effizienzgründen ist es vorteilhaft alle

Für die heutigen Kommunikationsanforderungen reicht die

sen CAN FD zum Einsatz kommen. Zusätzlich gibt es noch

übertragen werden soll. Das Gateway füllt die CAN-FD-

acht Bytes zu verwenden, um ein möglichst gutes Verhält­

Übertragungsrate von maximal 1 Mbit/s auf dem CAN-Bus

weitere Anforderungen:

Nachricht bis zum Versendezeitpunkt mit den PDUs nach

nis zwischen Nutzdaten und Protokoll-Overhead zu erhal­

teilweise nicht mehr aus. Eine Lösung des Bandbreitenpro­

ten. Einzelne zu übertragende Datenelemente (Signale)

blems ist das Verwenden von CAN mit flexibler Datenrate

wie beispielsweise eine Raddrehzahl sind aber oftmals klei­

(CAN FD). Diese verbesserte Version des CAN-Protokolls

ner als acht Bytes. Daher werden mehrere Signale gemein­

bietet Übertragungsraten bis zu 8 Mbit/s. Erreicht wird

sam versendet. Jedes Bit ist kostbar und so wird das Defi­

dies durch zwei Erweiterungen zum klassischen CAN: >>1. Das Übertragen der Nutzdaten-Bytes erfolgt mit einer

nieren der CAN-Nachrichten mit den jeweils enthaltenen

1/56

für CAN definierte PDUs auf CAN FD zu übernehmen. Damit

Signalen sehr komplex.

höheren Bitrate. Damit die sonstigen Eigenschaften von

Die Kommunikationsmatrix wird in einer Datenbasis defi­

CAN, beispielsweise die maximale Leitungslänge, möglichst

niert. Für CAN geschieht dies wahlweise in einem der For­

gleich bleiben, werden der Header und der Trailer einer

mate DBC, FIBEX oder AUTOSAR System Description. Die Datenbasis (Bild 1) enthält neben den Nachrichten und de­

CAN-Nachricht mit der normalen Bitrate gesendet. >>2. Eine CAN-FD-Nachricht enthält bis zu 64 Nutz­daten-

ren Zusammensetzung auch die dazugehörigen Sende- und

Bytes. Wird die 8-fache Bitrate verwendet und werden

Empfangsbeziehungen. Ebenso sind darin die Protocol

64 Nutzdaten-Bytes gesendet, ist die Übertragungszeit

Data Units (PDU) definiert – eine Abstraktionsschicht zwi­

vergleichbar zu einer klassischen CAN-Nachricht mit

schen Signalen und Nachrichten.

8 Nutzdaten-Bytes.

Bild 2: Mögliches Einführungsszenario von CAN FD

1/57

Neue Kommunikationsarten in der Automobilvernetzung

und nach auf. Jeder PDU wird ein Header vorangestellt, da­

gen kann es allerdings vorteilhaft sein, bestehende CAN-

Netzwerk mit Baum-Topologie, in dem es auf Grund der

zum Einsatz: Service Discovery (SD) und Scalable Service-­

mit ein Empfänger die einzelnen PDUs aus der Nachricht

oder FlexRay-PDUs 1:1 auf Ethernet weiterzuleiten. Das für

Punkt-zu-Punkt-Verbindungen keine Kollisionen gibt.

oriented Middleware over Internet Protocol (SOME/IP).

extrahieren kann. Das Gateway muss also nicht mehr auf

CAN FD vorgestellte Versenden von mehreren PDUs inner­

Jeder Ethernet-Knoten hat eine MAC-Adresse, die zum ein­

Bisher wurde in der Fahrzeugvernetzung von Sender und

die Reihenfolge der PDUs achten und kann sich ein aufwän­

halb einer Nachricht kann unverändert für Ethernet ange­

deutigen Adressieren im Netzwerk verwendet wird. Ein

Empfänger gesprochen. Bei Service-orientierter Kommuni­

diges Einhalten des Nachrichtenlayouts sparen. Somit blei­

wendet werden. Im Gegensatz zu CAN FD und FlexRay

Knoten verarbeitet eine Nachricht, wenn seine MAC-Adres­

kation gibt es ein Steuergerät, das einen Dienst (Service)

ben die Ressourcen-Anforderungen an das Gateway so ge­

spezifiziert AUTOSAR für Ethernet zwei gleichwertige An­

se als Ziel angegeben ist – das heißt der Sender muss den

anbietet – den Server – und Steuergeräte, die diesen Dienst

ring wie möglich.

sätze. Der erste bereits bei CAN FD beschriebene Ansatz

Empfänger kennen und die Zieladresse in der Nachricht

verwenden – die Clients.

Das Versenden einer CAN-FD-Nachricht wird durch ver­

ist das n-PDU-to-Frame-Mapping im I-PDU-Multiplexer.

entsprechend eintragen. Diese 1:1 Kommunikationsbezie­

Über das Service-Discovery-Protokoll geben die Server zur

schiedene Ereignisse angestoßen, wie beispielsweise: >>1. Der Sendepuffer der Nachricht ist voll

Der gleiche PDU-Sammelalgorithmus ist im Socket Adap­

hung verwendet eine sogenannte Unicast-Adressierung.

Laufzeit bekannt, welche Services sie anbieten und wie

tor Modul spezifiziert, welches für das Anbinden des TCP/

Wird eine Unicast-adressierte Nachricht an alle Netzwerk­

­diese angesprochen werden. Clients rufen Methoden des

>>2. Ablauf des für die Nachricht definierten Timeouts

IP-Stacks an die restliche AUTOSAR-Architektur zuständig

knoten versendet, verarbeitet dennoch nur ein Empfänger

Servers auf (Remote Procedure Calls) oder registrieren sich

>>3. Nach Ablauf des für eine PDU definierten Timeouts wird

ist. Der Anwender kann beide Ansätze verwenden, wobei

das Paket, alle anderen verwerfen es.

beim Server, um nachfolgend automatisch Datenaktuali­

die Nachricht versendet, in der diese PDU enthalten ist >>4. Eine PDU besitzt ein zusätzliches Attribut, das nach

der Socket Adaptor noch zusätzliche Steuerungsmöglich­

Um ein unnötiges Fluten des Netzwerks zu verhindern, wur­

sierungen zu erhalten. Im letzteren Fall stellt der Server be­

keiten für Ethernet-basierte Kommunikation anbietet.

de ein aktives Netzwerk-Koppelelement eingeführt – der

stimmte Datenelemente – sogenannte Events – bereit und

Switch. Ein Switch leitet Nachrichten nach einer kurzen

verschickt deren Wert an alle registrierten Clients. Zu wel­

Mit Ethernet ändert sich die Vernetzungstopologie

Einlernphase nur an die Verbindung weiter, an der das ad­

chem Zeitpunkt die Datenaktualisierungen versendet wer­

Neben der Nutzdatenlänge unterscheidet sich Ethernet

ressierte Ziel zu erreichen ist. Damit wird die zur Verfügung

den entscheidet die Applikation des Servers. Durch das

Die Möglichkeit, mehrere PDUs in einer Nachricht zu ver­

auch bei der Vernetzungstopologie und Adressierung maß­

stehende Bandbreite effizient genutzt. Außerdem ermög­

n-PDU-to-Frame-Mapping ist ein Versenden mehrerer

dem Kopieren der PDU in den Sendepuffer ein sofortiges Senden der Nachricht auslöst

senden, ist in AUTOSAR seit Release 4.2.1 definiert. Der

geblich von anderen Netzwerktechnologien (Bild 3). CAN

licht ein Switch, das zur selben Zeit mehrere Unicast-adres­

Events innerhalb einer Nachricht möglich. Bild 4 stellt die

­Mechanismus ist netzwerkunabhängig im I-PDU-Multiple­

setzt auf eine klassische Bustopologie. FlexRay lässt sich

sierte Nachrichten parallel im Netzwerk versendet werden

beiden Prinzipien der Service-orientierten Kommunikation

xer-Modul spezifiziert, damit er neben CAN FD zum Bei­

physikalisch zwar mit einer Sterntopologie realisieren, ver­

können. Bild 3 zeigt ein beispielhaftes Ethernet-Netzwerk

grafisch dar.

spiel auch für FlexRay oder Ethernet zum Einsatz kommen

hält sich logisch gesehen aber stets wie ein Bus. Bei beiden

mit zwei Switches: Einer im Steuergerät ganz oben im Bild,

Bei Methodenaufrufen und Datenaktualisierungen kann

kann. Neben dem reinen Aufsammeln von PDUs unter­

Netzwerktechnologien wird eine Nachricht an alle Teilneh­

der zweite im unbeschrifteten Steuergerät. Farblich mar­

die Länge der zu übertragenden Daten stark variieren. Das

stützt das Modul auch die unterschiedlichen Versendebe­

mer gesendet. Alle Netzwerkknoten entscheiden selbst­

kiert sind parallele Kommunikationspfade durch das Netz­

Unterstützen dieser variablen Datenlänge ist ein Haupt­

dingungen und zwei unterschiedliche PDU Header-Forma­

ständig, ob eine Nachricht für sie relevant ist und weiter

werk, die sich gegenseitig nicht beeinflussen. Auf allen drei

te. Für CAN FD und FlexRay kommt hauptsächlich ein

verarbeitet wird. Bei CAN geschieht dies anhand der CAN

Verbindungen können maximal 100 Mbit/s full-duplex über­

4-Byte-Header zum Einsatz. Auf Ethernet wird meistens

ID, bei FlexRay anhand der Slot ID, wobei in beiden Fällen

tragen werden. Dadurch multipliziert sich die Bandbreite

ein 8-Byte-Header verwendet.

die ID bereits den Inhalt der Nachricht klassifiziert. Es gibt

von 100 Mbit/s mit der Anzahl der parallelen Kommunikati­

keine Möglichkeit eine Nachricht gezielt an nur einen Emp­

onspfade. Ethernet bietet auch 1:n- (Multicast) und 1:alle-­

Ethernet bietet eine wesentlich größere Nutzdatenlänge

fänger zu versenden. Daher sind CAN und FlexRay Broad­

Kommunikation (Broadcast). Wenn man diese Adressie­

Im Vergleich zu CAN bietet Ethernet eine mehr als 185-­fache

cast-Medien. Ethernet war zu Beginn seiner Erfolgsge­

rungsarten ungeschickt einsetzt, gehen die beschriebenen

Nutzdatenlänge. Eine klassische Definition von hunderten

schichte ebenfalls ein Bussystem. Die Verkabelung wurde

Vorteile von Ethernet verloren.

oder sogar tausenden Signalen innerhalb einer 1500 Bytes

mit Koaxialkabel und T-Elementen realisiert. Heute ist

Im Falle von Unicast-Adressierung wandert die Intelligenz

langen PDU ist kaum realisierbar. Für Gateway-Anwendun­

Ethernet in den allermeisten Fällen ein aktiv geswitchtes

im Netzwerk vom Empfänger in den Sender. Der Sender muss wissen, welche Empfänger im Netzwerk an welchen Daten beziehungsweise PDUs interessiert sind und muss die Nachrichten mittels n-PDU-to-Frame-Mapping ent­ sprechend zusammensetzen. Dabei können PDUs oder Nachrichten durchaus mehrfach versendet werden, wenn es mehrere Empfänger für die gleichen PDUs gibt. Dieser Empfänger-spezifische Daten Fan-Out ist in AUTOSAR am einfachsten mit dem Socket Adaptor realisierbar. Neues Kommunikationsparadigma: Service-orientierte Kommunikation Die Eigenschaften von Ethernet sowie der Wunsch der Fahrzeughersteller nach mehr Flexibilität und Beherrsch­ barkeit der Komplexität bei der Vernetzung führten zur Ein­ führung von Service-orientierter Kommunikation im Auto­ motive-Umfeld. Dieses aus der Internet-Welt bekannte Kommunikationsparadigma wurde auf die Fahrzeugver­

Bild 3: Vergleich der Netzwerktopologien von CAN (FD), FlexRay und Ethernet

1/58

netzung übertragen. Allerdings kommen spezifische, für den Automotive-Anwendungsfall optimierte Protokolle

Bild 4: Funktionsprinzipien von Service-orientierter Kommunikation mittels Service Discovery

1/59

merkmal von SOME/IP. Es serialisiert strukturierte und

Alle Bilder:

komplexe Anwendungsdaten, so dass die restliche Basis­

Vector Informatik GmbH

software eines Steuergeräts sich nur noch um das Versen­ den beziehungsweise Empfangen eines Bytestroms küm­

Links:

mern muss. Daher wird das exakte Nachrichtenlayout nicht

Website Vector: vector.com

mehr in einer Datenbasis definiert.

Produkt Information MICROSAR: www.vector.com/microsar

AUTOSAR unterstützt SD und SOME/IP vollständig. Auf

Produkt Information CANoe: www.vector.com/canoe

Grund der Plattformunabhängigkeit von SD und SOME/IP kommen die Protokolle auch beim Datenaustausch zwi­ schen AUTOSAR-Steuergeräten und anderen Plattformen

M.Eng. Marc Weber ist bei Vector Informatik in der Produktlinie Embedded Software für das Produktmanagement des Ethernet-Stacks verantwortlich.

zum Einsatz. Fazit CAN FD und Ethernet bieten mit der höheren Nutzdaten­ länge neue Möglichkeiten in der Datenübertragung. Sie stellen die Fahrzeughersteller und ihre Zulieferer aber auch vor neue Herausforderungen – unter anderem beim Erstel­ len der Systembeschreibung. Abhilfe schafft hier das n-PDU-to-Frame-Mapping, das mehrere PDUs in eine CAN-FD- oder Ethernet-Nachricht verpackt. Im Falle von Ethernet erhöhen sich aber nicht nur die Nutzdatenlänge und die zur Verfügung stehende Bandbreite. Eine kleine Re­ volution im Automotive-Umfeld stellt das geswitchte Netz­ werk und die damit verbundene neue Adressierungsart dar. Neue Mechanismen zur Datenverteilung sind notwendig. Darauf aufbauend wird mittels Service-orientierter Kom­ munikation der Datenaustausch dynamischer. AUTOSAR 4.2.1 unterstützt bereits alle vorgestellten Mechanismen und erleichtert somit das Umsetzen der neuen Kommuni­ kationsparadigmen. Am Markt sind bereits Basissoftware-­ Implementierungen dieser AUTOSAR-Version verfügbar wie beispielsweise MICROSAR von Vector. Ebenso ermöglichen

Ethernet-Steuergeräte effizient entwickeln

Werkzeuge wie CANoe das komfortable Analysieren und Testen von CAN-FD- und Ethernet-Netzwerken. Im Heft 7/8 2015 der Automobil Elektronik ist eine gekürzte

... mit den Automotive-Ethernet-Lösungen von Vector

Version dieses Artikels erschienen.

Diese unterstützen die spezifischen Physical Layer sowie die Protokolle SOME/IP, AVB, DoIP, etc. Ihre Vorteile im Überblick: > Werkzeuge zum Simulieren, Analysieren und Testen von Ethernet-Netzwerken und -Steuergeräten – auch zusammen mit anderen Fahrzeug-Bussystemen > Interfaces für den unverfälschten Zugriff auf Ethernet-Netzwerke

> Universelles Steuergerät für Kleinserien und Funktionsmuster – komplett mit AUTOSARBasissoftware > Schulungen zu Ethernet-Technologien im Automotive-Umfeld

> Embedded Software mit geringem Ressourcenbedarf für den Automotive-Einsatz

Mehr Infos und Downloads: www.vector.de/ae

Profitieren Sie von über 25 Jahren Erfahrung in der Automobilelektronik.

1/60

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

ENTWICKLUNGSWERKZEUGE

ENTWICKLUNGSWERKZEUGE

(all

Automotive-Ethernet-Schnittstelle:

Für den nötigen Durchblick Das Testen und Simulieren von Automotive-Ethernet-Netzwerken erfordert eine andere Vorgehensweise, als Entwickler es von CAN, LIN und FlexRay her gewohnt sind. Der Beitrag zeigt, wie entsprechende Hard- und Software idealerweise aufgebaut sind und zusammenspielen, um optimale Entwicklungs-, Simulations- und Testergebnisse zu erzielen. Von Peter Fellmeth und Matthias Schwedt

A

utomotive Ethernet ist im Gegensatz zu CAN, LIN und FlexRay nicht einfach ein weiterer Bus, der mit sehr hohen Übertragungsraten glänzt. Vielmehr konfrontiert das System Entwicklungs- und Testabteilungen mit einer vollständig anderen NetzwerkTopologie, die in vielen Punkten eine andere Denk- und Herangehensweise erfordert. Am Beispiel einer neuen, flexiblen Automotive-Ethernet-Schnittstelle wird gezeigt, mit welchen Herausforderungen es Entwickler im Detail zu tun haben.

Zentrum des Interesses an Ethernet ist für die Automobilindustrie der enorme Bandbreitengewinn, der für aktuelle und künftige Anwendungen eine immer wichtigere Rolle spielt. Systeme zum autonomen Fahren und Advanced Driver Assistance Systems (ADAS) sind stets auf hochaktuelle Umgebungsdaten von Kameras und Radarsystemen angewiesen. Dort und in anderen Bereichen braucht man hohe Übertragungsraten, um zum Beispiel VideoStreams und Sensordaten schnell zu übertragen. Aber auch beim Flashen der vielen Steuergeräte sind Zeit- und

aus Elektronik automotive Sonderausgabe Ethernet 2016 1/62

Kostenvorteile durch eine hohe Bandbreite willkommen. Mit dem IEEE-Standard für Automotive Ethernet 100BASET1 (OABR, OPEN Alliance BroadR-Reach) sind auf Basis eines einzigen ungeschirmten Adernpaares einfach und kostengünstig Hochgeschwindigkeitsnetze realisierbar. Das System ist in der Lage, in jede Richtung gleichzeitig eine Bruttodatenrate von 100  Mbit/s zu übertragen, und liefert nach dem Vollduplex-Verfahren somit maximal 200 Mbit/s.

Netzwerk aus 1:1-Verbindungen Den Vorteil der großen Bandbreite erkauft sich die Automobilbranche jedoch mit einem Paradigmenwechsel. Denn Automotive Ethernet unterscheidet sich von der Topologie her deutlich von Bus-Systemen wie CAN, LIN oder FlexRay. So stehen bei Ethernet keine Busstränge zur Verfügung, an denen zahlreiche Steuergeräte, Sensoren und Aktoren gemeinsam angeschlossen sind. Vielmehr hat man es mit einem Netzwerk aus Switches und vielen elektri-

eB

ilde

r: V ec t or)

schen Punkt-zu-Punkt-Verbindungen zu tun. Bei solchen vollständig geswitchten Netzwerken spielt die Topologie, das heißt die Anordnung der einzelnen Knoten, eine wichtige Rolle – insbesondere wenn es um Echtzeitfähigkeit geht. Technologien wie AVB (Audio Video Bridging) und TSN (Time Sensitive Networking) haben Auswirkungen auf Switches und Steuergeräte und werden in Zukunft AutomotiveEthernet-Netzwerke mit Funktionen wie beispielsweise Priorisierung von Datenpaketen und Zeitsynchronität bereichern. All dies erhöht die Komplexität spürbar und hat Auswirkungen auf das Entwickeln, Testen und Simulieren entsprechender Netze. Von jeher große Bedeutung im Entwicklungsprozess hat ein komfortabler Netzzugriff der Testund Simulationswerkzeuge – so auch bei Automotive Ethernet. Allerdings steht in geswitchten Netzwerken „der eine Bus“ nicht mehr zur Verfügung, an dem man sämtliche Signale und Botschaften abgreift oder an den man seine Test-Botschaften absetzt. Hier stellt sich die Frage, welche Fähigkeiten und Eigenschaften eine für aktuelle und zukünftige Anforderungen gerüstete Schnittstellen-Hardware mitbringen muss.

Möglichst rückwirkungsfreies Messen Die Basisanforderungen an eine Schnittstelle für Automotive Ethernet unterscheiden sich zunächst nicht von denen anderer Kommunikationssysteme: Damit eine entsprechende Hardware gleichermaßen für das Labor wie für Außeneinsätze im Fahrzeug geeignet ist, sollte sie über ein robustes Gehäuse sowie über zuverlässige und für viele Steckzyklen ausgelegte Steckverbinder verfügen und für einen erweiterten Temperaturbereich geeignet sein. Die Software-Werkzeuge benötigen umfangreichen Netzwerkzugriff, das heißt dass die Schnittstelle sowohl passive Lesezugriffe als auch aktive Schreibzugriffe beherrschen muss. Wichtig für sämtliche Aktivitäten sind natürlich hochgenaue Zeitstempel sowie Synchronisierungsmöglichkeiten mit weiteren Schnittstellen und mit anderen Bussystemen in Multibus-Umgebungen. Zudem ist für die Kommunikation der Hardware mit dem Simulations- oder

Analyse-Werkzeug eine stabile und Funktionsentwicklung performante Host-Anbindung erfordervs. Netzwerksicht lich. Bei der reinen Funktionsentwicklung Wie erwähnt, besteht ein geswitchtes Ethernet-Netzwerk aus etlichen reicht häufig ein TAP aus, da hier der 1:1-Verbindungen (Bild  1), deren VollFokus in der Regel auf einer einzelnen duplex-Übertragung einen rückwirVerbindung zwischen zwei Netzknoten kungsfreien Netzzugriff nahezu unmögliegt, zum Beispiel von Steuergerät zu lich macht. Selbst ein passives Abgreifen Steuergerät oder Steuergerät zu Switch. des Datensignals zwischen zwei SwitNeben dem reinen Mithören einzelner ches oder Steuergeräten mit einem Verbindungen übernimmt das Softwareidealen, hochohmigen Messsystem am Werkzeug auch Aufgaben wie die RestNetzwerkkabel nutzt wenig, da sich die bussimulation und das Hinzufügen von abgegriffenen Signale so nicht dekozusätzlichen Datenpaketen und Störundieren lassen. Zum Dekodieren ist jegen. Schwieriger gestaltet sich das Anaweils der gegenüberliegende Netzknolysieren von Automotive Ethernet bei ten der Übertragungsstrecke in der aufwändigeren Szenarien, wenn EntLage, der die empfangenen Informatiwickler eine Sicht auf das Gesamtsystem benötigen (Bild 3). Das Augenmerk liegt onen durch Differenzbildung mit dem dann auf kompletten Datenpfaden. eigenen Signal vom Signalgemisch seNeben Gesamtübertragungs- und Durchparieren kann. Praktisch führt somit kein Weg daran leitungszeiten in den Switches interesvorbei, eine im Fokus stehende 1:1-Versieren den Anwender Detailinformatiobindung aufzutrennen und zusätzliche nen, wie zum Beispiel verworfene BotHardware beispielsweise als sogenannschaften und MAC-Adresstabellen. Beten TAP (Test Access Point) einzufügen nötigt der Anwender gleichzeitig meh(Bild 2). Ein TAP stellt zwei Ethernet Ports rere Zugänge zum Netz, so fügt er an und eine Verbindung zum Rechner mit mehreren Stellen seine Schnittstellen dem Analyse-Werkzeug bereit, wobei ein. Handelt es sich bei Letzteren um verschiedene Betriebsarten eines TAP diskrete Geräte, ist spätestens jetzt ein unterscheidbar sind: Für reines MonitoSynchronisationsmechanismus erforderring sind passive TAPs ausreichend, die die Daten auf ISO-OSILayer 1, also der physikalischen Ebene durchschleifen. Dadurch ist der TAP weitestgehend transparent in Bezug auf die wesentlichen Kommunikationseigenschaften. Fehler beim Übertragen von Bild 1. Beispiel für ein geswitchtes Ethernet-Netzwerk aus mehreEthernet-Paketen werren 1:1-Verbindungen. den weitergeleitet und nicht verworfen. Für die Zeitsynchronisation im Netzwerk ist wichtig, dass die zwangsweise auftretende Durchlaufverzögerung konstant und minimal ist. Sobald man aber in das Geschehen eingreifen und Daten verändern will, sind aktive TAPs gefragt. Sie arbeiten – vergleichbar mit einem Switch – auf der SicheBild 2. Ein typischer Messaufbau mit Signalabgriff durch Auftrennen der 1:1-Verrungsebene (Layer 2). bindungen und Durchschleifen durch zeitlich synchronisierte Schnittstellen. aus Elektronik automotive Sonderausgabe Ethernet 2016 1/63

ENTWICKLUNGSWERKZEUGE

lich, damit alle Schnittstellen auf derselben Zeitbasis arbeiten und die Tests brauchbare Ergebnisse liefern. Neben dem Netzwerkzugang stellt auch die Topologie bei geswitchten Netzwerken eine Herausforderung dar. Ein Beispiel aus der Praxis verdeutlicht die grundlegende Problematik beim Testen eines einzelnen Steuergeräts: Der reale Prüfling ist über eine Automotive-Ethernet-Schnittstelle mit dem Testrechner verbunden, auf dem zur Restbussimulation zwei virtuelle Steuergeräte laufen. Üblicherweise verfügt

ENTWICKLUNGSWERKZEUGE

der PC mit dem Simulationswerkzeug über genau einen TCP/IP-Stack, sodass beide virtuellen Steuergeräte über den gemeinsamen Stack nach außen zur Schnittstelle hin kommunizieren. Der vom PC erzeugte Datenverkehr entspricht somit keinesfalls einer realen Situation. Denn das zu testende Steuergerät kann die Botschaften der beiden simulierten Steuergeräte nicht unterscheiden, da sie unter derselben IP- und MAC-Adresse agieren. Umgekehrt ist es nicht in der Lage, die virtuellen Steuergeräte separat zu adressieren. Man

Bild 3. Datenübertragung vom Steuergerät 1 über drei Verbindungen und zwei Switches zum Steuergerät 5.

müsste das Steuergerät eigens modifizieren, nur um testen zu können – eine höchst ineffiziente Arbeitsweise. Abhilfe schaff t ein spezialisiertes Werkzeug, das es erlaubt, hinter jedes simulierte Steuergerät eine eigene TCP/ IP-Stack-Instanz zu legen (Bild  4). Zusammen mit der Schnittstelle kann der Anwender dann das reale Steuergerät so stimulieren, dass die simulierte Kommunikation der realen entspricht. Im weiteren Testverlauf könnte etwa ein Anwender auf die Idee kommen – wie er es von CAN gewohnt ist – „mal eben“ eines der simulierten Steuergeräte aus der Simulation herauszulösen und durch ein reales Pendant zu ersetzen. Wenn er das an einem noch freien Ethernet Port der Schnittstelle anschließt, müsste das doch funktionieren? Mit diesem Ansatz ignoriert er jedoch die Tatsache, dass Ethernet-Netze nur 1:1-Verbindungen erlauben. Eine 1:1-Verbindung existiert in der Testanordnung aber bereits zwischen dem realen Steuergerät und der Software mit dem verbleibenden simulierten Steuergerät. Weitere Geräte lassen sich in der Praxis nur durch das Etablieren neuer zusätzlicher 1:1-Verbindungen hinzufügen, wobei die neuen Netzfragmente mit Hilfe von Switches an das bestehende Netzwerk zu koppeln sind. Wenn die Schnittstelle intern eine Switch-Funktion bereitstellen oder sich dahingehend umkonfigurieren lassen würde, könnte der Anwender seinen Plan umsetzen und das zweite externe Steuergerät an einen freien Port anschließen.

Die Summe der Ports ist nicht alles

Bild 4. Restbussimulation mit mehreren TCP/IP Stacks. Im Rahmen der Integration wird das simulierte Steuergerät ECU 2 durch ein reales Steuergerät unter Berücksichtigung der Topologie ersetzt. aus Elektronik automotive Sonderausgabe Ethernet 2016 1/64

Eine leistungsfähige Automotive-Ethernet-Schnittstelle sollte mit zahlreichen Ports ausgestattet sein. Zwölf 100BASE-T1-Anschlüsse reichen aus, um auch vergleichsweise komplexe TestSzenarien umzusetzen. Doch die Anzahl der Ports allein ist nicht ausschlaggebend, wie oben schon gezeigt wurde. Es ist wichtig zu verstehen, dass der Wechsel eines Gerätes zwischen Simulation und realer Welt einer Topologieänderung gleichkommt. Nur mit herkömmlichen Standardkomponenten und -werkzeugen ausgestattet, können solche eigentlich einfachen Arbeitsschritte mit erheblichen Herausforderungen verbunden sein. Wie sollte vor diesem Hintergrund nun eine leistungs- und zukunftsfähige Automotive-Ethernet-Schnittstel-

le aussehen? Idealerweise entkoppelt eine solche Schnittstelle die Simulation von den direkten Ethernet Ports, indem es PC-seitig einen sogenannten Applikationskanal dazwischen schaltet. Des Weiteren füllt es die Lücke zwischen Applikationskanal und 100BASE-T1-Ports mit einer frei konfigurierbaren Transferfunktion (Bild 4). Eine typische und häufig benötigte Transferfunktion ist etwa die Funktion eines Switch. Durch den Einsatz eines FPGA lassen sich solche Transferfunktionen einfach auswählen und konfigurieren. Auch eine zukünftige Erweiterung für neue Transferfunktionen lässt sich hierüber realisieren. Die Schnittstelle ist somit flexibel an die praktischen Herausforderungen der verschiedenen Entwicklungs- und Testphasen anpassbar. Weiterhin ist nahezu jede Netzwerk-Konstellation und -Topologie auf eine funktional identische Testanordnung abbildbar. Bei Bedarf konfiguriert der Anwender mehrere parallele Applikationskanäle sowie Transferfunktionen und verknüpft diese mit den Ethernet Ports. Neben Switches kommen als Transferfunktionen unter anderem der „PHY Bypass“ (Mapping auf Layer 1) oder der „MAC Bypass“ (Store-and-ForwardPrinzip auf Layer 2) in Frage. Die Schnittstelle erlaubt dem Werkzeug jederzeit auch vollen Zugriff auf die Ethernet Ports, entweder direkt oder relativ über den Applikationskanal. Der native Zugriff auf Ethernet Frames am Bus-Transceiver zeigt beim Monitoring Probleme am Bus wie beispielsweise beschädigte Frames an, die bei herkömmlichen Switches von der MAC-Schicht herausgefiltert werden. Dies erlaubt aufschlussreiche Analysen über Fragestellungen, was direkt am Bus passiert und was am Steuergerät ankommt.

Skalierbare Schnittstellen-Familie Die zuvor beschriebenen Funktionen und Anforderungen hat Vector in sein neues Automotive Ethernet Interface VN5640 integriert (Bild 5). Das Gerät ist speziell für den Anwendungsfall ausgelegt, auf Netzwerksicht zu simulieren oder zu messen, und verfügt über insgesamt 16 Ethernet Ports, zwölf für IEEE 100BASE-T1 und vier für Standard-Ethernet-Anbindungen wie 100BASE-TX oder 1000BASE-T. Eine besonders schnelle Host-Anbindung sorgt für das Weiterleiten der gewaltigen Datenmengen, die

Bild 5. Das Automotive Ethernet Interface VN5640 bietet vielfältige Transferfunktionen, umfangreiche Filtermechanismen und ausreichend Ethernet Ports. an den Ethernet Ports anfallen können. Da für die üblichen Test- und Simulationsaufgaben in der Regel nur eine Teilmenge der Ethernet Frames relevant ist, sind in der VN5640-Hardware vielfältige Filtermechanismen aktivierbar. Auf Basis von diversen Protokollen leiten die Filter nur die wirklich benötigten Ethernet Frames an den PC weiter und tragen so zu einer signifikanten Entlastung der Simulations- und Test-Software bei. Neben dem üblichen Interface Mode kann das VN5640 auch ohne PC im Stand-alone-Modus verwendet werden. Darüber hinaus ist geplant, dass der Anwender zukünftig einen Ethernetfähigen Standard-Automotive-Datenlogger anschließen kann. Zusammen mit dem schon seit geraumer Zeit verfügbaren 2-Port Interface VN5610 bildet das VN5640 eine skalierbare Automotive-Ethernet-Interface-Familie, die untereinander und mit dem Test- und Simulationswerkzeug CANoe von Vector zusammenarbeitet. Viele neue Funktionen des VN5640 werden zukünftig auch vom VN5610 unterstützt und nach einem Treiber-Update verfügbar sein. Alle Interfaces der Familie sind über eine gemeinsame Programmierschnittstelle (API) ansprechbar. In Kombination mit CANoe lassen sich die umfangreichen Konfigurationsmöglichkeiten bequem mit Hilfe von Beschreibungsdateien vornehmen. Dies bietet außerdem den Vorteil der Austauschbarkeit mit anderen Abteilungen, Zulieferern und Kunden. Ferner bietet CANoe Zugriff auf die erweiterten Statistik- und Switch-Informationen, wie zum Beispiel Qualitätsinformationen von Übertragungsstrecken, Inhalte von MAC-Adresstabellen oder Queue-Stände von Swit-

ches, die Aufschluss über die Auslastung einzelner Link-Strecken geben. Um dem weiter steigenden Bedarf an Bandbreite gerecht zu werden, arbeitet die IEEE bereits an einer GigabitVariante von BroadR-Reach (1000BASET1). Durch den flexiblen Aufbau der Hardware ist das VN5640-Interface für weitere Physical Layers vorbereitet und schnell verfügbar. Technologien wie AVB (Audio Video Bridging) und TSN (Time Sensitive Networking) werden in absehbarer Zeit für garantierte WorstCase-Latenzen, priorisierte Datenübertragungen und Zeitsynchronität sorgen. Diese und sonstige Weiterentwicklungen werden zu gegebener Zeit in Firmware- und Software Updates Berücksichtigung finden. ku

Dipl.-Ing. (FH) Peter Fellmeth studierte Technische Informatik mit Schwerpunkt Automatisierungstechnik an der FH Esslingen. Bei der Vector Informatik GmbH ist er als Gruppenleiter und Produktmanager verantwortlich für die Entwicklung von Produkten im Umfeld von Automotive Ethernet, J1939 und ISOBUS.

Dipl.-Ing. (FH) Matthias Schwedt studierte Nachrichten- und Kommunikationstechnik mit dem Schwerpunkt Digitale Signalverarbeitung und Telekommunikation an der Hochschule Offenburg. Bei Vector ist er als Produktmanager im Bereich Network Interfaces für die Automotive-EthernetInterface-Familie VN5600 verantwortlich.

aus Elektronik automotive Sonderausgabe Ethernet 2016 1/65

1/66

1/67

1/68

INFOTAINMENT UND TELEMATIK

INFOTAINMENT UND TELEMATIK

Car2X – von der Forschung zur Serienentwicklung Für den Verantwortlichen in der Serienentwicklung ergeben sich bei Car2X-Systemen neue Herausforderungen. Zum einen kommuniziert das zu evaluierende Car2X-Steuergerät mit vielen Fahrzeugen und Baken in seinem Umfeld. Dadurch erhöhen sich die Anzahl der ausgetauschten Informationen sowie deren Komplexität erheblich im Vergleich zur bisherigen Netzwerkentwicklung im Serienfahrzeug. Zum anderen haben IPStandards inzwischen Einzug ins Fahrzeug gehalten, die Luftschnittstelle nach IEEE 802.11p ist für die meisten Entwickler allerdings noch Neuland. Mit darauf abgestimmten Werkzeugen lassen sich diese Herausforderungen bereits meistern. Von Hans-Werner Schaal und Thomas Löffler

C

ar2X-Kommunikation, auch als Vehicle-to-Vehicle- und Vehicleto-Infrastructure-Communication bekannt, ist der Austausch von Informationen zwischen Verkehrsteilnehmern und Infrastruktur. Ziel soll es sein, Sicherheit und Komfort zu erhöhen sowie den Verkehrsfluss zu opti-

mieren. Das technische Gesamtsystem zur Sicherstellung von Car2X-Kommunikation wird als Intelligent Transport System (ITS) bezeichnet. Das Basiskonzept der Car2X-Kommunikation beruht auf dem Senden und Empfangen standardisierter Nachrichten über die Luftschnittstelle sowie der Interpretation

der enthaltenen Statusinformationen durch die Verkehrsteilnehmer. Gemäß der momentanen Verkehrssituation hält die ITS-Station (ITS-S) die Nachrichten stets aktuell und sendet diese zyklisch oder ereignisgesteuert. Die wichtigsten Statusinformationen werden über die Nachrichten Cooperative Awareness Message (CAM), Decentralized Environmental Notification Message (DENM), Signal Phase and Time (SPaT) und Topology Specification (TOPO) übertragen. Das Europäische Institut für Telekommunikationsnormierung (ETSI) hat die CAM- und DENMNachrichten bereits spezifiziert. SPaT und TOPO werden zur Zeit projektbezogen gehandhabt. Intelligente Verarbeitungseinheiten der empfangenden Verkehrsteilnehmer beispielsweise eines Fahrzeugs haben dadurch die Möglichkeit, die sie unmittelbar betreffende Verkehrssituation weiträumig zu erfassen, den Fahrzeugführer bei Bedarf zu warnen, zu unterstützen oder sogar in die Fahrzeugführung einzugreifen.

WLAN-Empfangsbereich

!

Fehlersuche an der Luftschnittstelle

WLAN-Empfangsbereich

! A

B

C

Bild 1. Fahrzeug A bleibt liegen und sendet über sein ITS-S DENM-Nachrichten an Verkehrsteilnehmer B und C in seinem Umfeld. Diese erweitern den Empfangsbereich durch Weiterleitung der Nachricht.

Szenario: ein liegengebliebenes Fahrzeug

Anforderungen an die ITS-Station im Szenario

Am Beispiel eines von der ETSI definierten Car2X-Szenarios [1] werden im Folgenden die Anforderungen an Entwicklungswerkzeuge, die den Systemverantwortlichen der ITS-S bei der Entwicklung und Validierung unterstützen, abgeleitet. Ähnliche Verkehrsszenarien sind auch beim CAR 2 CAR Communication Consortium oder beim Projekt DRIVE C2X beschrieben [2]. Im Szenario Car Breakdown Warning soll vermieden werden, dass ein liegengebliebenes Fahrzeug für den nachfolgenden Verkehr eine Gefahr oder gar eine Unfallursache darstellt. Daher sendet die ITS-S des Fahrzeugs A eine standardisierte Nachricht, die innerhalb seines WLAN-Sendebereichs empfangen werden kann (Bild 1). Ein herannahendes Fahrzeug B empfängt, verarbeitet und leitet diese Nachricht weiter. Der WLAN-Sendebereich erweitert sich dadurch, so dass selbst entfernte Fahrzeuge C und Baken (Road Side Units, RSU) die Nachricht empfangen und ebenfalls weiterleiten können. Somit hat Fahrzeug C die Möglichkeit, den Gefahrenbereich noch zu umfahren. Dank der frühzeitigen Warnung kann Fahrzeug B rechtzeitig abbremsen, wenn etwa die Sicht durch Nebel oder Hindernisse eingeschränkt ist. Um Aktualität sicherzustellen und Fehlinformation zu vermeiden, wird unterschieden, ob die Nachricht von der ursprünglichen Quelle A stammt oder nur durch Sender, also die Empfängerfahrzeuge B und C, weitergeleitet wurde. Weil weitergeleitete Nachrichten zusätzlich eine Lebenszeit haben, werden sie nur über eine bestimmte Zeitspanne weitergegeben. Aufgrund der Geoposition und eines definierten Ausbreitungsgebietes (Dissemination Area) ist zudem festgelegt, ob die Fahrzeuge B oder C die Nachricht überhaupt weiterleiten.

Die ITS-S muss aus dem Kontext ihres Umfelds, also aus der Summe der von verschiedenen Quellen erhaltenen Nachrichten CAM, DENM, SPaT und TOPO, ein hinreichend komplettes Bild der Verkehrssituation ab- und Maßnahmen für das eigene Fahrzeug einleiten. Die Echtzeitanforderungen sind dabei hoch. Nach Spezifikation müssen DENM im obigen Beispiel zwar nur mit 10 Hz aktualisiert werden. Allerdings wird die geforderte Latenzzeit im obigen Szenario mit weniger als 100 ms angegeben [1]. Eine Übertragung über GSM ist damit nicht mehr realistisch. Nur mit der WLAN-Technologie nach IEEE 802.11p oder LTE ist diese Echtzeitanforderung realisierbar. Die ITS-S von Fahrzeugen im Empfangsbereich müssen zunächst entscheiden, ob empfangene Nachrichten für das eigene Fahrzeug relevant sind: zum einen, ob sie betroffen sind, und zum anderen, ob sie weiterleiten. Betroffen sind sie, wenn sie sich auf derselben Straße befinden oder auf dem Weg dorthin. Das lässt sich über die Botschaftsinhalte „Richtung“ (Heading) der empfangenen CAM-Nachricht und „Wegepunkte“ (Waypoints) in der Nachricht DENM ermitteln. Weiter spielen der Kurs des eigenen Fahrzeugs sowie Informationen über Topologie und Status von Ampelanlagen eine Rolle. Schließlich muss die ITS-S bewerten, ob die Information für das Umfeld potenziell relevant ist. Wenn das der Fall ist, muss es diese korrekt weiterleiten. Software-Entwicklungswerkzeuge können den Systemverantwortlichen in allen Phasen entlang des V-Modells dabei unterstützen, die Funktion der ITS-S sicherzustellen. Anders als bei der auf ein einzelnes Fahrzeug beschränkten Netzwerkentwicklung ist die Betrachtung des Umfelds dabei unabdingbar. An das Werkzeug ergeben sich dabei die nachfolgenden Anforderungen.

Messtechnisch lässt sich das obig dargestellte Szenario auf Bild 2 reduzieren, gegebenenfalls mit einer höheren Anzahl von ITS-Stationen. Die Funktion der ITS-S ist zwar standardisiert, doch wird sie von unterschiedlichen Herstellern implementiert. Im Fehlerfall muss zunächst in der Regel analysiert werden, ob alle Beteiligten auf demselben Funkkanal senden und empfangen. Daher ist es notwendig, die Luftschnittstelle als Kommunikationsmedium zu unterstützen. Erst wenn nachgewiesen ist, dass die Kommunikation über die Luftschnittstelle korrekt funktioniert, ist eine Protokollanalyse sinnvoll.

Protokollanalyse Der Verantwortliche für den ITS-S-Systemtest in der Serienentwicklung ist darauf angewiesen, dass ihm empfangene Nachrichteninhalte im Entwicklungswerkzeug applikationsorientiert präsentiert werden, also entweder als physikalische Größe mit Einheit oder interpretiert. So müssen die Signale „Generation Time“ (in CAM und DENM) mit Einheit und das CAM-Signal „Vehicle Type“ interpretiert, also beispielsweise als „Car“ oder „Motor Cycle“ dargestellt werden. Entsprechendes gilt für die DENM-Signale „Event Position“ (mit Breitengrad, Längengrad) oder „Cause Code“ (interpretiert).

Visualisierung der Fahrzeugsignale auf einer geografischen Karte Leider ist selbst die interpretierte Darstellung der Botschaftsinhalte mit Filtermöglichkeit aufgrund der Anzahl der Verkehrsteilnehmer und der Komplexität der Kommunikation oft nicht ausreichend. Wichtiges muss unmittelbar erkennbar sein – auch wenn es aus der

ITS-Station Hersteller 1

ITS-Station Hersteller 2

Luftschnittstelle 802.11p WLAN-Adapter Analysewerkzeug

Bild 2. Herausforderung Luftschnittstelle: Die Überprüfung des Datenverkehrs kann nur mit einem IEEE-802.11p-kompatiblen Analysewerkzeug erfolgen. Elektronik automotive 12.2012

1/70

1/71

INFOTAINMENT UND TELEMATIK

Menge interpretierter Information nicht offensichtlich ist. Das oben beschriebene Szenario verdeutlicht, dass die Relevanz eines Car2XSignals für das empfangende Fahrzeug nur im Kontext weiterer Verkehrsteilnehmer seines relevanten Umfelds ermittelt werden kann. Damit lässt es sich auch nur in diesem Kontext validieren. Zur Validierung müssen unter anderem die Geopositionen und die Richtungsvektoren der beteiligten Fahrzeuge in Betracht gezogen werden. Zur Klärung der Relevanz bietet sich eine Kartendarstellung an (Bild 3), die sich im Praxistest, zum Beispiel auf dem Testgelände in Helmond, Niederlande [3] und bei der Integrationsunterstützung des ITS World Congress [4] in Wien schon bewährt hat. Die Auswertung vereinfacht sich für den Entwickler deutlich, wenn den Sendern individuelle Zusatzinformationen wie Fabrikat, Fahrzeugtyp, Modell oder Nummernschild zugeordnet sind. Intuitive Symbole und Farb-Codes ermöglichen einen leichten Überblick über die Situation. So sind auf der Karte in Bild 3 mobile Sender als Pfeil, Wegepunkte als Fahne und RSUs als Kreise dargestellt. Probleme mit falsch gesendeter Fahrtrichtung (Heading) sind so im Gegensatz zur reinen Protokolldarstellung (Bild 4) unmittelbar erkennbar. Darüber hinaus lassen sich in die Karte topologische Informationen (TOPO) und Gefahreninformationen (DENM) einblenden, die für viele Szenarien ebenfalls eine Rolle spielen.

Unmittelbare Verfügbarkeit und schnelle Rekonfiguration In der Praxis ist es hilfreich, wenn das Testsystem den kompletten Datenverkehr ohne große Rüstzeit sofort darstellen kann. Hierzu ist die Kenntnis des zugrundeliegenden Datenmodells er-

INFOTAINMENT UND TELEMATIK

Bild 3. In der Karte werden Fahrzeuge mit Richtungspfeil und RSUs mit Kreisen dargestellt. Die in der DENM übertragenen Gefahreninformationen und die Wegepunkte, die zu dieser Gefahrenstelle führen, werden ebenso dargestellt wie das für diese Gefahr definierte Ausbreitungsgebiet der Nachricht. forderlich, das üblicherweise über Abstract Syntax Notation.1 (ASN.1) definiert ist. Allerdings kann ASN.1 keine Netzwerke darstellen und es fehlt die angesprochene Möglichkeit, Signale mit physikalischen Einheiten zu verwalten. Darum müssen diese Informationen ergänzend zur ASN.1-Beschreibung leicht im Analyse- und Entwicklungswerkzeug parametrierbar sein. Die ASN.1-Datei hingegen ist idealerweise automatisch importierbar. Wenn die Kommunikationsregeln aufgrund von Updates verändert werden, stehen dadurch die neuen Signalwerte im Werkzeug sofort wieder zur Verfügung – ohne dass hierfür etwa rekompiliert werden muss.

Stimulation und Simulation Selbst bei funktionierenden Prototypen besteht oft der Wunsch, an der Kommunikation aktiv teilzunehmen und beispielsweise einzelne CAM-, DENM-, SPaToder TOPO-Nachrichten korrekt oder gar verfälscht zu senden. Dadurch prüft der Car2X-Entwickler erste Prototypen durch gezielte Stimulation effizient. Allerdings muss dazu das Entwicklungswerkzeug protokoll- und luftschnittstellenkonform sendefähig sein.

Bei Testfahrten ist es hilfreich, RSUs oder andere Fahrzeuge, die in der Realität gar nicht vorhanden sind, in der vorher eingeführten Kartendarstellung einzublenden. Das Entwicklungswerkzeug kann so auf der Testfahrt die Rolle einzelner oder gar aller anderen Verkehrsteilnehmer übernehmen und deren Kommunikation auf der Luftschnittstelle simulieren. Für das auf der Testfahrt befindliche ITS-S ist dann nicht erkennbar, ob empfangene Car2X-Signale der Realität oder der Simulation entstammen. Das setzt voraus, dass für alle Verkehrsteilnehmer separate Software-Modelle hinterlegt werden können, die einzeln aktivierbar sind und mit der Kartendarstellung verbunden werden können.

Kompatibel zur Entwicklungsstrategie bisheriger Bussysteme Aktuelle Fahrzeugnetzwerke basieren auf CAN, FlexRay, LIN, MOST und seit neuestem auch auf IP, zum Beispiel in Form der BroadR-Reach-Technologie [5]. Bei der Entwicklung einzelner Steuergeräte ist die Methodik der Restbussimulation gebräuchlich. Steuergeräte lassen sich damit parallel und unabhängig voneinander entwickeln. Der für das betrachtete Steuergerät relevante, aber noch nicht zur Verfügung stehende Netzwerkteil wird durch das Entwicklungswerkzeug in der Software simuliert. Weil die ITS-S in der Regel auch Teilnehmer an einem der oben genannten Fahrzeugbusse ist, bietet sich die Restbussimulation hier ebenfalls an.

Entwicklungswerkzeuge für die Car2X-Kommunikation Bild 4. Protokolldarstellung von Car2X-Informationen im Trace-Fenster von CANoe und CANalyzer. Elektronik automotive 12.2012 1/72

Wie müssen die geforderten Car2X-Erweiterungen für ein Entwicklungs- und

Validierungswerkzeug für den Serieneinsatz aussehen? Der Schlüssel zur Lösung ist die Verbindung der obigen Ansätze mit den in der Automobilbranche üblichen und bewährten Vorgehensweisen bei der konventionellen Netzwerkentwicklung. Als MultibusWerkzeuge haben sich CANoe und CANalyzer bei der Entwicklung der Fahrzeug-Bordnetze CAN, LIN, FlexRay, MOST und IP bewährt. Mit der Option Car2X werden diese Werkzeuge für die Entwicklung von Komfort- und Fahrerassistenzfunktionen erweitert. Hierzu wird der in Bild 5 dargestellte Simulationsaufbau um die Luftschnittstelle ergänzt. Das Testsystem ersetzt bei Bedarf das gesamte Umfeld der ITS-S und kann sowohl senden als auch empfangen. Dabei sind die genannten Anforderungen Protokollanalyse, schnelle Rekonfiguration und Visualisierung durch eine Kartendarstellung bereits berücksichtigt. Um bei der Validierung gezielt Störinformation zu senden, steht der WLAN Packet Builder mit einer intuitiven Bedienoberfläche zur Verfügung. Er ermöglicht es, korrekte und verfälschte pWLAN-Pakete zu Testzwecken komfortabel zu erstellen und zu senden. Für komplexere Simulationen von Verkehrsszenarien mit Fahrzeugen und der Infrastruktur nutzt der Car2X-Entwickler spezifische, in CAPL oder als DLL bereitgestellte Funktionsbibliotheken. CANalyzer.Car2x deckt die wichtigsten Anforderungen an ein Car2X-Entwicklungswerkzeug, wie Protokollanalyse, Unterstützung der Luftschnittstelle und Stimulation, bereits ab. Die Visualisierungs- und die schnelle Rekonfigurationsmöglichkeit erhöhen zudem die Nutzbarkeit des Entwicklungswerkzeugs erheblich. Darüber hinaus erweitert CANoe.Car2x den Anwendungsbereich um vielfältige Simulations- und Testfunktionen.

Ausblick Zukünftige, auf ITS-S gestützte Fahrerassistenzsysteme werden weitere Fahrzeugdynamikdaten ergänzend zur Car2X-Kommunikation mit einbeziehen müssen, die an CAN-, FlexRay- oder IPNetzwerken im Fahrzeug anliegen. Es wird daher zunehmend wichtig, dass das Entwicklungssystem sowohl die Car2X-Kommunikation als auch die Kommunikation auf den konventionel-

ASN.1 Knoten physik. Parameter Entwicklungswerkzeug Simulation der Verkehrsteilnehmer Virtuelles Teilsystem (eigenes Fahrzeug)

Datenbasis

Luftschnittstelle Luftschnittstelle 802.11p WLAN-Adapter 802.11p WLAN-Adapter CAN I/O

Validierung TestReport XML/HTML

CAN

ITS-Station (ECU under Test)

analoge und digitale I/Os, Zähler, PWM, etc.

Bild 5. ITS-S-Testsystem: Das Testsystem ersetzt bei Bedarf das gesamte Umfeld der ITS-Station und kann sowohl senden als auch empfangen. Der übliche Simulationsaufbau wird um die Luftschnittstelle erweitert. Das ITS-S kann wie in der Realität über Luftschnittstelle und lokale Bussysteme kommunizieren. (Bilder: Vector Informatik GmbH)

len Bussystemen zeitstempelgetreu und mehrkanalig darstellen kann. CANoe.Car2x und CANalyzer.Car2x sind dafür heute schon gerüstet. Bei der Analyse leistet das Kartenfenster einen wichtigen Beitrag. Der nächste Entwicklungsschritt könnte sein, über diese Karte Szenarien und Rahmenbedingungen des Verhaltens der simulierten Verkehrsteilnehmer zu definieren. Als 802.11p-WLAN-Interface-Hardware für die Kommunikation zwischen Fahrzeugen sowie zwischen Fahrzeug und der Infrastruktur kann ein vorhandener, im Fahrzeug ohnehin verbauter Funkadapter verwendet werden. Dieser lässt sich gemeinsam mit der Fahrzeuganwendung oder exklusiv als Mess-Interface einsetzen. Das ist für viele Anwendungsfälle eine pragmatische und flexible Lösung. Für manche Aufgaben kann allerdings die Messgenauigkeit dieser Funkadapter nicht ausreichen. Deshalb wird zukünftig eine präzisere, weiterentwickelte MessHardware zur Debatte stehen. eck

www.drive-c2x.eu/news-item/items/ drive-c2x-ditcm-making-cooperativesystems-cooperate [4] ITS World Congress, Wien, http://2012. itsworldcongress.com [5] Schaal, H.-W.: Ethernet und IP im Kraftfahrzeug. Elektronik automotive. Heft 4.2012 S. 38ff.

Dipl.-Ing. Hans-Werner Schaal studierte Nachrichtentechnik an der Universität Stuttgart und Electrical & Computer Engineering an der Oregon State University, USA. Er ist als Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking und für IP und Car2X zuständig. Zuvor war Hans-Werner Schaal Entwicklungsingenieur, Projektleiter und Produktmanager in verschiedenen Branchen im Bereich Testwerkzeuge für mehrere Netzwerk-Technologien. [email protected]

Dipl.-Ing. Thomas Löffler Literatur: [1] ETSI, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Definitions, ETSI TR 102 638 V1.1.1 (2009-06) [2] CAR 2 CAR Communication Consortium, Related Projects, www.car-to-car. org/index.php?id=6&L=oksjfr [3] Making cooperative systems cooperate, DRIVE C2X @ DITCM Helmond, NL,

ist Senior Software Development Engineer bei der Vector Informatik GmbH. Er ist verantwortlich für das Thema Car2X. Die Schwerpunkte sind die Produktdefinition und die Projektleitung von Kundenprojekten. Herr Löffler vertritt Vector in diversen Car2X-Arbeitsgruppen. [email protected]

Elektronik automotive 12.2012 1/73

Bussysteme

IIII MOST

Serielle Bussysteme im Auto

Teil 5: MOST für die Übertragung von Multimediadaten Ein Auto der Premiumklasse ähnelt zunehmend einem mobilen Büro. Auf Wunsch des Kunden drängen immer mehr moderne Unterhaltungs- und Informationsmedien in das Kraftfahrzeug. Zu den wichtigsten Herausforderungen gehört dabei, den Verkabelungsaufwand gering zu halten und gleichzeitig den gestiegenen Anforderungen an den Funktionsumfang eines Infotainmentsystems im Fahrzeug gerecht zu werden. In circa 50 Modellreihen kommt daher bereits das Bussystem MOST (Media Oriented System Transport) zur Übertragung von Audio- und Videosignalen zum Einsatz.

Data Bus) eine einheitliche Kommunikationstechnologie zur seriellen Übertragung von Audio- und Videosignalen im Fahrzeug zu entwickeln.

Von Eugen Mayer

 Die MOST Cooperation

W

ar früher das Autoradio einziges Infotainment-Gerät, kamen im Laufe der Zeit CD- und MP3-Player, Navigationsgeräte und schließlich auch Bildschirme für die Wiedergabe von Video- und DVD-Filmen hinzu. Darüber hinaus lassen Bluetooth-Freisprecheinrichtungen mit integriertem Mikrofon und iPod-Steuerung das Cockpit allmählich zum Multimedia-Center werden, über das sich alle Playlisten und Verzeichnisse eines digitalen MP3-Players direkt auf dem Fahr-

zeugdisplay anzeigen und auch starten lassen. Der ohnehin bereits umfangreiche Verkabelungsaufwand nimmt durch die weiter ansteigende Vernetzung der immer leistungsfähigeren Infotainmentgeräte kaum mehr handhabbare Ausmaße an. Glücklicherweise erkannten einige Kfz-Hersteller schon früh, welche Vorteile die Busvernetzung auch für diesen Bereich zu bieten hat. Mitte der 1990er Jahre begannen BMW und Daimler auf der Basis des von Matsushita und Philips entwickelten D2B-Bus (Digital

MOST-Gerät Audio Disk Player FBlockID = 0x31 Systemfunktionen Gerätefunktionen FktIDs FktID = 0x000 Notification FktID = 0x001

.. .

Deck-Status FktID = 0x200 Track-Position FktID = 0x202

.. .

Function Block

...

Function Function Function Function

Net Block FBlockIDs FktID = 0x000 Geräte-Info FktID = 0x001

Function

MOST Network Interface

I Bild 1. Struktur eines MOST-Gerätes, das unter anderem den Function Block „Audio Disk Player“ beherbergt. Zur Systemverwaltung sind für jedes MOSTGerät der Net Block, für jeden Function Block Systemfunktionen obligatorisch. Elektronik automotive 9.2007 1/74

Bussysteme

MOST IIII

.. .

1998 gründeten BMW, Daimler, Harman/Becker und SMSC (vormals OASIS Silicon Systems) die MOST Cooperation [1]. Inzwischen hat sich MOST als De-facto-Standard für die Übertragung von Multimediadaten im Fahrzeug etabliert; die MOST Cooperation umfasst 15 internationale Fahrzeug- und mehr als 70 Gerätehersteller. Die MOST-Spezifikation liegt seit Oktober 2006 in der Version 2.5 vor. Sie gliedert sich in die Bereiche Application, Network und Hardware. Der Bereich Application beschreibt ein logisches Gerätemodell zur transparenten Modellierung und Steuerung von verteilten Infotainment-Systemen und basiert in erster Linie auf Methoden der Objektorientierung. Weiterhin definiert er ein hierarchisches Kommunikationsmodell sowie Dienste zur Verwaltung eines Infotainment-Systems. Die Network Section beschreibt den „MOST Network Interface Controller“ und seine Dienste, das Netzwerkmanagement sowie die Handhabung des Datentransports in einem MOSTSystem. Die Hardware Section setzt sich mit der Hardware-Struktur eines MOST-Gerätes auseinander. www.elektroniknet.de

 Modellierung von Funktionen Ein MOST-Gerät gliedert sich in eine Funktions- und in eine Netzwerkebene (MOST Network Interface). Auf der Funktionsebene sind die Infotainment-Funktionen als Funktionsblöcke (Function Blocks) untergebracht. Jeder Funktionsblock wie etwa der „Audio Disk Player“ stellt dem MOSTNetzwerk einen dedizierten Satz von Funktionen (z.B. Track Position) zur Verfügung, auf die mittels Operation Types (z.B. Set zum Setzen eines Tracks, oder SetGet zum Setzen und Lesen eines Tracks) zugegriffen werden können (Bild 1). Sowohl den Funktionsblöcken als auch den von einem Funktionsblock bereitgestellten Funktionen sind Adressen (FBlockID, FktID) zugeordnet. Man kann sie, ebenso wie die Kennungen der Operation Types, dem Function Catalog entnehmen. So hat der FBlock „Audio Disk Player“ den FBlockID=0x31 – die Funktion „Track Position“ den FktID=0x202. Durch die Trennung von Funktion und Netzwerk und mit Hilfe der

HMI MOST-Kommandos System-Controller MOST-Kommandos System-Slaves

I Bild 2. Hierarchie eines MOST-Systems.

Funktionsmodellierung lässt sich ein Kommunikationsmodell realisieren, welches völlig unabhängig von physikalischen MOST-Geräten ist. Folglich spielt es keine Rolle, auf welchen MOST-Geräten man einen Funktionsblock unterbringt.

 Hierarchisches Kommunikationsmodell MOST-Systemen liegt eine dreistufige, hierarchische Steuerungsphilosophie nach dem Master-Slave-Prinzip zugrunde (Bild 2). Auf der obersten www.elektroniknet.de

Hierarchieebene ist die HMI (Human Machine Interface) angesiedelt, ein exponierter Controller, der dem Anwender den gesamten Funktionsumfang zur Verfügung stellt. Auf der mittleren Hierarchieebene befinden sich die üblichen Controller. Sie decken einen Teil der Systemfunktionen ab und stellen ihr partielles Systemwissen der HMI als System-Master zur Verfügung. Die unterste Hierarchieebene bilden die System-Slaves, deren Funktionen jeweils von einem oder mehreren Controllern nutzbar sind. Sie sind mit keinerlei Systemwissen ausgestattet, was die Flexibilität hinsichtlich der Konfiguration wesentlich erhöht. System-Slaves lassen sich einem MOSTSystem einfach hinzufügen oder entfernen. Zur Steuerkommunikation dienen MOST-Kommandos. Sie umfassen im Kern den FBlockID, den FktID, den Operation Type und bis zu 65 535 Nutzbyte.

 Systemverwaltung Die Application Section definiert auch übergeordnete Funktionsblöcke und Funktionen zur Systemverwaltung. Zu den Systemfunktionen zählt unter anderem die Funktion FktIDs (FktID= 0x000), mit der man die von einem Funktionsblock unterstützten Funktionen abfragt. Die Systemfunktion Notification (FktID=0x001) erlaubt das Erstellen der Notification-Matrix für einen Funktionsblock. Aus der Notification-Matrix geht hervor, welches MOST-Gerät zu benachrichtigen ist, wenn sich eine bestimmte Eigenschaft eines Funktionsblocks verändert hat. Dieser Mechanismus verhindert ein unnötiges Ansteigen der Buslast im MOST-System. Zur Abfrage seiner Funktionsblöcke und Adressen hat jedes MOST-Gerät den (System-)Funktionsblock Net Block mit der FBlockID=0x01. Mittels der Funktion FBlockIDs (FktID= 0x000) können die auf einem MOSTGerät implementierten Funktionsblöcke in Erfahrung gebracht werden. Über die FktIDs 0x002, 0x003 und 0x004 lassen sich die physikalische und die logische Adresse sowie die Gruppenadresse eines MOST-Gerätes ermitteln. Eine wichtige Aufgabe bei der Verwaltung eines MOST-Systems hat der

Network Master. Er ist für den Systemstart und die Verwaltung der Central Registry verantwortlich. Diese umfasst die logischen Adressen der in einem MOST-System implementierten MOST-Geräte und die Adressen der darauf untergebrachten Funktionsblöcke.

 „MOST Network Interface“ Das „MOST Network Interface“ (Bild 3) sorgt dafür, dass die auf unterschiedlichen MOST-Geräten untergebrachten Funktionsblöcke in der Lage sind, miteinander zu kommunizieren. Dabei erbringen die „MOST System Services“ („Low Level System“ und „MOST Network Services“) die Kommunikationsfunktionen, die für den Transport aller multimediarelevanten Daten (zeitkontinuierliche Bitströme, Paketdaten und Steuerdaten) notwendig sind. Die „Low Level System Services“ (Schicht-2-Dienste) sind in Hardware (Network Interface Controller; NIC) implementiert und setzen auf dem Physical Layer auf. Die „MOST Network Services“, die den Transport Layer in Form von „Basic Layer System Services“ und das höhere Management in Form eines Application Sockets umfassen, sind auf einem externen Host Controller (EHC) untergebracht und steuern den NIC. Dabei muss sichergestellt sein, dass der EHC auch die zeitkritischsten Teile des Network Interface bedienen kann. Durch die Weiterentwicklungen, von MOST25 über MOST50 zu MOST150, stößt diese Architektur inzwischen an ihre Grenzen. INIC-Architektur EHC Application Socket NIC-Architektur EHC

INIC

Application Socket Basic Layer System Services

NIC Low Level System Services

Physical Interface

Basic Layer System Services

NIC Low Level System Services

Physical Interface

I Bild 3. Unterschied zwischen der NIC- und der INIC-Architektur eines MOST-Gerätes. Elektronik automotive 9.2007 1/75

IIII MOST

MOST IIII

Boundary Descriptor Synchronous Asynchronous Data Transfer Data Transfer Stream-DataChannels

0 1 2 3 4 5 6 7 ...

Packet Channels m n

 MOST Networking Administration

Administration

Bussysteme

. . . 58 59 60 61 62 63

Source Data Area (60 byte) Control Data Channel (2 byte) MOST Frame (64 byte)

I Bild 4. Aufbau des MOST-Frames: Im AdministrationsByte 0 werden Synchronisationsinformationen und der Boundary Descriptor, im Administrations-Byte 63 werden Status-Bits und ein Paritäts-Bit zur Sicherung des MOST-Frames übertragen.

In Neuentwicklungen löst der INIC (Intelligent Network Interface Controller) den NIC ab. Während der INIC die Abwicklung der zeitkritischen Teile des Netzwerktreibers vom EHC übernimmt, läuft auf dem EHC nur noch ein relativ kleiner Teil des Netzwerktreibers, der im Wesentlichen einen Sockel für die Applikation darstellt. Die INIC-Architektur entlastet somit den EHC. Zur Steuerung stellt der INIC dem EHC bzw. der MOST API („MOST Network Services“) mit der INIC API eine Schnittstelle zur Verfügung. Die Funktionen des INIC sind durch einen Funktionsblock (FBlock INIC) gekapselt.

MOST ermöglicht die Übertragung von kontinuierlichen Bitströmen (Bitstreaming) ohne Pufferung und unnötigen Overhead. Dazu speist ein ausgewiesenes MOST-Gerät (Timing Master) den MOST-Frame (Bild 4) mit einer festen Frequenz (44,1 kHz oder 48 kHz) in das üblicherweise optische Übertragungsmedium ein. In einem MOST25-System stellt der MOST Frame 60 Streaming Channels zu je 8 bit (bzw. 15 Quadlets zu je 4 byte) zur Übertragung von kontinuierlichen Bitströmen zur Verfügung (Source Data Area). Die Übertragungsrate eines Streaming Channels ergibt sich entweder zu 352,8 kbit/s (44,1 kHz) oder zu 384 kbit/s (48 kHz). Da die MOST-Geräte physikalisch zu einem Ring zusammengeschlossen sind, muss jeder MOST-Frame jedes MOST-Gerät mit der vom Timing Master vorgegeben Frequenz passieren. Sobald sich die entsprechenden Kommunikationspartner (Datenquelle und -senke) mit denselben Streaming Channels verbunden haben, beginnt das Bitstreaming (Bild 5). Auf- und Abbau der Verbindung geschieht üblicherweise auf Anfrage

Signalübertragung mittels POF

Elektronik automotive 9.2007 1/76

dB/m 0,4 Dämpfung

Tritt ein Lichtstrahl von einem transparenten Medium in ein anderes über, so wird er gebrochen. Die Brechung ist um so stärker, je größer der Einfallswinkel ist. Das Medium, in dem der Lichtstrahl mit dem Lot den kleineren Winkel bildet, ist das optisch dichtere Medium. Beim Übergang vom optisch dichteren zum optisch dünneren Medium wird der Strahl vom Lot weg gebrochen. Der Brechungswinkel a kann berechnet werden, wenn die so genannten Brechzahlen n der beiden Medien bekannt sind (Snellius-Gesetz). Überschreitet der Lichtstrahl beim Übergang vom optisch dichteren zum optisch dünneren Medium den Einfallswinkel a0, so tritt Totalreflexion ein. Aufgrund dieser Eigenschaft kann man Licht in einem optischen Leiter transportieren. Im MOST-System setzt man üblicherweise Polymerfasern zur optischen Signalübertragung ein, deren Kern aus PMMA (Polymethylmetha-crylat) von einem dünnen Mantel aus fluoriertem Acrylat umgeben ist. PMMA hat eine größere Brechzahl als fluoriertes Polymer. Wenn der eingehende Lichtstrahl über dem Grenzwinkel

Dämpfungsfenster

0,3 0,2 0,1 450

500 550 600 Wellenlänge

650 nm

liegt, wird aufgrund der Totalreflexion das Licht im Kern geführt. Die kleinsten Dämpfungen für das Übertragen von Licht in einer Step-Index-PMMA-Fasern erhält man bei 520 nm (grün), 560 nm (gelb) und 650 nm (rot). In erster Linie werden rote LEDs verwendet (Dämpfung: 0,14 dB/m), da sie sehr kostengünstig sind

durch den Funktionsblock Connection Master (CM; FblockID=0x03). Zu diesem Zweck stellt der CM die beiden Funktionen BuildSyncConnection und RemoveSyncConnection bereit. Im Rahmen des Verbindungsaufbaus fordert der CM die entsprechende Datenquelle auf, zum Beispiel den TV-Tuner, sich die entsprechende Anzahl Streaming Channels beim Timing Master allokieren zu lassen. Denn der Timing Master ist für die Verwaltung der „Channel Resource Allocation Table“ zuständig. Die Adressen der allokierten Streaming Channels gibt der CM der Datensenke, zum Beispiel Display, weiter, damit sich diese mit den Streaming Channels verbinden kann. Zum Abschluss aktualisiert der CM die „Sync Connection Table“, über die er sämtliche synchronen Verbindungen verwaltet. Der Abbau funktioniert nach dem gleichen Schema. Um auch Datenpakete übertragen zu können, hat der Anwender die Möglichkeit, die Anzahl der Streaming Channels mittels Boundary Descriptor bis auf 24 (sechs Quadlets) zu verringern. Denn alle Streaming Channels, die nicht für das Bitstreaming reserviert sind, werden zum Packet Channel zusammengefasst. Während bei 44,1 kHz eine maximale Übertragungsrate von bis zu 12,7 Mbit/s möglich ist, erreicht man bei 48 kHz eine maximale Übertragungsrate von bis zu 13,8 Mbit/s. Verwaltet wird der Boundary Descriptor vom Funktionsblock Network Master (FBlockID= 0x02). Über die Funktion Boundary (FktId=0xA03) lässt sich dieser setzen. Zur Übertragung von Datenpaketen kommt ein Schicht-2-Protokoll zum Einsatz. Der Frame setzt sich aus dem Arbitrierungsfeld, der Quell- und Zieladresse, dem Data Length Code, dem Datenfeld (48 oder 1014 byte) und der Datensicherung zusammen. Ein im Ring zirkulierender Token regelt den Buszugriff. Jenes MOST-Gerät, welches den Token vom Ring nimmt, darf auf den Packet Channel zugreifen. Schließlich muss das MOST-System die zur Verwaltung und Steuerung notwendigen MOST-Kommandos übertragen. Dazu kommen Control Messages (Bild 6) zum Einsatz, die im Control Channel übertragen werden. Zur Übertragung einer Control Message sind 16 MOST-Frames (MOST-Block) erwww.elektroniknet.de

Timing Master

f = 48 kHz

Packet Channel à 20 byte

40 Stream Data Channels à 8 bit

40 Stream Data Channels à 8 bit

Packet Channel à 20 byte

1 2 3 . . . 40 41 42 43 . . . 60 61 62

1 2 3 . . . 40 41 42 43 . . . 60 61 62

MOST-Frame (t = 1/f)

MOST-Frame (t = 1/f)

Timing Slave

Stream Data Channel 1 - 40

1 byte

1 byte

1 byte

384 kbit/s

Packet Channel

20 byte

20 byte

20 byte

7,68 Mbit/s

Control Channel

2 byte 1/f

2 byte 1/f

2 byte 1/f

...

...

Timing Slave

768 kbit/s

MOST-Ring

Timing Slave

I Bild 5. Prinzip des Bitstreamings: Der Timing Master überträgt mit der Frequenz von 48 kHz MOST-Frames. Es stehen 40 Streaming Channels (10 Quadlets) mit je 384 kbit/s zur Allokierung bereit (Boundary Descriptor = 0xA). Der Packet Channel (20 byte) stellt für die Übertragung von Datenpaketen eine Bandbreite von 7,68 Mbit/s zur Verfügung.

forderlich. Die Übertragungsrate beträgt bei 44,1 kHz 705,6 kbit/s und bei 48 kHz 768 kbit/s. Auch der Übertragung der Control Messages liegt ein Schicht-2-Protokoll zugrunde. Der Buszugriff erfolgt mittels CSMA-Verfahren (Carrier Sense Multiple Access).

 Physical Layer Zur Übertragung der Audio- und Videosignale im MOST-System sind heute Lichtwellenleiter aus Polymerfasern (POF; polymeroptische Faser) Stand der Technik (Kasten). In der Summe sind die technischen Eigenschaften der Polymerfasern denen elektrischer Übertragungsmedien weit überlegen. Zu erwähnen ist vor allem die hervorragende elektromagnetische Störfestigkeit und die vergleichsweise hohe Signalübertragungsgeschwindig-

keit von bis zu 500 Mbit/s. Außerdem stellt die Kombination aus POF, roter Leuchtdiode als Lichtquelle und einer Silizium-PIN-Fotodiode als Empfänger eine sehr günstige und vergleichsweise einfach handhabbare Form der optischen Signalübertragung dar. Mit MOST150 geht nach MOST50 aktuell ein MOST-System an den Start, dem diese Sender- und EmpfängerTechnik zugrunde liegt und dem Anwender eine Übertragungsgeschwindigkeit von 150 Mbit/s zur Verfügung stellt. Die im Auto vergleichsweise kurzen Strecken von bis zu 20 m sind damit problemlos zu bewältigen.

Bussysteme

Cooperation und bietet Unterstützung bei Entwicklung und Analyse von Infotainment-Lösungen im Automobil. Für Anwendungen wie High-EndAudiosysteme, Multimedia-Streaming, Telefonie und Navigation gibt es eine umfassende Palette an Analyse-, Entwicklungs- und Test-Werkzeugen, Hardware-Schnittstellen, Datenlogger sowie Schulungen und Dienstleistungen [2]. Das notwendige Basiswissen rund um die Steuergerätekommunikation im Automobil vermittelt die Vector Academy [3] im Rahmen von Seminaren zu CAN, LIN, FlexRay und MOST. sj Literatur [1] www.mostcooperation.com [2] www.vector-group.net/most/de [3] www.vector-academy.de [4] Mayer, E.: Serielle Bussysteme im Automobil. Teil 1: Archtiektur, Aufgaben und Vorteile. Elektronik automotive 2007, H. 7, S. 70 – 73. [5] Mayer, E.: Datenkommunikation im Automobil. Teil 2: Sicherer Datenaustausch mit CAN. Elektronik automotive 2007, H. 8, S. 34 – 37. [6] Mayer, E.: Serielle Bussysteme im Automobil. Teil 3: Einfacher und kostengünstiger Datenaustausch mit LIN. Elektronik automotive 2008, H. 1, S. 40 – 43. [7] Mayer, E.: Serielle Bussysteme im Automobil. Teil 4: FlexRay für den Datenaustausch in sicherheitskritischen Anwendungen. Elektronik automotive 2008, H. 2, S. 42 – 45.

 Entwicklung, Test und Analyse von MOST-Systemen Die Vector Informatik GmbH ist seit 1999 assoziiertes Mitglied der MOST

Control Message (32 byte) a

b

c

d

e

f

g

h

2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte byte

... MOST Frame

MOST-Block (16 MOST Frames)

I Bild 6. Zur Übertragung einer Control Message ist ein MOST-Block erforderlich. Die Control Message setzt sich zusammen aus: Arbitrierung (a), Zieladresse (b), Quelladresse (c), Message Typ (d), Datenfeld (e), Datensicherung (f), Bestätigung (g) und Reservierung (h). www.elektroniknet.de

Dipl.-Ing., Dipl.-Techpaed. Eugen Mayer hat nach der Berufsausbildung zum Kommunikationselektroniker an der FH Ravensburg/Weingarten Elektronik und an der Universität Stuttgart Elektrotechnik und Berufspädagogik studiert. Er arbeitet seit 1999 bei der Vector Informatik und ist dort als Senior Trainer tätig.

Elektronik automotive 9.2007 1/77

Gegensatz zu RS232 erlaubt K-Line wie ein Bussystem die

Skalierbare K-Line-Lösungen

Kommunikation mit verschiedenen Steuergeräten, indem

Zum Testen und Simulieren von K-Line-Entwicklungen bie­

es diese adressiert. Die Standardübertragungsrate beträgt

tet Vector Informatik ein Portfolio aufeinander abgestimm­

10.400 Baud, daneben kommen für besondere Anwen­

ter K-Line-Komponenten an, bestehend aus hochwertiger

dungsfälle, wie zum Beispiel dem Programmieren von

Schnittstellen-Hardware und leistungsfähigen Software-­

Flash-Speichern, auch Geschwindigkeiten bis 115,2 KBaud

Werkzeugen. Die Lösungen decken alle denkbaren Anforde­

zum Einsatz.

rungen ab und sind flexibel skalierbar vom einkanaligen

K-Line eignet sich sowohl für On-Board- als auch für Off-­

K-Line-Monitoring-Werkzeug über die Möglichkeit zum

Board-Diagnosen und bietet zwei spezielle Initialisierungs­

­Simulieren von K-Line-Diagnosetestern und -Steuergeräten

muster: Das Fast-Init arbeitet mit dem Standard von

bis hin zum großen HiL-System. Letzteres zeichnet sich un­

10.400 Baud und sendet ein Wake-up-Muster. Daneben

ter anderem durch Echtzeiteigenschaften aus und ist in der

gibt es das sogenannte 5-Baud-Init-Muster, wobei das

Lage für die Testläufe vielkanalige Steuergeräteumgebun­

System ein Adress-Byte mit fünf Baud sendet und die ­

gen zu simulieren, wobei neben K-Line auch andere Bussys­

­Empfänger diese langsame Übertragungsrate detektieren.

teme wie CAN, LIN und FlexRay integrierbar sind. Für die

Charakteristisch für K-Line sind außerdem spezielle Key-­

Verbindung zu K-Line sind diverse Schnittstellenfamilien

Bytes zum Kennzeichnen von Header-Formaten und Timing-­

mit USB-Schnittstelle oder PCI-Bus von Vector lieferbar.

Parametern.

Dazu gehören die Interface-Familien VN1600 und VN8900

Um weltweit alle K-Line-Fahrzeuge zu warten, besteht eine

sowie als Steckkarten die Vertreter VN7570 und das

wichtige Aufgabe der Fahrzeughersteller im After-Sales-­

VT6204 für das VT System. Die Übertragung auf der physi­

Markt darin, den Werkstätten geeignete K-Line-Testgeräte

kalischen Ebene übernimmt der LIN-Transceiver 7269, der

zur Verfügung zu stellen. In der Steuergeräteentwicklung

für optimale K-Line-Unterstützung sorgt (Bild 1).

hingegen werden neue Funktionen bereitgestellt, die ge­

K-Line: Flexible Lösungen für ein klassisches Protokoll

Unterstützung proprietärer K-Line-Varianten und

lieferer zum Testen ihrer K-Line-Test- und -Steuergeräte

­Byte-Protokolle

selbst leistungsfähige Hard- und Software-Werkzeuge, die

Als Software stehen von Vector die Werkzeuge CANoe und

das K-Line-Protokoll unterstützen.

CANalyzer zur Auswahl. Während CANoe die universelle Lösung für (automatisierbare) Tests und Simulationen dar­

Vom genauen Monitoring bis zur Datenmanipulation für generische Byte-Protokolle

Erhöhte Anforderungen der Test-Hardware

stellt, liegt beim CANalyzer der Fokus auf Analyse- und

Als ehemaliger langjähriger Standard für Diagnoseaufgaben in diversen Fahrzeugen ist das Diagnoseprotokoll K-Line auch

Grundvoraussetzung für jeden Diagnose- und Testprozess

­Monitoring-Aufgaben (Bild 2). Diese Werkzeuge gestatten

ist zunächst eine geeignete Schnittstellen-Hardware, die

den Zugriff auf sämtliche K-Line-Parameter und Einstel­

die Verbindung vom Diagnose-PC zum zu testenden Gerät

lungen. Das Testpersonal kann die Tests, Messungen und

herstellt. Zum Testen von K-Line-Geräten ist es möglich die

Fehlereinstreuungen auf verschiedenen Ebenen durchfüh­

gewöhnliche UART/RS232-Schnittstelle eines PCs zu ver­

ren: auf der Diagnose- und Kommunikationsebene sowie –

wenden, das stößt aber schnell an Grenzen. Hier fehlen die

als Besonderheit – auch auf Byte-Ebene. Dadurch sind diese

weitergehenden Eigenschaften, die man zum Prüfen auf

Werkzeuge auch bei proprietären, vom Standard abwei­

heute noch vielfach im Einsatz. Das Alter der Schnittstelle schließt es allerdings nicht aus, für aktuelle Diagnosen, Entwicklungen und Servicearbeiten moderne Hard- und Software einzusetzen. Denn die Anforderungen fallen ganz unterschiedlich aus. Sie reichen von der einfachen Kommunikation mit dem Steuergerät über die Unterstützung proprietärer K-Line-Varianten auf Byte-Ebene bis hin zu Simulationen kompletter K-Line-Diagnosetester und K-Line-Steuergeräte.

Einerseits spielt das Diagnoseprotokoll K-Line bei Neuent­

etliche europäische Entwicklungen von damals baute (und

Konformität und Verifizieren der korrekten Funktionalität

chenden K-Line-Varianten und generischen seriellen Byte-­

wicklungen keine nennenswerte Rolle mehr, denn längst

baut) man in Asien in Lizenz nach, wodurch diese dort viele

benötigt. Dazu gehört unter anderem auch das Wissen, wie

Pro­tokollen einsetzbar. Trace- und Analyse-Fenster stellen

­haben Systeme wie CAN und Ethernet die betreffenden

Jahre länger produziert wurden als bei uns. Weiterhin ist es

nahe ein Prüfling an den Grenzen der Spezifikation arbeitet

hochgenaue Timings, Baudraten, Header Bytes, Nutzdaten,

Diagnoseaufgaben übernommen. Andererseits kommen ­

gängige Praxis – vor allem in Anwendungsbereichen mit

oder anders ausgedrückt, wie groß seine Funktionsreserven

weltweit die Fahrzeughersteller, Zulieferer und Werkstät­

kleineren Stückzahlen – bewährte Steuergeräteentwick­

sind.

ten nicht an der Tatsache vorbei, dass viele Fahrzeuge

lungen in nachfolgenden oder verwandten Produktlinien

Effiziente K-Line-Schnittstellen erlauben es, im Gegensatz

­beziehungsweise Steuergeräte die K-Line-Technologie ver­

weiterzuverwenden; auch dies verlängert die Lebensdauer

zu RS232-Lösungen, Kommunikations-Timings exakt zu

wenden und dies noch eine gewisse Zeit so bleiben wird.

von K-Line.

­erfassen. Sowohl gesendete als auch empfangene K-Line-­

Steuergeräte mit K-Line-Schnittstelle finden sich unter

1/78

prüft werden müssen. Daher benötigen Hersteller und Zu­

Frames werden mit exakten Zeitstempeln versehen. Wei­

anderem im Bereich von PKWs, im LKW-Sektor und in ­

Serielles UART-Diagnoseprotokoll mit Bus-Charakteristik

terhin werden automatisch die Baud-Raten einschließlich

Zweirädern.

Bei K-Line handelt es sich um ein nach ISO 14230 standar­

der Muster von Fast-Initialisierungen und 5-Baud-Initiali­

disiertes Diagnoseprotokoll. Wie die serielle Standard­

sierungen erkannt, Manipulationen von K-Line-Timings-

Totgeglaubte leben länger

schnittstelle RS232 basiert es auf der Technik typischer

und -Daten sowie das Senden von Raw-Byte-Streams ist

Insbesondere in Märkten wie China, Indien und Südostasien

UART-Schaltungen

ebenso möglich. Über USB lassen sie sich an jeden PC an­

sind Millionen von PKWs und Zweiräder mit K-Line-Techno­

Transmitter). Bei der asynchronen Übertragung dienen

binden und arbeiten idealerweise eng mit den Software-­

logie auf den Straßen unterwegs. Dabei handelt es sich in

Start- und Stopp-Bits zur Synchronisation von Sender und

Werkzeugen zusammen, zum Beispiel über eine speziali­

der Regel um Fahrzeuge, deren technischer Stand sich auf

Empfänger. Das System benötigt somit keine zusätzliche

sierte K-Line-API, die in Test-Skripts einen einfachen Zugriff

dem Niveau von vor etwa 10 bis 15 Jahren befindet. Auch

Taktleitung und kommt mit einer Eindrahtleitung aus. Im

auf alle Hardware-Funktionen erlaubt.

(Universal

Asynchronous

Receiver

Bild 1: Unterschiedliche K-Line-Interfaces: vom einkanaligen USB-Interface bis hin zum HiL-Modul

1/79

K-Line: Flexible Lösungen für ein klassisches Protokoll

Fazit Auch für das deutlich in die Jahre gekommene K-Line-Pro­ tokoll stehen leistungsfähige und moderne Werkzeuge be­ reit, etwa zur Pflege von Diagnosetestern und Steuergerä­ ten. Sie gestatten Fahrzeugherstellern und Zulieferern nicht nur qualifizierte Tests auf hohem Niveau, sondern ermögli­ chen auch eine problemlose Weiterentwicklung beziehungs­ weise Weiterverwendung bestehender K-Line-­Kom­po­nenten. Deutsche Übersetzung der Online-Veröffentlichung in ­Automotive EE Times Europe, Mai 2015. Bildrechte: Alle Bilder Vector Informatik GmbH Peter Decker ist seit 2002 bei Vector Informatik und arbeitet als Product Manager in der Produktlinie Networks and Distributed Systems.

Bild 2: K-Line Test- und ­Simulationsumgebung

Inter-Byte- und Inter-Frame-Spaces dar (Bild 3). Andere

mulationen lassen sich ebenfalls über CAPL in Verbindung

Fenster erlauben das interaktive Senden von K-Line-Frames.

mit der speziellen K-Line-API erstellen. Testmodule sorgen

Über die Anwendungsprogrammiersprache CAPL können

anschließend für automatische Testabläufe und Report­

Raw-Frames versendet und Fehler eingestreut werden. Si­

erstellungen.

Bild 3: K-Line Analyse auf verschiedenen Kommunikationsebenen

1/80

1/81

TITELTHEMA FUNK TIONAL E SICHERHEIT

AUTOREN

DIPL.-ING. NICO ADLER arbeitet als wissenschaftlicher Mitarbeiter im Forschungsbereich Embedded Systems and Sensors Engineering am FZI Forschungszentrum Informatik in Karlsruhe.

DR. EDUARD METZKER ist Senior Produkt-ManagementIngenieur für Systems-EngineeringWerkzeuge bei der Vector Informatik GmbH in Stuttgart.

HERLEITUNG

Mit der Veröffentlichung der ISO 26262 „Road vehicles – Functional safety“ werden erstmalig eindeutige Sicherheitsvorgaben an die Automobilindustrie, deren Entwicklungsprozesse und das Produkt selbst gestellt. Die ISO 26262 stellt erhebliche Anforderungen an die Verantwortlichkeiten, Prozesse, Dokumentationen und Techniken bei der Entwicklung sicherheitsrelevanter Systeme. Hersteller müssen nicht nur einen Teil des Systems in der jeweiligen Entwicklungsphase betrachten, sondern das ganze System innerhalb des gesamten Lebenszyklus. Das System muss den geforderten Automotive Safety Integrity Level (ASIL) der Sicherheitsfunktion erreichen. Alle Komponenten (Hardware und Software), die zur Ausführung einer Sicherheitsfunktion beitragen, werden hierfür betrachtet. Um den Aufwand zu minimieren, sind entsprechende Entwicklungswerkzeuge hilfreich. FUNKTIONALE SICHERHEIT IM KONTEXT VON HARDWARE

DR. ALEXANDER RUDOLPH arbeitet als Safety Manager im Geschäftsbereich Vehicle Dynamics bei der Continental AG in Frankfurt am Main.

DESIGN UND ANALYSE FUNKTIONAL SICHERER HARDWARE IN EINEM EBS Die Erfüllung der funktionalen Sicherheit für Straßenfahrzeuge gemäß ISO 26262 geht mit umfassenden Anforderungen und Aufwand an die Entwicklung in Form von vorgeschriebenen Hardware-Sicherheitsevaluationen sowie spezifischen Nachweisdokumenten einher. Continental, das FZI Forschungszentrum Informatik in Karlsruhe und Vector beschreiben eine effiziente Methodik, die einen iterativen Design- und Analyseprozess unterstützt und in das modellbasierte Systems-Engineering-Werkzeug PREEvision integriert wurde. Neben der prinzipiellen Vorstellung der Methodik und der Werkzeugunterstützung auf Basis der ISO 26262 wird eine konkrete Anwendung im Rahmen der Sicherheitsbetrachtungen eines neuentwickelten elektronischen Bremssystems (EBS) erläutert.

24

2/0

06I2014

9. Jahrgang

Die innerhalb der ISO 26262 [1] geforderten Aktivitäten und Arbeitsprodukte sind umfangreich und trotz des sehr gut strukturierten und aufbereiteten Standards oftmals schwer in bestehende Prozesse und Toolketten einzubringen [2]. Für die Produktentwicklung auf Hardware-Ebene nach Teil 5 beschreibt der Standard zwei unterschiedliche Designphasen: Das Hardware-Architekturdesign, bestehend aus Hardware-Komponenten, beschreibt eine abstrahierte und funktionale Sicht auf ein vorläufiges Hardware-Design. Das detaillierte Hardware-Design hingegen ist aus HardwareBauteilen zusammengesetzt und repräsentiert eine Detaillierung der HardwareKomponenten auf Ebene von elektronischen Schaltplänen. Im Folgenden sprechen wir vereinfacht von HardwareDesigns und -Elementen. Geforderte Sicherheitsbetrachtungen in Bezug auf die Untersuchung von zufälligen Fehlern der Hardware basieren auf statistischen Fehlerinformationen und sind in Teil 5 Abschnitt 8 für die „Evaluation of the hardware architectural metrics“ beschrieben. Diese Evaluation setzt sich wiederum aus der „Single-point fault metric“ sowie der „Latent-fault metric“ zusammen und ermöglicht eine

Aussage über die Robustheit des Hardware-Designs. Komplementär wird in Abschnitt 9 auf die „Evaluation of safety goal violations due to random hardware failures“ eingegangen, welche probabilistische Sicherheitsanalysen repräsentieren. Zwei unterschiedliche Evaluationen können hier angewandt werden: „Evaluation of Probabilistic Metric for random Hardware Failures (PMHF)“, welche eine globale Untersuchung des Designs erfordert, sowie die „Evaluation of each cause of safety goal violation“, welche häufig als FRC-Methode bezeichnet wird und eine individuelle Einstufung der einzelnen Hardware-Elemente darstellt. VORGEHENSWEISE FÜR HARDWARE-SICHERHEITSEVALUATIONEN

Um die geforderten Hardware-Sicherheitsevaluationen nach ISO 26262 in iterativen und kollaborativen Entwicklungen zu unterstützen, sind modellbasierte Entwicklungsumgebungen prädestiniert. Hierzu werden auf spezifischen Bibliotheken basierende Hardware-Designs mit hinterlegten Fehlerinformationen modelliert. Mit den Modellinformationen können anschließend die geforderten Sicherheitsevaluationen datenbankgestützt und mit deutlich geringerem Aufwand ausgeführt werden [3]. Eine sich aktualisierende Darstellung der berechneten Evaluationsergebnisse unterstützt die iterative Vorgehensweise zu unterschiedlichen Entwicklungsphasen. Dies vereinfacht zielgerichtete Designänderungen. Hierbei unterstützen zugeschnittene und durchdachte Bedienkonzepte den Ingenieur. Zudem reduzieren automatisch generierbare Reportdokumente den Dokumentationsaufwand. FEHLERBIBLIOTHEK

Statistische Informationen zu Fehlern von Hardware-Elementen wie Ausfallraten, Ausfallarten und Fehlerverteilung auf die Ausfallarten werden in einer Fehlerbibliothek verwaltet. Die Fehlerbibliothek speist sich typischerweise aus Standardwerken wie die Siemens Norm SN 29500 und kann problemlos um Erfahrungswerte aus firmeneigenen Datenbanken erweitert werden. Einmal eingepflegte Fehlerinformationen können übergreifend in unterschiedlichen Hardware-Designs verschiedener Teams wiederverwendet werden.

25

2/1

TITELTHEMA FUNK TIONAL E SICHERHEIT

Auszugsweise Darstellung der Fehlerdatentabelle mit den Ergebnissen der „Hardware Architectural Metrics“ sowie der FRC-Methode

Die Fehlerdatentabelle nach ISO 26262 enthält die zu untersuchenden Sicherheitsziele, die sicherheitsbezogenen Einstufungen sowie die in der Bibliothek annotierten Fehlerinformationen. Informationen zu einer potenziellen direkten Verletzung des Sicherheitsziels als auch einer potenziellen Verletzung in Kombination mit anderen unabhängigen Fehlern sind dargestellt. Die Klassifizierung der Ausfallarten im Kontext des Sicherheitsziels kann über ein Auswahlmenü direkt im Editor oder automatisiert über

eine qualitative Fehlerbaumanalyse (FTA) erfolgen. Die „Evaluation of the hardware architectural metrics“ wird für ein oder mehrere Sicherheitsziele ausgeführt. Für die „Evaluation of each cause of safety goal violation“ auf Ebene des HardwareElements wird eine Einstufung in Ausfallraten-Klassen, sowie ein spezifischer Diagnose-Abdeckungsgrad mit einbezogen. Zielwerte werden aus dem ASIL der Sicherheitsziele abgeleitet und deren Erfüllung grafisch hervorgehoben 1
(b).

Die Evaluation einer PMHF wird durch eine qualitative und quantitative Fehlerbaumanalyse unterstützt. Hierfür wird die Berechnung einer Wahrscheinlichkeit als Worst-CaseAbschätzung für den Eintritt des Hauptereignisses im Fehlerbaum als Verletzung des zu bewertenden Sicherheitsziels bereitgestellt. Die Gewinnung von mittleren Wahrscheinlichkeiten (Fussnote: Numerisch entspricht dies der „Conditional failure intensity“, also der Fehlerwahrscheinlichkeit zum Zeit-

 Modellierung des Hardwaredesigns auf unterschiedlichen Abstraktionsebenen

DURCHGÄNGIGE MODELLIERUNG

Zunächst werden Sicherheitsziele mit assoziiertem „Automotive safety integrity level“ (ASIL) aus einer vorhergehenden Gefahren- und Risikoanalyse (HARA) des Gesamtsystems abgeleitet und in der Anforderungsebene hinterlegt. Eine Verfeinerung erfolgt mittels funktionalen und technischen Sicherheitsanforderungen, welche iterativ nachgepflegt werden können. Weiterhin erforderlich ist die Definition von Sicherheitsmechanismen mit den spezifischen Werten für den DiagnoseAbdeckungsgrad in Bezug auf Restfehler und latente Fehler. Für die Modellierung des Hardware-Designs kann das funktionale und das technische Sicherheitskon-

26

2/2

zept in Form des Hardware-Architekturdesigns  (a) sowie des detaillierten Hardware-Designs
0
(b) umgesetzt werden. Die in der Bibliothek hinterlegten Hardware-Elemente einschließlich der statistischen Fehlerinformationen können direkt in das entsprechende Diagramm übernommen werden 0 (c). NACHVOLLZIEHBARKEIT UND DESIGNOPTIMIERUNG

Da die Fehlerinformationen der Hardware-Elemente aus der Fehlerbibliothek übernommen werden sind konsistente und nachvollziehbare Ergebnisse sichergestellt
(a). Der Ingenieur wird von der Pflege der Daten entlastet und kann sich

auf die Analyse und Optimierung des Designs im Sinne der funktionalen Sicherheit konzentrieren. Somit können die Auswirkungen von neu eingeführten Sicherheitsmechanismen oder weiteren Hardware-Elementen auf die Evaluationen analysiert werden. HARDWARE-SICHERHEITSEVALUATIONEN

Für die modellbasierte Durchführung der Sicherheitsevaluationen stehen mehrere Editoren zur Verfügung. Mit diesen lassen sich die Evaluationsergebnisse strukturiert und aufbereitet darstellen während sie unterschiedliche Sichten auf die Evaluationen bieten.

Auszug des Systemelements Spannungsversorgung aus dem elektronischen Bremssystem 06I2014

9. Jahrgang

27

2/3

TITELTHEMA FUNK TIONAL E SICHERHEIT

Durch die Anwendung der integrierten Konzepte konnte der in  (a) dargestellte Fehlerbaum erarbeitet werden. Der Eintritt des Top-Ereignisses liegt vor, wenn „Unentdeckter Ausfall von VP2“, „Ausfall von VP2 bei ausgefallener Redundanz (VP1 oder Umschalter ALT)“ oder „Ausfall der Redundanz (VP1 oder Umschalter ALT) im Notlauf“ vorliegt. Durch die Minimalschnitt-Auswertung konnten die Budgets für die Eintrittswahrscheinlichkeiten der einzelnen Minimalschnitte vergeben und die in 3 (b) ersichtlichen Sicherheitsanforderungen (funktional und technisch) beziehungsweise Entwurfseinschränkungen abgeleitet werden. Bei Mehrfach-Fehlern (Minimalschnitt-Tiefe größer 1) können so die zulässigen Budgets der Einzelfehler ermittelt und die Degradierungs- und Notlaufeigenschaften (maximale Dauer und Bewarnungskonzept) spezifiziert werden, 3 (c).

[2] Adler, N.; Otten, S.; Schwär, M.; Müller-Glaser, K.: Managing Functional Safety Processes for Automotive E/E Architectures in Integrated Model-Based Development Environments. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(1), S. 103-114, doi:10.4271/2014-01-0208 (2014) [3] Adler, N.; Otten, S.; Cuenot, P.; Müller-Glaser, K.: Performing Safety Evaluation on Detailed Hardware Level according to ISO 26262. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 6(1): S. 102-113, doi:10.4271/2013-01-0182 (2013)

FA ZIT

 Fehlerbaum und abgeleitete Sicherheitsanforderungen sowie Entwurfseinschränkungen

punkt T unter der Bedingung der Fehlerfreiheit zum Zeitpunkt T0. Als Worst-case kann die Systemlebenszeit als T-T0 = Lifetime angesetzt werden.) aus den Ausfallraten wird über eine anpassbare Latenzzeit T vorgenommen. Zusätzlich ermöglicht die qualitative Analyse des Fehlerbaums mittels Minimalschnitten die Definition von Entwurfseinschränkungen. REPORTS

Für den Sicherheitsnachweis können Review-Reports während der Designphase und Dokumente zum Erbringen der Argumentation im Sinne des „Safety case“ nach Finalisierung des HardwareDesigns erstellt werden. Diese sind für

28

2/4

eine mögliche Zertifizierung der Hardware einsetzbar. Die Nachweisdokumente sind zu jeder Zeit der Entwicklung automatisiert erstellbar und liefern ein Abbild des aktuellen Status der Hardware-Sicherheit des Systems. EBS ALS BEISPIEL-SZENARIO

In diesem Beispiel geht es um die Sicherheitsbewertung für ein sich in der Entwicklung befindliches elektronisches Bremssystem aus dem Bereich Brake-byWire (BBW). Aus Darstellungsgründen ist die Betrachtung auf die redundant ausgelegte Spannungsversorgung des EBS beschränkt, . Hierbei standen unter anderem die Schnittstellen zwischen

Anforderungen, Architektur, Design und deren Ableitung mit deduktiven Sicherheitsanalysen im Fokus. Aus der HARA konnte das Sicherheitsziel SAF_REQ_1 „Die mittlere Wahrscheinlichkeit des Verlusts der BBW-Hilfsenergie soll kleiner sein als 3e-09/h“ abgeleitet werden. Das funktionale Konzept sieht hierbei vor, dass die Spannungsversorgung für das benachbarte Systemelement BBWAktuator primär über die externe Klemme KL30_2 versorgt wird. Im Bedarfsfall kann über den Umschalter ALT auf die sekundäre Spannungsversorgung VP1 umgeschaltet werden. Diese wird verfügbarkeitserhöhend als kalte Redundanz eingesetzt und als Notlauf zugeschaltet.

Sämtliche in der ISO 26262 geforderten Hardware-Sicherheitsevaluationen werden vollständig in einer integrierten Lösung unterstützt. Damit sind Mehrarbeit und Fehlerquellen durch inkonsistente Datenquellen sowie Werkzeugwechsel und -brüche ausgeschlossen. Der Bibliotheksansatz entlastet Ingenieure bei Entwurf bzw. Analyse und ermöglicht einen hohen Grad von Wiederverwendung. Auswirkungen von Hardware-Entwurfsänderungen oder Einführung von Sicherheitsmechanismen sind sofort in den Analyseergebnissen sichtbar. Dadurch verkürzen sich die Optimierungszyklen drastisch. Dank der Kollaborationsunterstützung können verteilte Teams den Entwurf und die Analysen gemeinsam vorantreiben sowie Änderungen schneller und sicherer umsetzen. Die modellbasierte Verknüpfung der Hardware-Sicherheitsevaluationen mit anderen Arbeitsprodukten der ISO 26262 ist möglich und wünschenswert. Dies ermöglicht automatisierte Prüfungen der Arbeitsergebnisse auf formale Vollständigkeit und Konsistenz sowie automatisierte Reports bis hin zum Sicherheitsnachweis.

DANKE Besonderer Dank gilt den weiteren Autoren dieses Artikels: Prof. Dr.-Ing. Klaus D. MüllerGlaser und Stefan Otten. Klaus D. Müller-Glaser ist Leiter des Instituts für Technik und Informationsverarbeitung (ITIV) in Karlsruhe, und Stefan Otten arbeitet als wissenschaftlicher Mitarbeiter im Forschungsbereich Embedded Systems and Sensors Engineering am FZI Forschungszentrum Informatik in Karlsruhe.

DOWNLOAD DES BEITRAGS

www.springerprofessional.de/ATZelektronik LITERATURHINWEISE [1] International Organization for Standardization, ISO 26262 Standard, Road vehicles – Functional safety (2011)

06I2014

READ THE ENGLISH E-MAGAZINE

order your test issue now: [email protected]

9. Jahrgang

2/5

Common to Architectures 1 + 2 150% Architecture 100% Architecture 2 100% Architecture 1

Common to Architectures 2 + 3 Common to Architectures 1 + 3 100% Architecture 3 Bild 1: Das 150% Modell und abgeleitete 100% Architekturen

Common to all Architectures

Von der Definition neuer Features bis in die Werkstatt: Nutzung von Entwicklungsdaten bei der Wartung Die Automobilindustrie sieht sich mit hoch entwickelten, anspruchsvollen Märkten und zunehmend strengeren gesetzlichen Vorschriften konfrontiert. Das erfordert einerseits komplexere Systeme, andererseits bieten diese Systeme das Potenzial für effiziente und gleichzeitig sicherere Fahrzeuge. Im Fehlerfall erschweren allerdings die komplexen Wechselwirkungen zwischen den zugrunde liegenden Systemen die Fehlersuche.

Idealerweise werden Anforderungen für die Wartung kom-

architektur erstellt, sei es als eine Variante einer vorhande-

plexer Systeme für den Service vor Ort am besten mit einer

nen Plattform oder als komplett neues Modell. Am Anfang

Wissensdatenbank erfüllt. Werkstätten, die mit solchen

eines Designprozesses steht eine Liste mit Funktionen und

Wissensdatenbanken arbeiten, sind allerdings in der ersten

Eigenschaften (Feature-Liste), die von der neuen Plattform

Zeit nach Einführung eines neuen Fahrzeugmodells auf-

erfüllt werden sollen.

grund des fehlenden Informationsgehalts nicht optimal auf-

In der Regel ist eine Feature-Liste nach Fahrzeugmodellen

gestellt. Denn gerade in dieser Frühphase ist tiefergehendes

oder -varianten aufgeschlüsselt. Ergänzt wird sie durch

Know-how für die Identifizierung und Lösung komplexer Pro-

eine Anforderungsliste für den Fahrzeugauslieferungszu-

blemstellungen gefragt, die weder während der Entwicklung

stand. Diese enthält für jede Modellvariante Begrenzun-

und Zulassung noch bei den Testfahrten aufgefallen sind.

gen, Verfeinerungen und Spezifikationen unter Berücksich-

Mit der Wiederverwendung frühzeitiger Entwicklungsda-

tigung der Vorgaben des Marktes, des Unternehmens und

ten zeigt Vector einen Weg auf, diese zusätzlichen Informa-

des Gesetzgebers. So entsteht für jede Modellvariante eine

tionen in der kritischen Modelleinführungsphase dem tech-

eigene Feature-Liste.

nischen Wartungspersonal vor Ort verfügbar zu machen.

Anschließend muss der Systementwickler die Feature-Lis-

spruch zu ihr stehen. Aus diesem Grund geht man von

Beschreibung der Feature-Liste als eine

einem 150-Prozent-Modell aus, von dem dann verschiedene

Funktionsarchitektur

Varianten mit einem 100-Prozent-Architekturmodell abge-

PREEvision von Vector bietet eine leistungsstarke Umge-

leitet werden. (siehe Bild 1).

bung für die Modellierung von Feature-Listen und deren

Eine 150-Prozent-Architektur lässt sich natürlich physika-

Zusammenhänge und Realisierungen sowohl in abstrakter

lisch nicht als reales Fahrzeug realisieren, das Ergebnis

Logik-Form als auch in Bezug auf die erforderliche Hard-

wäre eine Art „Coupe-Cabriolet-Kombi“ mit Benzin-/Diesel-/

und Software. Über den integrierten „Resolver“ des Tools

Hybridaggregat als Links- und Rechtslenker.

lassen sich Konflikte und Abhängigkeiten im Feature-

Also sind nicht alle Funktionalitäten kombinierbar, die Ge-

Modell automatisch auffinden.

genstand einer Feature-Liste sein können. Deshalb ist es

PREEvision beinhaltet einen hierarchischen Tabelleneditor

für die Entwicklung der Fahrzeugarchitektur entscheidend,

zur Dokumentation der Feature-Listen. Jeder Eintrag in

Abhängigkeiten und Einschränkungen einzelner Features in

der Feature-Liste wird zu einem „Modell-Artefakt“ (kurz

der 150-Prozent-Architektur zu erkennen. Die Modellierung

Artefakt) und lässt sich innerhalb des Tools vielfältig nut-

dieser Architektur erfolgt unter Festlegung von Abhängig-

zen. PREEvision beinhaltet auch einen Rich-Text Editor, mit

keiten und Einschränkungen und ermöglicht die Schaffung

dem Artefakte in der Feature-Liste dokumentiert werden

eines „Feature-Modells“.

können – z. B. mit Anwendernotizen oder mit Diagrammen, Fotos oder eingescannten Skizzen, wie in Bild 2 dargestellt.

ten der Modellvarianten zu einer einzigen umfassenden

2/6

Frühzeitige Entwicklungsdaten

Feature-Liste für das neue Fahrzeugmodell zusammenfüh-

Zu Beginn einer neuen Fahrzeugentwicklung werden große

ren. Daher muss die Gesamt-Feature-Liste so formuliert

Datenmengen mit Beschreibungen der geplanten Fahrzeug-

werden, dass die einzelnen Feature-Listen nicht im Wider-

Bild 2: Mit dem Rich Text-Editor erstellte Artefakte in einer Feature-Liste

2/7

Von der Definition neuer Features bis in die Werkstatt: Nutzung von Entwicklungsdaten bei der Wartung

Bild 5: Detaillierte logische Modellierung der Fahrzeuggeschwindigkeitsberechnung

Bild 3: Verfeinerung der Artefakte einer Feature-Liste mit Anforderungen in Textform

für viele Projekte stabil bleiben, während die technischen

entspricht quasi einer Befehlsfolgenbeschreibung). Die für

Innovationen zahlreiche Veränderungen der Soft- und Hard-

die Realisierung aller Artefakte in der 150-Prozent-Feature-

ware zwischen den einzelnen Projekten nach sich ziehen

Außerdem erlaubt PREEvision über Verknüpfungen mit

kompletten, komplexen Realität abbildet, um die Über-

Liste erforderliche, vollständige Modellierung des Netz-

können.

Anforderungen, die ganz konventionell in Textform im Rich

sichtlichkeit zu erhalten.

werks logischer Blöcke führt zu einer 150%igen „Logik-

Text-Editor erstellt wurden, eine verfeinerte und detaillier-

Wie aus den „Type“-Hinweisen in den Blöcken der Bild 5 er-

Architektur“.

Modellieren der Implementierung

tere Festlegung der Artefakte einer Feature-Liste (siehe

sichtlich, unterstützt PREEvision die Verwendung von an-

Die Verwendung der Activity Chains erlaubt auch die Unter-

Ähnlich wie beim Aufbau der logischen Architektur lassen

Bild 3).

wenderdefinierten Teilebibliotheken. Für eine effizientere

teilung in allgemein bzw. exklusiv zugängliche Feature-Be-

sich auch die Beziehungen zwischen Softwarefunktionen,

In PREEvision können die Artefakte einer Feature-Liste als

Modellierung können die Artefakte von Prototypen einfach

reiche und unterstützt die Wiederverwendung von Daten-

die bei der Implementierung der abstrakten Logik erforder-

Zusammenhänge in der logischen Architektur dokumen-

kreiert und direkt in die Datenbank eingetragen werden –

quellen und Systemausgaben. Die logische Architektur

lich sind, als Software-Artefakte modellieren. Außerdem

tiert werden, und zwar als Informationsquellen („Sense“),

ohne einen eigenen Blockeditor.

kann als eine Beschreibung von Prototypen der Artefakte in

können Zuordnungen zwischen den logischen und Soft-

Datenverarbeitung oder Entscheidungsfindung („Logical

Das Tool erlaubt das Einrichten von Zuordnungen – so ge-

der Soft- und Hardware angesehen werden, die für die Im-

warekomponenten erstellt werden, um die zwischen ihnen

Function“) und/oder Systemausgänge („Actuator“). So

nannten Mappings – zwischen logischen Artefakten, die

plementierung des Systems benötigt werden. Eine ausge-

bestehenden Beziehungen darzustellen. Auf diese Weise

könnte z. B. das Feature zur Geschwindigkeitsanzeige für

diese mit bestimmten Teilen einer Feature-Liste verbinden.

feilte logische Architektur kann über einen langen Zeitraum

wird eine 150-Prozent-Softwarearchitektur geschaffen.

den Fahrer als eine logische Sequenz modelliert werden,

Solche Zuordnungen sind bidirektional und ermöglichen

siehe Bild 4.

das automatisierte Abfragen bzw. Durchsuchen der Design-

So lässt sich ein detaillierteres Inhaltsmodell für den Block

modelle in verschiedenen Richtungen.

„Fahrzeuggeschwindigkeitslogik“ aufstellen, wie z. B. in Bild 5

Die Anzahl der logischen Block-Artefakte kann in einer

gezeigt. Es ist eine hierarchische Beschreibung der Logik

komplexen Realisierung zahlreiche Zuordnungen erforder-

möglich, die durch die verschiedenen Subsysteme des Fahr-

lich machen. Deshalb bietet PREEvision das Konzept der

zeugs realisiert wird, und zwar mit abstrakten High-Level-

Activity-Chains, das die Zuordnung von Feature-List-Ele-

Blöcken. Diese dienen dann als zusammenfassende Kurz-

menten zu deren Realisierung vereinfacht. Dieses Konzept

form für die Low-Level-Details in Diagrammen oder ande-

erlaubt die Gruppierung der zu einem bestimmten Artefakt

ren Darstellungen des Features. In PREEvision lässt sich ein

in der Feature-Liste gehörenden logischen Blöcke in einem

Design einfach durch Verwendung von Diagrammen auf-

anderen Artefakt, nämlich der Activity Chain. Damit kann

bauen. Dabei ist jedoch zu beachten, dass ein Diagramm in

mit einer einzelnen Zuordnung, die zwischen dem Feature

einem PREEvision-Designmodell nur einen Ausschnitt der

und seiner entsprechenden Activity Chain kreiert wurde,

Bild 4: High-Level-Modellierung einer Logik-Anforderung (Geschwindigkeitsanzeige)

2/8

alle relevante Logik impliziert werden (die Activity Chain

Bild 6: Hardwaretopologie-Modell mit Softwarezuordnungen

2/9

Von der Definition neuer Features bis in die Werkstatt: Nutzung von Entwicklungsdaten bei der Wartung

Als Nächstes kann eine 150-Prozent-Hardwaretopologie

gewünschte aus- oder einschließende Beziehungen zwi-

automatisch analysieren kann, um das bestmögliche Rou-

Wartungsrelevante Informationen

erstellt werden, um die Verbindungen zwischen der im

schen Artefakten festlegen z. B. Xenon-Scheinwerfer und

ting, auch für Kommunikationsbussysteme (oder Subbus-

Auch wenn Funktionsarchitektur und Kommunikationsstruk-

Fahrzeug eingesetzten Hardware darzustellen. Hierbei kann

Glühlampen-Scheinwerfer schließen sich gegenseitig aus.

systeme), sowie die optimalen Punkte für die Lokalisierung

tur die Grundlage für zahlreiche weitere Aktivitäten im Pro-

es sich etwa um eine konventionelle Verdrahtung oder

Außerdem kann der Inhalt jeder gewünschten Modellvari-

von Interbus-Gateways zu ermitteln. Dieser automatisier-

duktentwicklungsprozess darstellen, sind die im PREEvision-

Kommunikationsbusse handeln. Eine detaillierte Modellie-

ante in Bezug auf die Artefakte der Feature-Liste angege-

te Routing-Algorithmus optimiert die Funktionsarchitektur

Modell definierten und bisher beschriebenen Beziehungen

rung bis hin zum einzelnen Kabel und Stecker ist zwar mög-

ben werden. Der automatisierte Resolver-Mechanismus von

indem er Signale entfernt, die aus einem gegebenen Hard-

auch noch nützlich, wenn die Entwicklung eines bestimm-

lich, wird hier jedoch nicht weiter behandelt. Zur entspre-

PREEvision ist dann in der Lage, Unvereinbarkeiten in der

ware-Artefakt nicht herausgeführt werden müssen. Wenn

ten Fahrzeugs abgeschlossen und seine Serienfertigung

chenden Hardware können etwa Sensoren, Steuergeräte

Feature-Liste anhand einer Überprüfung der Zuordnungen

beispielsweise die Quelle und der alleinige Konsument eines

aufgenommen wurde bzw. die Wartung des Fahrzeugs an-

(Electronic Control Units, ECUs), Sicherungs-/Relaisboxen

im Modell zu ermitteln und so den tatsächlichen Inhalt der

Datenelements derselben ECU in der Funktionsarchitektur

steht. Beispielsweise lassen sich alle logischen Blöcke einer

und Aktuatoren gehören. Wiederum sind Zuordnungen zwi-

gewünschten 100-Prozent-Architekturen zu definieren.

zugeordnet sind, ist keine Signalerstellung erforderlich.

Activity Chain, die die Umsetzung eines bestimmten Arte-

Nach dem Signalrouting kann jeder Signalpfad in der Archi-

fakts in der Feature-Liste darstellt, finden, in dem das

schen den software- und hardwarebezogenen Block-Artefakten möglich. Die Zuordnungen der Software zur Hard-

Definieren einer Kommunikationsstruktur

tektur einfach durch entsprechende Auswahl visualisiert

Modell mithilfe eines automatisierten, in PREEvision integ-

ware lassen sich in Diagrammen in Form von „Hinweisen“

Sobald die Entwicklung eines Modells die hier beschriebene

werden. Hierdurch werden dann die Zuordnungsstellen der

rierten Abfragemechanismus durchsucht wird. Die durch

darstellen, siehe Bild 6.

Stufe erreicht hat und etwaige Unvereinbarkeiten in den

Quelle (in Gelb) und Konsumenten (in Hellbraun) des zuge-

eine solche Abfrage gewonnenen Informationen können

Sowohl in der logischen als auch in der Software-Architek-

Feature-Listen ausgeräumt wurden, kann die logische und

hörigen Datenelements zusammen mit dem Pfad markiert,

daher hilfreiche Hinweise bieten, wenn ein Außendienst-

tur können die Datentypen angezeigt werden, die für jedes

die Software-Architektur in Verbindung mit der Hardware-

der zwischen diesen und den durchlaufenen Gateways (in

techniker mit einem Fehler in einem neuen, komplexen Sys-

zwischen Artefakten übertragene Datenelement gelten.

topologie als Funktionsarchitektur angesehen werden. Die

Orange) genutzt wurde (siehe Bild 7).

tem ohne zugehörige Wissensdatenbank konfrontiert wird.

Diese Definition kann entsprechend der AUTOSAR-Anforde-

logische oder Software-Architektur definiert dabei einen

Nach dem Routing des Datenflusses in der Funktionsarchi-

Den logischen und Software-Architekturen können Defini-

rungen erfolgen, und sobald die Modellierung der Architek-

Datenfluss, während die Hardwaretopologie das potenziel-

tektur stellt PREEvision eine integrierte Netzwerk-Design-

tionen zu deren normalen (funktionalen) Kommunikations-

tur abgeschlossen ist (einschließlich der Kommunikations-

le Routing für den Datenfluss festlegt.

umgebung bereit, damit Signale Protokoll-Dateneinheiten

anforderungen hinzugefügt werden. Ebenso lässt sich auch

struktur), kann eine AUTOSAR Systembeschreibungs-Datei

Das korrekte Routing des Datenflusses in einer gegebenen

(Protocol Data Units, PDUs) zugewiesen werden können.

die Funktionsarchitektur als Ganzes mit Definitionen diag-

zur Verwendung in den nachgelagerten Produktentwick-

100-Prozent-Architektur kann sich im Falle eines manuell

Den PDUs können wiederum Frames und Frames Schedules

nostischer Anforderungen versehen.

lungsvorgängen exportiert werden.

durchgeführten Prozesses als Problem erweisen. PREEvision

gemäß den Bustypen zugeordnet werden, über die das

An diesem Punkt ist das Designmodell so weit fertigge-

bietet jedoch einen Signalrouting-Mechanismus, der den de-

Signal in der Architektur übertragen werden muss. So ent-

Aufbau einer Diagnosearchitektur

stellt, dass Bedingungen hinzugefügt werden können, die

finierten Datenfluss im Hinblick auf die Hardwaretopologie

steht letztendlich eine Kommunikationsstruktur für die Ar-

In der ersten Stufe kann man einen als „Fehlfunktion“ be-

chitektur. Bei realisierter Kommunikationsstruktur liefert

zeichneten Artefakttyp erstellen und diesen Teilen der

PREEvision nicht nur eine AUTOSAR-basierte Exportfunk-

Funktionsarchitektur zuordnen, um die übergeordnete Dia-

tion, sondern ermöglicht auch den Export von LDF-, DBC-

gnoseanforderungen abzudecken. Diese können aus allge-

und FIBEX-Dateien.

meinen Unternehmensanforderungen oder einer detaillier-

Bild 7: Hardwaretopologie mit Signalrouting für Fahrzeuggeschwindigkeit – Schlüssel im Haupttext

2/10

Bild 8: Logischen Sensoren zugeordnete allgemeine Fehlfunktionen

2/11

Von der Definition neuer Features bis in die Werkstatt: Nutzung von Entwicklungsdaten bei der Wartung

– Signal-/leistungsbezogene Fehlfunktion – z. B. durch Verlassen des zulässigen Bereichs > Aktuatoren können eine Art von Fehlfunktionen

rektional mit der Diagnosearchitektur verknüpfen, siehe

Funktion gefunden werden, sondern es ist ebenfalls mög-

Bild 10.

lich, Fehler (DTCs), die u. U. Funktionen beeinträchtigen,

Darüber hinaus lassen sich Fehlfunktions-Artefakte auch

über eine einzige Informationsquelle zu ermitteln.

aufweisen:

für die Entwicklung einer Analyse funktionaler Sicherheits-

– elektrische Fehlfunktion – z. B. eine unterbrochene

konzepte einsetzen. Für einen solchen Fall ist davon auszu-

Verbindung

gehen, dass die Designs für Funktionssicherheits-Konzepte, Funktionsarchitektur und Diagnosearchitektur miteinan-

Entsprechend erstellte Fehlfunktionszuordnungen können

Iain Cunningham (BEng(hons), MSc) arbeitet seit 2013 bei Vector GB Ltd. Er arbeitet in der Prozess Tools und Diagnose Abteilung und ist verantwortlich für Buissness Development Aktivitäten.

der verknüpft wurden.

dann solche Fehlfunktionsartefakte mit den Artefakten in der Funktionsarchitektur verknüpfen, siehe Bild 8.

Nutzen aus dem Engineering-Wissen für die Werkstatt

In der Funktionsarchitektur lässt sich durch Verfolgen der

Wenn bei Freigabe der Software zur Fahrzeugproduktion

Zuordnungen zwischen der logischen und der Software-

alle in der Phase der Diagnosearchitektur erstellten DTC-

Architektur sowie der Hardwaretopologie ermitteln, welche

Anforderungen erfüllt werden, dann kann man die Verknüp-

Prozessoren Diagnoseroutinen ausführen sollten. Dadurch

fungen und Zuordnungen im PREEvision-Designmodell aus

können diese beiden Fehlfunktionsklassen erkannt werden.

einem Artefakt der Feature-Liste nutzen. So können die

Anschließend ist es möglich, entsprechende DTC-Anforde-

Inputs für die Funktionen der Activity Chain gefunden wer-

rungen (Diagnostic Trouble Code) in der Architektur zu er-

den, wie zuvor beschrieben. Über die logischen Blöcke sind

stellen. PREEvision unterstützt das Konzept diagnostischer

auch alle dem System zugeordneten DTCs auffindbar, die

Master-Slave-Beziehungen in Fällen, in denen eine ECU

u. U. zu einer Funktions- oder Funktionalitäts-Beeinträchti-

oder ein Prozessor Diagnoseinformationen für eine oder

gung führen. Dies können hilfreiche Informationen für Tech-

mehrere ECUs, Sensoren oder Aktuatoren zusammenträgt.

niker beim Händler sein, wenn bei der Wartung Fehler in

Ein Beispiel, wie Diagnoseinhalte in der Modellstruktur ein-

einem komplexen, unbekannten System diagnostiziert wer-

schließlich der Anforderungen für diagnostische Data Iden-

den sollen.

tifier, Messungen und Steuerungen, zusätzlich zu den DTCs

Natürlich kann durch die starke Vernetzung von Fahrzeug-

dargestellt werden, findet sich in Bild 9.

systemen und -funktionen ein bestimmter Fehler im Bord-

Mit der Schaffung einer solchen Struktur wird eine

netz zu einer Beeinträchtigung mehrerer Features und

Diagnosearchitektur umgesetzt, die über die Hardware-

Funktionen führen. Da die Verknüpfungen und Zuordnun-

teren Analyse resultieren. Nehmen wir beispielsweise an,

topologie (bidirektional) mit der Funktionsarchitektur ver-

gen im PREEvision-Designmodell bidirektional sind, ergibt

dass die folgenden allgemeinen oder generischen Fehlfunk-

knüpft ist. Diese Art der Modellierung soll in erster Linie die

sich auch hier ein interessanter Ansatz: Stößt man bei

tionsklassen gemäß bestimmter, dokumentierter allgemei-

Entwicklung von Diagnosespezifikationen auf ECU-Ebene

einem Fahrzeug auf einen Fehler (DTC), kann eine Abfrage

ner Unternehmensanforderungen für Sensoren und Aktua-

unterstützen, und zwar bei Einhaltung der im Modell defi-

für das Designmodell ausgeführt werden, um nach allen

toren existieren und entsprechend diagnostiziert werden

nierten Anforderungen und unter Berücksichtigung der in

Artefakten in der Feature-Liste zu suchen, die ggf. von die-

sollten. Dabei wird vorausgesetzt, dass logische Funktio-

der Hardwaretopologie modellierten Master-Slave-Inter-

sem DTC betroffen sind. Auch dies liefert äußerst nützliche

nen lediglich für das Vorhandensein von Systemfehlern ge-

aktionen. So kann PREEvision eine Schnittstelle für den Ex-

Informationen für die Wartung.

nutzt werden können und dass diese vor der Serienferti-

port von Diagnoseanforderungen bereitstellen, die einer

gung entfernt werden: > Sensoren können zwei Arten von Fehlfunktionen

bestimmten ECU für die weiter detaillierte Betrachtung

Zusammenfassung

mit dem Vector Tool CANdelaStudio und für die Verwen-

Komplexe, vernetzte Systeme in Kraftfahrzeugen helfen

aufweisen:

dung in nachgelagerten Prozessen zugewiesen sind.

die immer strengeren Sicherheitsanforderungen der Behör-

– elektrische Fehlfunktion – z. B. eine unterbrochene

Als Nächstes kann man mithilfe der zuvor beschriebenen

den zu erfüllen und lassen Kunden gleichzeitig neue Kom-

Fehlfunktionsartefakte auch die logische Architektur bidi-

fortmerkmale erfahren. Die Komplexität solcher Systeme

Bild 9: Modellstruktur für diagnostische Artefakte

Verbindung

und ihrer Interaktionen bedeutet jedoch, dass sich eine Diagnose im Falle eines bei der Wartung festgestellten Fehlers als schwierig erweisen kann. Eben diese Komplexität hat jedoch auch zur Entwicklung von System-Designwerkzeugen wie dem Tool PREEvision von Vector geführt. Die mit solchen Tools erstellten Designmodelle können auf Basis der ursprünglichen Designdaten des Fahrzeugs als leistungsstarke, neue Informationsquelle für anspruchsvolle Wartungsumgebungen verwendet werden. Mit Einführung diagnostischer Modellierungs-Artefakte in PREEvision hat sich der mögliche Nutzen der aus dem DesignBild 10: Zuordnungen zwischen logischen und diagnostischen Architekturen über eine Fehlfunktion

2/12

modell ableitbaren Informationen erhöht. So können nun nicht nur die Inputs für die Logik eines Features oder einer

2/13

ELEKTRONIK + SOFTWARE TITELSTORY

So liegt der Kabelbaum richtig Gemeinsame Entwicklung von Elektrik/Elektronik und Mechanik im Fahrzeugbau

Ohne den Einsatz modellbasierter Techniken wäre die Komplexität in der Automobilentwicklung schon seit geraumer Zeit nicht mehr überschaubar und zu beherrschen. Allerdings haben sich im mechanischen Bereich und in der Elektrik/Elektronik verschiedene Entwicklungs- und ArchitekturWerkzeuge etabliert.

Preevision bildet alle relevanten Aspekte in einem Ebenenmodell ab – von den Anforderungen des Fahrzeugs über die logischen Fahrzeugfunktionen sowie Software- und HardwareKomponenten, die Kommunikation bis zur Verkabelung und den Geometrieinformationen

Eine strategische Partnerschaft der Vector Informatik mit Siemens PLM Software ermöglicht es künftig, Daten aus Mechanik, Elektrik, Elektronik sowie Software miteinander in Beziehung zu setzen. So lassen sich frühzeitig im Entwicklungsprozess nachhaltige Optimierungen durchführen sowie Inkonsistenzen an den Berührungspunkten aufdecken. Die ideale Lösung für eine modellbasierte Systementwicklung – die der Komplexität der Fahrzeuge Rechnung trägt – ist ein Kompromiss aus dem technisch Machbaren und einer Reihe verschiedener Optimierungsziele wie Kosten, Funktionalität, Gewicht, Bauraum oder Robustheit. Gleichzeitig gilt es, Randbedingungen wie Sicherheitsanforderungen, gesetzliche Vorgaben, Verbrauchs- und Emissionswerte zu berücksichtigen. Je detaillierter man die gewünschten Funktionen und Anforderungen an ein Fahrzeug sowie die Umsetzungsmöglichkeiten in einem Modell abbildet, umso genauere Vorhersagen liefert es über die Systemeigenschaften und das Systemverhalten. Modellbasierte Techniken haben sich sowohl in der Mechanik als auch im E/E-Bereich (Elektrik/ Elektronik) etabliert. So nutzen auf der klassischen konstruktiven Seite viele Anwender für Design, Entwicklung und Modellierung von mechanischen Komponenten das interaktive CAD/ CAM/CAE-System NX von Siemens, einem Bestandteil der Teamcenter Software. Demgegenüber findet man im Bereich der Auto-

Der Autor Dr. Clemens Reichmann ist Gründer und Geschäftsführer der Aquintos GmbH, Karlsruhe

2/14

mobil-Elektrik/Elektronik das von der Firma Aquintos entwickelte Modellierungswerkzeug Preevision, das seit dem Jahr 2010 unter der Produktbezeichnung „Preevision Architect“ ein Teil der „Easee Automotive Solution“ der Firma Vector Informatik ist. Es dient zur Konzeption, Entwicklung und Bewertung von E/E-Architekturen, wobei sich das zugehörige Datenmodell als De-facto-Standard zum Austausch von E/E-Daten zwischen verschiedenen Unternehmen, wie OEMs und Zulieferern, durchgesetzt hat. Über spezielle Metriken – Berechnungsvorschriften für Analysen – kann Preevision Systemeigenschaften gezielt in einem Zahlenwert zusammenfassen. Dies erlaubt formale Vergleiche und eine schnelle und objektive Bewertung verschiedener Architektur- und Designvarianten. Ausgehend von den Anforderungen (Featureliste) entwirft der Entwickler zunächst die logische Architektur, die Software- und HardwareKomponenten und gelangt schließlich zu den Ebenen von Stromlaufplan und Leitungssatz. Spätestens hier spielen geometrische und topologische Aspekte eine wichtige Rolle, um Leitun-

gen, Steckverbinder und elektronische Geräte an geeigneter Stelle unterzubringen. Idealerweise werden Einbauorte in den Bauräumen beim Design der Karosserieteile frühzeitig berücksichtigt. Die Visualisierung über ein 2,5-D-Modell, das die räumliche Verteilung von elektrischen und elektronischen Komponenten von oben gesehen darstellt, ist hier nützlich. Allerdings kann es keine Konflikte auflösen, die als Folge von Versäumnissen und mangelnder Kommunikation zwischen E/E-Architekten und Konstrukteuren entstehen. Feinabstimmung muss schon früh erfolgen E/E- und Mechanische Entwicklung arbeiten in verschiedenen Entwicklungsabteilungen und verwenden jeweils die auf ihre Domänen zugeschnittenen Entwicklungssysteme mit (grafischen) Editoren. Die notwendige Feinabstimmung findet für derart komplexe mechatronische Systeme häufig zu späte Beachtung. Bei dieser Vorgehensweise sind Inkonsistenzen an den Berührungspunkten von Mechanik und Elektrik/Elektronik kaum vermeidbar. Ein typi-

sches Beispiel sind die von den Mechanikern festgelegten Kabelbaumdurchbrüche in den Karosserieteilen. Während eine ungünstige Platzierung längere Kabel erfordern kann, drohen etwa Temperaturprobleme, wenn Leitungen zu nahe am Motorblock vorbeiführen. Je schneller und unkomplizierter Informationen zwischen den Entwicklungsteams der Mechanik und der Elektrik/Elektronik austauschbar sind, umso schneller lassen sich ungünstige Konstellationen vermeiden. Wissen die Mechaniker zum Beispiel frühzeitig, dass zwei kleine Durchbrüche besser sind als ein großer, können sie das berücksichtigen. Im Automobil gibt es etliche Berührungspunkte dieser Art: Man muss Platz für Steckverbindungen an Trennstellen wie Türen vorsehen, Trassenführungen einplanen, die für jeweils genügend große Querschnitte sorgen, Gehäuseschutz (IP-Schutzarten) und Schutz gegenüber Kontakt mit Öl, Benzin oder Bremsflüssigkeit sowie Schock- und Vibrationsfestigkeiten berücksichtigen. Besonders kritisch ist die Entwicklung der Stirnwand, das heißt der Trennwand zwischen Armaturenbrett und Motorraum samt der zahlreichen Durchbrüche. Im Fahrzeuginnenraum herrscht hier eine hohe Gerätedichte und Konzentration an Funktionalität, denkt man neben der Instrumentierung und der Elektrik/Elektronik beispielsweise an die Komponenten der Lüftungs- und Klimaanlage. Jeder will sein Steuergerät im Fahrzeuginnenraum unterbringen, um mit einer niedrigen Schutzart auszukommen. Während des Entwicklungsprozesses können aufgrund von Optimierungen oder Sparmaßnahmen durchaus auch einmal größere Strategieänderungen notwendig werden. Eine andere Aufteilung der Funktionen auf die verfügbaren Hardware-Ressourcen führt in

Der Architekturentwurf: Preevision unterstützt Spezifikation, Design und Optimierung aller Komponenten verteilter elektronischer Fahrzeugsysteme, Easee stellt Entwicklungsartefakte dem ganzen Unternehmen zur Verfügung

solchen Fällen gegebenenfalls zum Wegfall oder der Ergänzung von Steuergeräten beziehungsweise zu einem anderen Einbauort. Ganzheitlicher Ansatz hilft rationalisieren In solchen Situationen bedarf es flexibler Reaktionen auf Veränderungen und geeigneter Werkzeuge zum Informationsaustausch. Die strategische Zusammenarbeit von Vector und Siemens soll Mechanik-, E/E- und Entwicklungs-Teams von Embedded Software mit einem integrierten Ansatz unterstützen, in dem sich die Easee Automotive Solution und Siemens Teamcenter zu einer aus Sicht des Anwenders integrierten Lösung zusammenfügen. Bei der technischen Umsetzung spielt das Know-how der Vector Tochter Aquintos eine wesentliche Rolle. Daten aus Mechanik, Elektrik, Elektronik und Software lassen

Für die Arbeit in den verschiedenen Modellierungsebenen in Preevision stehen dem E/E-Entwickler spezifische tabellarische und grafische Editoren zur Verfügung

sich in Beziehung zueinander setzen. Konsistenzchecks erkennen bereits in frühen Entwicklungsphasen Konflikte bei Segmentquerschnitten, Trassenführungen, Abmessungen von Steuergeräten und ähnlichem oder vermeiden sie von vorneherein; dasselbe gilt bei Strategieänderungen. Die Modellierung bei Preevision unterstützt hierzu die Spezifikation verschiedener Produktvarianten. Die Modellobjekte der verschiedenen Ebenen werden über Mappings miteinander in Beziehung gesetzt. Alle Modellobjekte werden in der „Easee Collaboration Platform“ abgelegt. Sie können dort einerseits in Revisionen und Branches verwaltet werden, andererseits stehen sie so der gesamten Entwicklungsorganisation zur Verfügung. Die Verfolgbarkeit (Traceability) ist damit in verschiedenen Richtungen möglich: innerhalb einer Modellierungsebene, beispielsweise von einem Steuergerät zu den angeschlossenen Sensoren und Aktuatoren über die Modellierungsebenen hinweg, etwa von den Requirements bis zum konkreten CAN-Signal entlang der Zeit über die History. Für Anwender beider Seiten bringt die Kooperation der in ihren Bereichen jeweils als Marktführer geltenden Unternehmen daher Vorteile, um die Verzahnungen und Wechselwirkungen in mechatronischen Systemen zu beherrschen. Messe Embedded: Halle 10, Stand 115

· · ·

Vector Informatik; Telefon: 0711 80670-0; E-Mail: [email protected]

2/15

MESSEN UND TESTEN

MESSEN UND TESTEN

Schocks von –40 bis +120  °C aus. Die mechanischen Beanspruchungen reichen von Vibrationstests mit sinusförmigen Schwingungen und Rauschcharakteristiken bis zu Einzelschocks mit Beschleunigungen von 30  g. Des Weiteren sind Dichtigkeitsprüfungen durch Behandlungen mit Salzsprühnebel, feinstem Sandstaub oder Wasserschwall vorzunehmen; Hochdruckreiniger simulieren Motorwäschen.

(Bild: Vector Informatik)

Virtuelle Steuergeräte-Umgebungen

ZF TRW testet weltweit Steuergeräte mit neuem Konzept:

In Rekordzeit

Ein erheblicher Teil der Entwicklungskosten eines Steuergeräts entfällt auf die zahlreichen Tests vor jeder Serienfreigabe. Zudem ist der Aufwand für die Konzeption von Prüfständen und Programmierung von Testabläufen immens gewachsen. Doch mit der neuen Prüfstandsgeneration kann der Automobilzulieferer ZF TRW Kosten und Zeit sparen. Von Stefan Siefert-Gäde und Katja Hahmann

V

or Jahren zählten Antiblockiersysteme (ABS) zur ambitionierten Ausstattung von Fahrzeugen ab der gehobenen Mittelklasse. Heute gehören komplexe erweiterte Schlupfregelsysteme wie ESC (Electronic Stability Control), in Deutschland als ESP (elektronisches Stabilitätsprogramm) bezeichnet, zum aktuellen Stand der Technik. Am Beispiel der Evolution von ABS zu ESP lässt sich anschaulich demonstrieren, wie die Komplexität der Automobilelektronik auf allen Gebieten kontinuierlich zunimmt. Im Gegensatz zu einem ABS-System, das nur tätig wird, wenn der Fahrer aktiv bremst, arbeitet ein ESP-System praktisch autonom. aus Elektronik automotive 8/9.2015

3/0

Entsprechend ist mehr Sensorik notwendig, um das System mit Informationen über Beschleunigungen, Quer- und Längskräfte oder Torsionsbewegungen zu versorgen. Daher müssen moderne Steuergeräte immer mehr Signale der Steuergerätesensoren oder der angeschlossenen Bussysteme verarbeiten.

Testaufwand erreichte Schmerzgrenze Der Automobilzulieferer ZF TRW entwickelt in seinem Werk in Koblenz unter anderem Steuergeräte für ESP-Systeme. Die zunehmende Komplexität der Entwicklungen spiegelt sich nicht zuletzt im

Testaufwand wider. Sowohl die Anzahl der Steuergeräte als auch deren erweiterter Funktionsumpfang verursachen immer höhere Kosten für die Tests. In den letzten zehn Jahren hat sich die Zahl der Steuergeräte von circa 30 auf bis zu 200 in einem Oberklassefahrzeug erhöht. Der technische Aufwand, der hinter den zahlreichen Prüfszenarien steckt, um jeden Steuergerätetyp unter allen erdenklichen Betriebs- und Umgebungsbedingungen zu testen, ist immens. Für jedes Fahrzeugmodell und jeden Hersteller ist eine spezielle Steuergerätevariante erforderlich. Bei ZF TRW gibt es entweder eine Steuergerätevariante als ESP-System oder eine Variante mit integrierter Parkbremse. Insgesamt muss jedes Steuergerät zahlreiche elektrische, funktionale und mechanische Umwelt- und EMV-Tests vor der Freigabe absolvieren. Simulationen bilden dazu Umgebungseinflüsse sowie mechanische und elektromechanische Beanspruchungen oder Extremsituationen nach. So setzen zyklische Temperaturwechsel-Dauerlauftests die Geräte und Platinen thermischen

Voraussetzung für diese Tests ist ein laufender Betrieb des Steuergeräts. Repräsentative Tests und eine umfassende Diagnose der Steuergerätefunktion sind jedoch nur möglich, wenn der Prüfstand die elektrische und elektronische Fahrzeugumgebung lückenlos nachbildet. Somit sind für alle digitalen und analogen Eingänge Signale mit realitätsnahen Spannungen und Strömen zu generieren. Dasselbe gilt für angeschlossene Lasten und für die sogenannte Restbussimulation. Weil sich neben CAN längst weitere Bussysteme, wie FlexRay, LIN und MOST, im Automobil etabliert haben, kommunizieren zahlreiche Steuergeräte gleichzeitig mit mehreren Bussen. Diese Multibus-Systeme erhöhen die Komplexität ein weiteres Mal und sind in den Restbussimulationen ebenfalls korrekt abzubilden – manchmal auch der Funktionsumfang von Gateways. Um der steigenden Komplexität der Steuergerätetests und den verfügbaren Zeitschienen auch in Zukunft gerecht werden zu können, suchten die Prüfstandsingenieure vor einiger Zeit nach einer moderneren flexibleren Prüfstandslösung. Sie sollte global und einheitlich an allen ZF-TRW-Standorten umgesetzt werden. Inzwischen hat der Automobilzulieferer insgesamt 32 der neuen Prüfstände in Deutschland, USA, Tschechien und China in Betrieb. Jeder Prüfstand besteht aus einem 19-ZollSchrank mit sechs Einschüben, sodass sich jeweils sechs Steuergeräte parallel prüfen lassen (links im Aufmacherbild). Über einen Scanner, einen Touch-Bildschirm und eine Tastatur pro Schrank lassen sich Benutzereingaben vornehmen, Ergebnisse anzeigen oder Statusmeldungen ablesen (Bild 1). Die Energieversorgung für die Einschübe erfolgt über eine zentrale Stromversorgung,

die für Hochstromverbraucher Ströme bis 500 A oder eine Nennspannung bis 30 V liefern kann. Die hohen Leistungen sind für die Tests der ESP-Steuergeräte notwendig, bei denen 580-W-Antriebe für den Druckaufbau der Bremshydraulik verantwortlich sind und hohe Anlaufströme entstehen. Dennoch ist es notwendig, den Energiebedarf während paralleler Tests zu managen, damit nicht alle Einschübe die Maximalleistungen gleichzeitig abrufen.

Intelligentes Netzwerk-Interface im Mittelpunkt

se mit minimalen Anpassungen in Tests direkt weiterverwenden. Diese Restbussimulationen sind bereits intern verifiziert, sodass zu diesem Zeitpunkt kein zusätzlicher Aufwand mehr für deren Qualitätssicherung anfällt. Durch diesen Ansatz schließen sich interne Bedenken damit quasi von selbst aus, was zu einer spürbaren Entlastung der Mitarbeiter und vor allem des Projektleiters führt. Die Rüstzeiten wurden damit drastisch reduziert: in der Größenordnung von bis zu acht Monaten zum Umrüsten eines Steuergerätetests von OEM1 auf OEM2 auf jetzt zwei bis drei Wochen. Gleichzeitig wurde die Flexibilität bei der Reaktion auf späte Kunden-Software-Änderungen kurz vor Teststart mit Anpassungszeiten unter einer Woche enorm gesteigert.

Eine zentrale Rolle im Konzept der komponentenbasierten Prüfstände spielt eine spezielle Hardware vom Typ VN8900 aus dem Hause Vector Informatik (Bild 2). Der ZF-TRW-Prüfstandlieferant, die Smart Testsolutions GmbH Robuste Testabläufe – nicht zu verwechseln mit dem Kleinwagenhersteller – hat pro Einschub Eine weitere Besonderheit des VN8900jeweils ein VN8900-System in seine Systems ist die Möglichkeit zum autoLösung integriert (Bild 3). Beim VN8900nomen Betrieb, ohne dass eine VerbinSystem handelt es sich um ein modudung zu einem Bedien- oder Überwalares Netzwerk-Interface für die Bussyschungs-PC notwendig ist. Von den teme FlexRay, CAN (FD), LIN, J1708 und Testingenieuren werden am normalen K-Line, das mit einem eigenen x86PC-Arbeitsplatz mit Hilfe von CANoe Echtzeit-Rechner ausgestattet ist. DieRestbussimulationen und Testabläufe ser sorgt insbesondere bei Anwendunin der Skriptsprache CAPL erstellt. Angen mit vielen parallelen Zugriffen auf schließend lassen sie sich einfach auf mehreren Bus-Kanälen für hohe E/Adas VN8900-System laden und dort Leistung mit kurzen Reaktions- und Antwortzeiten sowie geringsten Latenzen. Neben den variabel konfigurierbaren Busschnittstellen stellt das System Erweiterungsmöglichkeiten für analoge und digitale Ein-/Ausgänge bereit. Dieses intelligente Interface ist einfach von einem PC aus über USB oder Ethernet konfigurierbar. Weil die VN8900-Systeme auf die Vector-Simulations- und Analysewerkzeuge CANoe und CANalyzer optimiert sind, fügen sich die neuen Prüfstände nahtlos in die Werkzeugkette bei ZF TRW ein. Aus den Entwicklungsabteilungen vorhandene CANoe-RestBild 1. Anwenderfreundliches Konzept mit Touch-Bildschirm, bussimulationen lassen Scanner und Tastatur erleichtert das Bedienen der Prüfstände. sich somit praktischerwei(Bilder: Vector Informatik)

aus Elektronik automotive 8/9.2015 3/1

MESSEN UND TESTEN

Steuergerät

TestController

Sensorik Aktorik Messtechnik

Teststeuerung-/überwachung

ausführen. ZF TRW prolassen sich die VN8900fitiert hier unter andeGeräte am Arbeitsplatz rem von einer höheren sinnvoll weiterverwenStabilität und Robustheit den, anstatt als totes bei Langlauftests. Früher Kapital ungenutzt zu passierte es vor allem bleiben. bei bis zu sechsmonatigen Langlauftests hin Die Entwicklung geht und wieder, dass der PC weiter nach einigen Monaten abstürzte. Das ist insoMit seinen neuen Prüffern ärgerlich, als der ständen, die erstmals Rechner dann über keibeim Testen von ESPnerlei KontrollmöglichSteuergeräten zum Einkeit mehr über den lausatz kamen, verfügt ZF TRW über ein kompofenden Testprozess verfügt. Derartige Probleme nentenbasiertes Testsyssind bei den neuen Prüftem, bestehend aus ständen bisher nicht sechs bis sieben Bausteiaufgetreten. Bild 2. Das modulare VN8900-Netzwerk-Interface mit integriertem Echtzeitrechner nen, die in verschiedeHeute sind Test Connen Konstellationen spielt eine zentrale Rolle für die Netzwerk-Kommunikation des Steuergerätes. trolling, Visualisierung kombinierbar sind. So und Kommunikation zum Steuergerät Löschen von Fehler-Codes, das Lesen kann das Unternehmen das Prüfstandstreng getrennt. Das VN8900-System und Sichern von XCP-Variablen, das konzept zügig an Tests für andere Steukommuniziert mit einem Linux-basierten Beeinflussen der Restbussimulationen ergerätetypen adaptieren, zum Beispiel Leitrechner von Smart Testsolutions und vieles mehr. für Airbags oder Fahrerassistenzsysteme. über die LAN-Schnittstelle. Dabei kommt Beeindruckend sind die verkürzten ein spezielles, von Vector mitgeliefertes, Budget-freundliche Lösung Rüstzeiten und die Geschwindigkeit, mit echtzeitfähiges Ethernet/UDP-Protokoll der die Verantwortlichen jetzt auf Anmit der Bezeichnung FDX (Fast Data Für ZF TRW war die breite Unterstützung forderungsänderungen reagieren könExchange) zur Anwendung. Durch eine in Hinsicht auf die benötigten Protokolnen. Künftige Systeme für das autonome enge Zusammenarbeit mit Vector Inforle ein wichtiges Argument, sich zugunsFahren sind bereits avisiert. Beim Testen matik war ZF TRW in der Lage, das FDXten der Vector-Lösung zu entscheiden. der hierfür unverzichtbaren Radar- und Protokoll nach eigenen Vorstellungen Der Werkzeughersteller hat aus Sicht Kamerasysteme wird es für das neue zu modifizieren, und konnte in diesem des Zulieferers für alle am Markt gängiPrüfstandskonzept viele Gelegenheiten Rahmen beispielsweise einen Datenausgen Protokolle sowie Automobilherstelgeben, seine Leistungsfähigkeit und sein tausch nach dem Fifo-Prinzip implemenler-spezifischen Netzwerke und DiagnoRationalisierungspotenzial weiterhin tieren. Umgekehrt hat Vector bei der sesysteme eine entsprechende Lösung unter Beweis zu stellen. eck Weiterentwicklung des VN8900-Systems parat. Diese zudem kostenlosen Lösunauch Ideen von ZF TRW aufgegriffen. gen sind ein Alleinstellungsmerkmal von FDX bietet nun weitreichenden Zugriff Vector am Markt. Der Vorteil möglicherauf autonom laufende Tests und erlaubt weise günstigerer Hardware-Komponeben dem Starten und Stoppen von nenten anderer Hersteller löst sich durch Anwendungen etwa das Auslesen und höhere Folgekosten auf, wenn ProtokolDipl.-Ing. (FH) le für einzelne Busse oder die für diverStefan Siefert-Gäde se OEMs fehlende XCP-Unterstützung studierte Elektrotechnik an der PC FH Koblenz. Er trat 2006 in die erst nachzuentwickeln ist. ZF-TRW-Bedienoberfläche für Prüfstände TRW Automotive ein. Seit 2014 Vorteilhaft gelöst hat der Hersteller Energieversorgung USB-Multiplexer koordiniert Siefert-Gäde im des VN8900-Systems auch die LizenzBereich Global Electronics die frage, weil Anwendern wie dem AutoBuskommuniSteuereinheit kation globale strategische Entwicklung von Test Equipment. mobilzulieferer durch die sogenannte CANoe-Stand-Alone-Extended-Lizenz VN8900: Ethernet - Restbuspraktisch keine weiteren Kosten anfalCAN simulation (FDX) len. Mit einer CANoe-Lizenz auf einem - Diagnose LIN (UDS, XCP) Entwicklungs-PC lassen sich beliebig Dipl.-Ing. FlexRay viele Prüfstandsanwendungen erstellen. Katja Hahmann I/O Updates der VN8900-Systeme auf aktustudierte Elektrotechnik an der TU Chemnitz. Sie trat 1997 bei elle CANoe-Versionen sind dabei immer Vector Informatik ein und ist Bild 3. Blockschaltbild eines eigenständigen Subsyskostenlos enthalten. Selbst wenn sich dort Gruppenleiterin der CAder Lebenszyklus der neuen Prüfstände tems, von dem pro Prüfstand sechs Einheiten verbaut Noe-Anwendungsentwicklung. einmal ihrem Ende zuneigen sollte, sind.

Erfahrung in Serie. Setzen Sie auf erprobte FlexRay-Lösungen Solutions for FlexRay

Profitieren Sie bei Ihrer FlexRay-Entwicklung von umfassenden Erfahrungen aus Serienprojekten. Nutzen Sie dazu das durchgängige Vector Angebot zur FlexRay-Vernetzung: > Simulieren, diagnostizieren und testen Sie Steuerge-

> Sichern Sie sich Qualitäts- und Zeitvorteile: Bauen

räte und Netzwerke mit einer ausgereiften Entwick-

Sie auf kompetente Unterstützung bei Entwicklung

lungsumgebung: CANoe und die FlexRay-Interfaces

und Training

> Profitieren Sie von standardisierter Steuergerätesoftware. Die Softwaremodule von Vector können

Steigen Sie ein: www.flexray-solutions.de

Sie flexibel konfigurieren und leicht integrieren. Bringen Sie FlexRay zuverlässig auf die Straße – mit serienerprobten Werkzeugen, skalierbaren Modulen und über 25 Jahren Vernetzungs-Know-how von Vector.

aus Elektronik automotive 8/9.2015 3/2

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Steuergerätetests effizienter programmieren – Basics, Tipps und Tricks beim Einsatz von CAPL Teil 1: CAPL-Basics

>>Wenn die Botschaft LightState empfangen wird, dann

der TX bzw. RX–Interrupt des CAN-Controllers, also direkt

sollen die darauf enthaltenen Signale HeadLight und

nach korrekt erfolgter Übertragung der Botschaft. Die Bot-

Flashlight für die grafische Darstellung in einem

schaft aufgrund derer die aktuelle Funktion aufgerufen

Anzeige­panel aufbereitet werden und an das Panel

wird, wird mit der Syntax „this“ bezeichnet.

weitergereicht werden.

In Zeile 8 wird der Wert des Signals EngineSpeed aus der soeben empfangenen Botschaft (this) ausgelesen und mit

CAPL ist eine von Vector Informatik entwickelte Programmiersprache, die in den weit verbreiteten Software-Werkzeugen CANoe und CANalyzer zur Verfügung steht. In drei aufeinanderfolgenden Beiträgen werden zu CAPL-Grundlagen

Genaue Betrachtung des Programms

sowie Tipps und Tricks je nach Kenntnisstand der Anwender vorgestellt. Dieser erste Teil konzentriert sich dabei auf die

Die Zeilennummern sind nicht Bestandteil des CAPL-Pro-

wiesen.

Basics von CAPL. Er ist in erster Linie für Neulinge dieser Sprache interessant; für Kenner ergeben sich eventuell ein paar

grammes und sind hier nur eingefügt, um einfacher einzel-

Die Zeilen 11..17 zeigen eine Botschaftseventprozedur für die

Einblicke in die Motivation für einzelne CAPL-Konstrukte. Der zweite Teil wird fortgeschrittene Funktionsweisen von

ne Zeilen oder Abschnitte referenzieren zu können. Um eine

Botschaft LightState, die die Informationen zu einem Blin-

CAPL behandeln. Der dritte Teil schließlich enthält eine Betrachtung zur Performance und zum Speicherbedarf sowie

möglichst kompakte Darstellung zu ermöglichen, wurden

ker überträgt. Die Verarbeitung ist ähnlich wie bei der Bot-

Tipps und Tricks zur Verwendung von Datenbanken und assoziativen Arrays.

hier öffnende Klammern nicht in einer separaten Zeile plat-

schaft EngineState mit folgenden Besonderheiten: In Zeile

ziert.

12 wird nun in der gerade übertragenen Botschaft (this) das

einer Umrechnung (/ 1000.0) an eine Systemvariable zuge-

In einem CAPL–Programm können globale Variablen und

RichtungsFlag (.dir) geprüft. Es sollen in diesem Programm

Seit über 20 Jahren – damals zunächst in CANalyzer für

Botschaften und Signale erhalten dort Namen und

Konstanten definiert werden. Dies geschieht in dem Ab-

nur empfangene Botschaften betrachtet werden (Wert RX),

DOS – lässt sich mit CAPL eine große Bandbreite von Auf-

können direkt mit diesem im Programmcode verwendet

schnitt „variables“ (Zeilen 1..5). Global sind diese Konstan-

da auch eine vom Knoten selbst versendete Botschaft eine

gaben effizient umsetzen: von einfachen Stimuli bis zur

werden. In Bild 1 sind das die Bezeichner „EngineState“

ten und Variablen für dieses Programm: sie sind überall im

Event-Prozedur auslöst (Wert TX). In diesem Fall würde in

für eine Botschaft und „EngineSpeed“ für ein Signal auf

Programm verwendbar, aber nicht in anderen Programmen

Zeile 15 gegebenenfalls eine Fehlermeldung ausgegeben.

innerhalb derselben Anwendung von CANoe. Die weiteren

Da die Aufarbeitung des Signals für die Darstellung an der

Abschnitte definieren Reaktionen auf Ereignisse (Zeilen

Oberfläche (einem Panel, in dem verschiedene Zustände

typen an die Hand. Damit sind eine Unmenge Program-

7..17) und eine Hilfsfunktion (Zeilen 19..28).

mit verschiedenen Bitmaps dargestellt werden) etwas auf-

lösen. Typische Aufgaben sind das Reagieren auf empfan-

mierfehler und Ursachen für Programmabstürze, wie sie

Die Zeilen 7..9 zeigen eine minimale Form einer Botschafts-­

wändiger ist, wird die Implementierung in eine eigene Funk-

gene Botschaften, das Testen und Setzen von Signalwer-

C-Programmierern häufig widerfahren, von vornherein

Event-Prozedur. Diese Funktion wird genau dann aufgeru-

tion ausgelagert: In Zeile 13 wird SetLightDsp mit den bei-

ten oder das Senden von Botschaften. Hier sollte sich ein

ausgeschlossen. Da Pointer abgesehen von ihrer Fehler-

fen, wenn diese Botschaft auf dem Bus übertragen wurde.

den benötigten Signalen der Botschaft als Parameter auf-

Programm auf genau diese Dinge beschränken und keinen

anfälligkeit auch ein sehr mächtiges Konzept darstellen,

Spezifisch für CAN bedeutet das: Der genaue Zeitpunkt ist

gerufen.

weiteren Overhead erfordern.

gibt es für manche Dinge in CAPL Ersatz, so zum

Viele Programmieraufgaben, mit denen ein CANoe Anwen-

Beispiel die assoziativen Arrays als Ersatz für dynami-

der zu tun hat, mögen tatsächlich so kurz und trivial wie

schen Speicher.

Simulation komplexer Busteilnehmer. Im Folgenden wird ­ CANoe stellvertretend für die beiden Produkte CANoe und CANalyzer genannt. Das Ziel von CAPL ist seit jeher, die ­jeweiligen Aufgabenstellungen so einfach wie möglich zu

dieser Botschaft. >>CAPL-Programme geben dem Benutzer keine Pointer-

das unten aufgeführte Beispiel sein – viele andere Aufgaben sind es natürlich nicht. Deshalb wurde CAPL stetig

Eine wichtige Eigenschaft, die CAPL mit C verbindet, sei

über die Jahre erweitert, um auch bei komplexen Aufgaben

noch erwähnt: CAPL wird immer kompiliert, also in effizi-

als Werkzeug nach dem Grundsatz „so einfach wie mög-

ent ausführbaren, flexiblen Maschinencode übersetzt.

lich“ zur Verfügung zu stehen. „CAPL“ steht dabei als Akronym für „Communication

Beispiel: Ein simples CAPL-Programm

Access Programming Language“. Die ursprüngliche Aus­

In diesem Abschnitt wird ein einfaches CAPL-Programm

richtung auf CAN ist schon längst auf alle automobilen und

vorgestellt (Bild 1), das eine der grundlegenden Aufgaben

einige weitere Bussyteme erweitert, wie beispielsweise LIN,

eines Busmonitorwerkzeugs erledigt: es lauscht am Bus

FlexRay, MOST, J1587 aber auch ARINC und CANopen.

und bereitet ein paar der Ereignisse auf dem Bus für die

Die Syntax von CAPL lehnt sich – wie viele andere Sprachen

Beobachtung/Überwachung durch den Anwender auf. Es

auch – eng an die Syntax der Sprache C an. Wer sich mit C,

handelt sich hier um ein gekürztes Beispielprogramm von

C# oder verschiedenen modernen Script-Sprachen aus-

CANoe: Display.can aus dem Beispiel Easy.cfg. Das Bild 1

kennt, findet sich auch in CAPL schnell zurecht. Ein paar

zeigt das Programm. Im Folgenden wird erst die Gesamt-

Auffälligkeiten unterscheiden aber ein CAPL-Programm von

funktion kurz umrissen, bevor dann die einzelnen Abschnit-

einem C-Programm: >>CAPL-Programme sind event-orientiert. Das heißt, sie

te genauer beschrieben werden.

Event innerhalb des aktuell betrachteten Systems reagieren:

Aufgabenstellung >>Es soll ein CAN-Bus beobachtet werden, dessen Elemente

den Empfang einer Botschaft, die Änderung eines Signals,

wie Busknoten, Botschaften und transportierte Signale

bestehen aus einzelnen Funktionen, die jeweils auf ein

das Ablaufen eines Timers oder auch eine Änderung in der „Umgebung“. So wird auf die Botschaft „EngineState“ reagiert: „On message EngineState“ (Bild 1). >>CAPL-Programme verwenden spezifische Datenbanken für die Kon-zepte des aktuell betrachteten Systems.

3/4

mit einer Datenbasis beschrieben werden. >>Wenn die Botschaft EngineState empfangen wird, dann soll das darauf enthaltene Signal EngineSpeed für die Darstellung in einem Anzeigepanel aufbereitet werden und an das Panel weitergereicht werden.

Bild 1: Ein einfaches CAPL-Programmbeispiel

3/5

Die Zeilen 19 bis 28 schließlich definieren eine eigene Funktion, die je nach Wert der übergebenen Signale unterschiedliche Werte in die Systemvariable LightDisplay im Namensraum Lights schreibt. Diese Variable wählt dann in dieser Demokonfiguration in einem Anzeigepanel die jeweils passende Bitmap aus. Übersetzung der englischen Veröffentlichung im CAN News­ letter, Ausgabe 2/2014.

CAPL – „Communication Access Programming ­Language“ CAPL ist eine von Vector Informatik entwickelte prozedurale, C-ähnliche Programmiersprache. Die Ausführung wird von Progammblöcken durch Ereignisse gesteuert. CAPL-Programme werden mit einem eigenen Browser entwickelt und kompiliert. Dabei kann auf alle in der Datenbasis enthaltenen Objekte (Botschaften, Signale, Umgebungsvariablen) und Systemvariablen zugegriffen werden. Darüber hinaus bietet CAPL eine Vielzahl von vordefinierten Funktionen, die das Arbeiten mit dem Entwicklungs-, Test- und Simulations-Werkzeug CANoe und CANalyzer unterstützen.

Marc Lobmeyer (Dipl.-Inf.) arbeitet seit 1994 bei Vector Informatik als Entwickler an CANoe und CANalyzer.

Roman Marktl (Dipl.-Ing) arbeitet seit 2012 bei Vector Informatik als Produktmanager im Bereich für CANoe und CANalyzer.

3/6

Steuergerätetests effizienter programmieren – Basics, Tipps und Tricks beim Einsatz von CAPL

#include:

Messknoten und Testprogramm sowie der verwendeten

Include-Dateien enthalten beliebige, aber vollständige, Ab-

CANoe-Version zu unterscheiden. Hier ein Beispiel zusam-

schnitte eines CAPL-Programmes: includes, variables und

men mit einem #pragma message:

Teil 2: CAPL besser verstehen und effektiv anwenden

procedures. Im Gegensatz zu C wird hier nicht einfach der Text der Include-Dateien in die CAPL-Datei eingefügt, son-

#if (TOOL_MAJOR_VERSION < 8)

Der erste Teil dieser Artikelreihe behandelte die grundlegenden Konzepte der Programmiersprache CAPL. Der nun folgende

dern die Abschnitte. Dabei gelten alle Abschnitte der

#pragma message(„This program needs at least

zweite Teil erläutert das Zeitverhalten von Ereignisprozeduren. Zudem gibt es für alle Anwender Tipps für ein effektives

Include-­Datei in der gesamten includierenden CAPL-Datei

CANoe 8 „)

Arbeiten mit CAPL rund um die Themen „generisches Programmieren“ und „bedingtes Compilieren“.

„als ob“ sie darin enthalten wären. Die Reihenfolge der Ab-

#endif

schnitte ist in CAPL sowieso unerheblich. Das bedeutet, der #pragma message:

Das Ausführungsmodell

gleichzeitig initiiert, was zum Beispiel bei CAN zu einem ge-

an. Außerdem dürfen sich Code und Daten aus includieren-

Die Direktive #pragma message ermöglicht es den Anwen-

Ein wichtiger Unterschied zwischen CAPL und C sowie C++

sicherten Arbitrieren mehrerer durch output() ausgegebe-

der und Include-Datei gegenseitig verwenden. Als Ausnah-

dern, eine eigene Meldung während eines Übersetzungs-

ergibt sich aus der Vorgehensweise, wann und wie Pro-

ner Botschaften führt.

me des eben erklärten Verbots doppelter Symbole dürfen

vorganges auszugeben, zum Beispiel die Versionsnummer

on start, on preStart, on preStop und on stopMeasurement

für das gerade übersetzte CAPL-Programm. Diese er-

grammelemente aufgerufen werden. In C beginnen beispielsweise alle Verarbeitungsabläufe mit der zentralen

Aktualisieren von Systemvariablen:

in der includierenden und in der Include-Datei koexistieren.

scheint zusammen mit den anderen Meldungen, Warnun-

Startfunktion main(). In CAPL hingegen enthält ein Pro-

Mit CAPL können Anwender auch außerhalb des Program-

Bei diesen Funktionen wird der Code nacheinander ausge-

gen, Fehlern und allgemeinen Meldungen des Compilers.

gramm eine ganze Sammlung gleichberechtigter Prozedu-

mes sichtbare Umgebungs- oder Systemvariablen ändern.

führt, erst der Code aus der Include-Datei, dann der Code

ren, die jeweils auf externe Ereignisse reagieren: >>Vom System ausgelöst: Diese Ereignisse sind einerseits

CAPL vollzieht Wertänderungen einer Variablen erst nach

aus der includierenden Datei.

Übersetzung der englischen Veröffentlichung im CAN News­

Ende der aktuellen Ereignisbearbeitung, aber weiterhin mit

Include-Dateien übernehmen damit drei Aufgaben: das De-

letter, Ausgabe 3/2014.

die zur Initialisierung und Nachbereitung des Messungs-

der Zeit des eben behandelten Ereignisses. Ein lesender Zu-

klarieren von Datentypen, das Definieren von Variablen und

laufs nutzbaren Ereignisse on preStart, on start, on

griff innerhalb der aktuellen Prozedur liefert also auch nach

das Bereitstellen einer (inline-) Funktionsbibliothek.

preStop und on stopMeasurement, andererseits die Zeit-

scheinbarer Änderung einer solchen Variablen noch den al-

steuerungs- und Tastaturereignisse on timer und on key. >>Durch Buskommunikation ausgelöst: Die Ereignisproze-

ten Wert. Das hat den Vorteil, dass zu einem Zeitpunkt

#pragma library:

nicht mehrere Wertänderungen auftreten.

CAPL-Programme können in anderen Sprachen erstellte

CAPL ist eine von Vector Informatik entwickelte proze-

Windows-DLLs mit einer passenden CAPL-DLL-Schnitt-

durale, C-ähnliche Programmiersprache. Die Ausführung

duren, die durch Busereignisse wie Kommunikation oder

CAPL – „Communication Access Programming ­Language“

Fehlerbehandlung auftreten, sind vielfältig und stark

Das Ausführungsmodell ist situationsabhängig:

stelle verwenden. Diese DLLs lassen sich direkt mit der Di-

wird von Progammblöcken durch Ereignisse gesteuert.

bustypabhängig. Beispiele sind hier on message und on

CAPL ist in CANoe und CANalyzer vielfältig einsetzbar.

rektive #pragma library(„capldll.dll“) einbinden.

CAPL-Programme werden mit einem eigenen Browser

busOff bei CAN oder on frFrame und on frStartCycle bei

Daher variiert auch das Ausführungsmodell etwas: Die ­

FlexRay. >>Durch Zugriff auf ein Value Object ausgelöst: Hierbei

entwickelt und kompiliert. Dabei kann auf alle in der

­Simulationsknoten einer CANoe Simulation befinden sich

Makros:

Datenbasis enthaltenen Objekte (Botschaften, Signale,

parallel am Bus. Entsprechend sind sie unabhängig. Einmal

In CAPL stehen den Anwendern mehrere vordefinierte Ma-

Umgebungsvariablen) und Systemvariablen zugegriffen

handelt es sich einerseits um System- und Umgebungs-

ausgelöste Ereignisse werden immer an alle Programme

kros im Code und für bedingtes Compilieren zur Verfügung.

werden. Darüber hinaus bietet CAPL eine Vielzahl von

variablen, die in CANoe/CANalyzer global zur Verfügung

verteilt . Im Unterschied dazu sind die Knoten im Messauf-

Makros für den Einsatz im Code lassen sich uneinge-

vordefinierten Funktionen, die das Arbeiten mit dem

stehen, sowie andererseits um Signalwerte, die einer

bau und in CANalyzer seriell hintereinander angeordnet:

schränkt überall im Code verwenden. Im Gegensatz zu C ist

Entwicklungs-, Test- und Simulations-Werkzeug CANoe

Dateninterpretation der Buskommunikation entspre-

Jeder Knoten reicht seine Ausgaben an den nächsten wei-

der Einsatz auch beispielsweise völlig frei innerhalb von

und CANalyzer unterstützen.

chen. Das Interpretieren führen spezielle Datenbanken

ter. Eintreffende Ereignisse benötigen zur weiteren Verar-

String-Konstanten, Variablen- und Funktionsnamen. Sie be-

aus. Auf dieses Konzept wird Teil 3 dieser Artikelreihe

beitung eine explizite Weiterleitung an den nächsten Kno-

ginnen und enden immer mit einem %-Zeichen und dienen

eingehen.

ten. Dafür stehen die Prozeduren on * und on [*] bereit.

hauptsächlich zum Schreiben von generischen Programmen.

Ein weiterer Programmtyp sind die Testprogramme, deren

Die verfügbaren Code-Makros umfassen unter anderem

Ereignisprozeduren sind atomar:

Testprozeduren auf externe Ereignisse warten können. Bei

den Knotennamen, den Index des aktuellen Kanals, den

Auch das Simulationsmodell von CANoe ist ereignisorien-

Eintritt eines solchen Ereignisses fährt CAPL dann mit des-

­Namen des aktuellen Netzwerks und den Typ des verwen-

tiert. In Ereignisprozeduren führt CANoe aus Modellsicht

sen Simulationszeit fort. Im Gegensatz dazu legt ein War-

deten Busses. Auf den Namen der enthaltenden Datei kann

alle Aktionen gleichzeitig aus, nämlich zum Zeitpunkt des

ten in normalen Ereignisprozeduren das gesamte Simula­

der Code mit %FILE_NAME% zugreifen, auf den Namen

auslösenden Ereignisses. Die tatsächliche Berechnungs-

tionssystem brach. Dies ist eine häufige Fehlerquelle bei

der aktuell übersetzten Programmdatei mit %BASE_FILE_

dauer auf einem realen PC wird also vernachlässigt.

der Anwendung von CAPL. Es ist daher nicht sinnvoll, ein

NAME%. Letzteres ist bei Include-Dateien die includierende

Busy-Wait oder einen Wartebefehl in einer externen DLL zu

Datei. Hier zwei einfache Beispiele:

Simulationszeit und Zeitstempel:

Marc Lobmeyer (Dipl.-Inf.) arbeitet seit 1994 bei Vector Informatik als Entwickler an CANoe und CANalyzer.

Roman Marktl (Dipl.-Ing) arbeitet seit 2012 bei Vector Informatik als Produktmanager im Bereich für CANoe und CANalyzer.

verwenden.

Ein im PC erzeugtes reales Ereignis, etwa eine Busausgabe

3/8

Compiler mahnt doppelt vorhandene Symbole als Fehler

write(„The node name is %NODE_NAME%“);

durch output(), erhält allerdings einen Zeitstempel von der

Tipps zum effizienten Programmieren in CAPL

Echtzeituhr. Die Reihenfolge und Zeitpunkte dieser Ereig-

Der Präprozessor ist in der Sprache C ein mächtiges Hilfs-

nisse können dabei durch Busprotokolle, Treiber- und Hard-

mittel, das aber auch zu Unübersichtlichkeit und damit zu

Für das bedingte Compilieren von Code-Abschnitten gibt

ware-Eigenschaften beeinflusst werden.

Fehlern führen kann. In CAPL gibt es deswegen nur eine

es einen eigenen Satz vordefinierter Makros. Diese sind #if,

Im Falle eines simulierten Busses entfallen einige der ge-

Auswahl der von C bekannten Präprozessor-Direktiven mit

#else, #elif oder #endif. Sie erlauben es, innerhalb eines Pro-

nannten Einflussgrößen. Dort werden die Busereignisse

vergleichbarer Semantik.

grammes nach den Programmarten Simulationsknoten,

putValue(envChannel%CHANNEL%Var1, %CHANNEL%);

3/9

Steuergerätetests effizienter programmieren – Basics, Tipps und Tricks beim Einsatz von CAPL

beliebigen Botschaften und Signalen die Datenbankdefini-

on sysvar_update werden bei jedem schreibendem Zugriff

tionen liefern. Ein kurzes Beispiel:

auf die jeweiligen Datenobjekte aufgerufen, auch dann,

Teil 3: CAPL für Fortgeschrittene

message * m;

dazu bringen on signal_change und on sysvar_change einen

int i, mx;

Performance-Vorteil, sofern nur Wertänderungen interes-

Der dritte und letzte Teil dieser Artikelreihe stellt einige Tipps und Tricks für fortgeschrittene Anwender vor. Insbesondere

mx=elcount(aNet::aNode.Tx);

sieren. Diese beiden Prozedurarten werden nur dann aufge-

behandelt er die in den vorhergehenden Teilen angekündigten Themen Assoziative Arrays, Performance, Speicherbedarf

for (i = 0; i < mx; ++i)

rufen, wenn sich der jeweilige Wert auch tatsächlich geän-

sowie weitere Möglichkeiten des Datenbankzugriffs.

{

dert hat. Die Kurzformen on signal und on sysvar entsprem.id=aNet::aNode.TX[i];

chen dabei schon den optimierten Formen, die nur auf

write(DBLookup(m).Name);

echte Flanken reagieren.

Assoziative Arrays

>>containsKey fragt ab, ob ein spezifischer Schlüssel

}

CAPL kennt keine Pointertypen und damit auch keine dynamische Speicherverwaltung, wie sie in anderen Sprachen,

bereits enthalten ist. >>size liefert die Anzahl der enthaltenen Schlüssel.

Diese Zugriffstechniken erlauben es dem Anwender, zu-

In CAPL sind alle Variablen statisch. Das heißt, sie werden

beispielsweise C, üblich ist. Dadurch ist CAPL sehr robust

>>clear leert ein Assoziatives Array komplett, während

sammen mit den zuvor eingeführten Assoziativen Arrays,

alle bei Programmstart angelegt und der Speicherplatz

bei Bedarf generische Programme zu schreiben.

erst bei Programmende wieder freigegeben. Das ist ein Un-

und auch für Ablaufumgebungen geeignet, die knapp an

remove einen einzelnen Schlüssel entfernt. Beide

Speicher und umständlich zu debuggen sind. Davon profi-

­Funktionen geben Speicher frei.

tiert insbesondere das CANoe Feature „CAPL-on-Board“,

Speicherbedarf

terschied zu den meisten blockorientierten Sprachen, wie Performance

beispielsweise C, bei denen lokale Variablen nur existieren,

das die Programme zur Verbesserung des Echtzeitverhal-

Zu guter Letzt existiert eine Spezialform der for-Anwei-

Die meisten CAPL-Programme müssen nicht-triviale Echt-

bis der sie enthaltene Block verlassen wird. Dadurch kann

tens direkt auf der Hardware bestimmter Bus-Interfaces

sung für Assoziative Arrays. Diese Form iteriert über alle

zeitbedingungen einhalten. Das Ausführungsmodell eines

CAPL überraschend viel Speicher benötigen, wenn viele

ausführt. In der zumeist verwendeten Windows-Ablaufum-

tatsächlich enthaltenen Schlüssel in lastTime:

mit CAPL simulierten Knotens verwendet sogar die Modell-

Prozeduren gleichartige große Variablen anlegen, die sie

vorstellung, dass CAPL-Programme beliebig schnell ablau-

sich eigentlich teilen könnten. Ein Beispiel:

gebung hingegen ist Speicher selten knapp. Darum können hier Daten, deren Umfang vor Programmstart nicht feststeht, mit Assoziativen Arrays gespeichert werden. Assozia-

for (long akey: lastTime) {[…]} …

tive Arrays sind Container, die den Maps oder Dynamischen

fen (siehe Teil 2 dieser Artikel­reihe). Um diesem Idealbild ausreichend nahe zu kommen, werden CAPL-Programme

testcase test789()

kompiliert, also in die Maschinensprache des je­weils aus-

{

Arrays in anderen Programmiersprachen entsprechen. In-

Zugriff auf Datenbanken

führenden Prozessors übersetzt. Außerdem werden für den

char outBuffer[1024];

tern verwendet CAPL für diese Arrays eine effiziente Hash-

Teil 1 dieser Artikelreihe hat bereits die Hauptanwendung

oft komplexen Zugriff auf Signale optimierte Codesequen-

[..]

table. Diese speziellen Arrays ermöglichen damit das Spei-

von busspezifischen Datenbanken in CAPL aufgezeigt: es

zen verwendet.

chern von Busbotschaften oder Messwerten, auch wenn

werden Namen für Botschaften und Signale eingeführt.

Nachfolgend gibt es ein paar Tipps, wie der Anwender die

Es gibt CAPL-Programme mit tausenden solcher Testproze-

vorher nicht bekannt ist, welche Botschaften oder wie viele

Das Komplizierte an Signalen aus Programmierersicht ist,

Performance beeinflussen kann.

duren, von denen stets nur eine auf einmal laufen kann. Ein

Messwerte überhaupt auftreten.

dass sie in den Nutzdaten von Botschaften aus Effizienz-

Das Deklarieren von Assoziativen Arrays erfolgt in CAPL als

gründen meistens recht eng gepackt sind. Deshalb weisen

WriteEx()

nur einmal global im variables-Abschnitt angelegt werden.

einfache Arrays, allerdings mit einem Schlüsseltyp anstatt

sie im Allgemeinen beliebige Bit-Längen und Offsets inner-

Die Funktion write dient zur Ausgabe einzelner Meldungen

Eine andere nicht sinnvolle Verwendung ist das Anlegen von

der sonst üblichen Größenangabe. Zwei Beispiele für Asso-

halb der Nutzdaten auf. Zudem lassen sie sich im Intel-

in das Write-Fenster von CANoe und CANalyzer. Für das

übergroßen Arrays, etwa um Daten von Ereignissen unter

ziative Arrays:

oder im Motorola-Format ablegen.

Ausgeben größerer Datenmengen steht als Alternative die

ihrer jeweiligen ID abzulegen. Eine extended ID bei CAN

Der symbolbasierte Zugriff über den Namen entlastet den

Funktion writeEx zur Verfügung. Mit ihr kann unter ande-

umfasst 29 Bit, kann also über 500 Millionen Werte anneh-

> long lastTime [long];

CAPL-Anwender von all diesen Details. Bei einem lesenden

rem direkt in das Trace-Fenster oder in eine Logging-Datei

men. Hierfür ein fast leeres Array zu verwenden, ist Spei-

> char[30] translate[ char[] ]

oder schreibenden Zugriff wird der nötige Code für den

geschrieben werden. Das Zeitverhalten von Meldungen zu

cherverschwendung. Besser ist es, für solche Zwecke Asso-

bit-genauen Zugriff, das Maskieren, das Drehen und das

diesen Zielen ist identisch zu dem Zeitverhalten von Buser-

ziative Arrays wie weiter oben beschrieben zu verwenden.

Der Bezeichner lastTime steht für ein Array, das long-Schlüs-

Schieben vom Compiler eingefügt.

eignissen.

Sie benötigen zwar für jedes tatsächlich verwendete Ele-

sel auf long-Werte abbildet. Während translate für eines

Datenbanken enthalten noch weitere Objekte, die dem

steht, das Zeichenkettenschlüssel (ohne Längenbegren-

Anwender in CAPL-Programmen zur Verfügung stehen. ­

Ereignisprozeduren

zung!) auf char[30]-Zeichenkettenwerte abbildet. Eine

Insbesondere lassen sich Signale symbolischen Werte­

Ein CAPL-Programm besteht aus einer beliebigen Anzahl

mögliche Anwendung von lastTime besteht darin, für jede

tabellen zuordnen. Damit sind als Werte kodierte Zustände

von Pro­zeduren, die auf Ereignisse reagieren. Einige dieser

Nützliche, aber weniger bekannte Features

auf dem Bus auftretende Botschafts-ID einen Wert abzu-

mit ihren Klarnamen nutzbar. Außerdem steht es dem Er-

Ereignisse ­ treten ausgesprochen häufig auf. Die Perfor-

Den Abschluss dieser Artikelreihe über CAPL bildet diese

legen:

steller einer Datenbank völlig frei, eigene weitere Attribute

mance eines Programmes ist daher signifikant besser,

kurze Aufzählung einiger weniger bekannter Features, die

zu definieren, die er dann im Programmcode verwenden

wenn nur die jeweils interessierenden Ereignisse verarbei-

zumeist neueren Datums sind:

kann.

tet werden. Sollten zum Beispiel nur s­ olche Slots interessie-

Mit Structs lassen sich ähnlich wie in C Strukturen definie-

Anhand der symbolischen Namen ist CAPL in der Lage, be-

ren, die ein bestimmtes Signal enthalten, ist es besser on

ren. Zusammen mit Kopieroperationen, die auch zwischen

kannte Datenbankobjekte direkt zu verwenden. Manchmal

frSlot signalname zu schreiben, als on frSlot *.

Intel- und Motorola-Format innerhalb einer struct umwan-

on message CAN1.*{ lastTime [this.id] = this.time; }

3/10

wenn sich der Wert dabei gar nicht ändert. Im Gegensatz

Puffer, etwa um Meldungen zu formatieren, sollte in diesem Fall

ment etwas mehr Speicher, brauchen dafür aber keinen Speicher für nicht verwendete Elemente.

deln können, bilden sie eine flexible Möglichkeit zur Daten-

sind die potentiell interessierenden Objekte aber beim Erstellen des Programmes noch gar nicht bekannt. Deshalb

Signalflanken

konvertierung.

Für den komfortablen Umgang mit Assoziativen Arrays

kann CAPL zusätzlich zur Laufzeit auf die Gesamtheit aller

Für Signale und Systemvariablen existieren jeweils zwei

Beim Aufruf von CAPL-Funktionen hat der Anwender die

enthält CAPL noch weitere Funktionen:

Botschaften eines Knotens zugreifen. Außerdem kann es zu

­Varianten für die Ereignisprozeduren. on signal_update und

Möglichkeit außer Werte-Parameter auch Referenz-Para-

3/11

meter zu übergeben. Wichtigste Anwendung ist die Rückgabe von mehr als einem Ergebniswert aus einer Funktion. Auch von CAPL-DLLs aus lassen sich Referenz-Parameter

Marc Lobmeyer (Dipl.-Inf.) arbeitet seit 1994 bei Vector Informatik als Entwickler an CANoe und CANalyzer.

nutzen. CAPL-Programme sollen auch bei fehlerhafter Anwendung nicht abstürzen. Diese Robustheit wird einerseits durch die Sprachstruktur erreicht, etwa indem es keine allgemeinen Pointer gibt. Andererseits verbessern automatische Laufzeittests von Array-Grenzen, Stack-Grenzen und benötigter Rechenzeit die Stabilität. Es steht eine eigene Kommandozeilenversion des Com­ pilers zur Verfügung. Diese Version ist sehr hilfreich zum ­Automatisieren von Abläufen in Skriptsprachen. Schlussbetrachtung Die vorliegende 3-teilige Artikelreihe hat CAPL als ein Beispiel für eine anwendungsbezogene Programmiersprache vorgestellt. Die vertraute Syntax der Sprache C erleichtert den Einstieg in CAPL. Spezifische Symboldatenbanken und Konzepte für das Anwenden zur Simulation, Emulation und dem Test von Feldbusknoten unterstützen die Anwendungsdomäne. Das umsichtige, kontinuierliche Erweitern der Sprache durch Vector kombiniert Kompatibilität zu Vorgängerversionen mit der Öffnung für neue Anwendungs­ gebiete. Übersetzung der englischen Veröffentlichung im CAN News­ letter, Ausgabe 4/2014.

CAPL – „Communication Access Programming ­Language“ CAPL ist eine von Vector Informatik entwickelte prozedurale, C-ähnliche Programmiersprache. Die Ausführung wird von Progammblöcken durch Ereignisse gesteuert. CAPL-Programme werden mit einem eigenen Browser entwickelt und kompiliert. Dabei kann auf alle in der Datenbasis enthaltenen Objekte (Botschaften, Signale, Umgebungsvariablen) und Systemvariablen zugegriffen werden. Darüber hinaus bietet CAPL eine Vielzahl von vordefinierten Funktionen, die das Arbeiten mit dem Entwicklungs-, Test- und Simulations-Werkzeug CANoe und CANalyzer unterstützen.

3/12

Roman Marktl (Dipl.-Ing) arbeitet seit 2012 bei Vector Informatik als Produktmanager im Bereich für CANoe und CANalyzer.

Messen/Testen/Tools Systementwicklung

Messen/Testen/Tools Systementwicklung

Alle Bilder: Vector Informatik

Bild 1: Mit der Restbussimulation ist das Testen simulierter Netzknoten im Verbund mit realen Knoten möglich.

Schnelle Wege zur Restbussimulation Virtuelle Netzwerke ohne Programmier-Know-how erstellen Eine wichtige Aufgabe beim Entwickeln von Steuergeräten kommt der Restbussimulation zu. Sie sorgt dafür, dass dem Steuergerät eine funktionsfähige Umgebung zur Verfügung steht, ohne die sich umfassende Tests kaum realisieren lassen. Die Herausforderung für Entwickler besteht darin, unter Berücksichtigung gegebener Randbedingungen zügig eine realitätsnahe Restbussimulation zu generieren. Mit den passenden Werkzeugen lassen sich Restbussimulationen ohne zu programmieren, quasi im Drag&Drop-Verfahren, erstellen. Autoren: Stefan Albrecht und Peter Decker

D

ie Zielsetzungen bei der Restbussimulation reichen vom Nachbilden einzelner Netzknoten bis zum Simulieren kompletter Netze. Aus technischer Sicht geht es darum, die Infrastruktur eines Steuergerätes über alle Schichten des OSI-Modells abzubilden. Dies erfordert eine Modellierung von der Kommunikationsschicht über das Netzwerkmanagement und die Transportschicht bis hin zur Applikationsschicht. Entsprechend vielfältig sind die bei der Umsetzung zu berücksichtigenden Aspekte und Aufgabenbereiche. Dazu gehört beispielsweise die Auswahl geeigneter Hardware für CAN-, LIN-, Flexray- und MOST-Busschnittstellen ebenso wie die Simulation von Steuergerätefunktionalitäten über Matlab/Simulink-Modelle auf den oberen Ebenen. Der simulierte Restbus muss Botschaften

3/14

58

Automobil ElEktronik 03/2012

vom zu testenden System empfangen, darauf dynamisch reagieren und die Ergebnisse in Form von Botschaften zurück an das Steuergerät senden (Stimulation). Die Restbussimulation ist somit letztlich nur Mittel zum Zweck. Sie ist stets eingebettet in ein leistungsfähiges Entwicklungs- und Testsystem, das die gewonnenen Testergebnisse auswertet und für die Dokumentation aufbereitet. Ein Beispiel dafür ist das Simulations- und Testsystem CANoe von Vector Informatik.

Konfigurieren statt Programmieren Moderne Test- und Simulationssysteme sollten sowohl verschiedene Arten der Restbusgenerierung unterstützen (automatisch, manuell, programmiert) als auch der unterschiedlichen Komplexität www.automobil-elektronik.de

einzelner Tests gerecht werden. So besteht etwa ein großer Unterschied darin, ob Entwickler eine kleine Simulation zum Testen einer oder weniger Systemfunktionen brauchen oder ob es um umfassende und detaillierte Kompletttests in der Endphase einer Produktentwicklung geht. Als Grundlage für Restbussimulationen dienen in erster Linie die Kommunikationsdaten der verschiedenen Bussysteme, die in den Datenbanken DBC (CAN), LDF (LIN), FIBEX (Flexray), Function Catalogs (MOST) abgelegt sind. Auch Diagnosebeschreibungen wie CDD und ODX gehören dazu. Möglich ist auch das Beziehen sämtlicher Daten aus einer einzigen Datenbank, wie etwa der Autosar System Description. Mit Hilfe eines geeigneten Konfigurationsassistenten und diesen Datenbasen sind Entwickler heute in der Lage, Restbussimulationen durch wenige Konfigurationsschritte zu erstellen oder sogar automatisch zu erzeugen; Programmier-Know-how ist nicht mehr zwingend notwendig. Per Drag&Drop fügen Projektmitarbeiter die Kommunikationsdatenbasen in den Simulationsaufbau ein. Das Detailverhalten einzelner Netzknoten ist anschließend modifizierbar. Einem Netzknoten können aber auch mehrere Bussysteme zugeordnet werden, was für die Simulation von Gateways und anspruchsvolleren Steuergeräten von Bedeutung ist. Eine wesentliche Rolle bei der Restbussimulation spielt die Berücksichtigung herstellerspezifischer Metadaten und Sendemodelle. Hier kommt der Interaction Layer ins Spiel, der das vom jeweiligen OEM definierte Sendeverhalten abbildet. Im Interaction Layer sind Schutzmechanismen wie beispielsweise Message Counter oder CRC-Berechnungen für jede Botschaftsart gemäß dem Sendemodell korrekt abgebildet. Der Interaction Layer übersetzt den signalorientierten Zugriff der höheren Anwendungen in die botschaftsorientierte Übertragungsweise des Bussystems. Ein weiterer wesentlicher Aspekt ist die Unterstützung verschiedener Netzwerk-Managements (NM) wie beispielsweise das OSEK-NM oder die busspezifischen Autosar-NM. www.automobil-elektronik.de

Stimulieren via Bedien-Panels und Ablaufsequenzen Zu den Anwendungen auf der oberen OSI-Ebene gehören beispielsweise Signal-Panels und Signalgeneratoren. Beim Simulieren von Benutzeraktivitäten und dynamischen Vorgängen sind sie unverzichtbare Hilfsmittel. Sie enthalten virtuelle Schalter, Knöpfe und Anzeigeinstrumente über die sich spontane Bedienvorgänge wie beispielsweise das Betätigen des Blinkers, des Scheibenwischers oder des Fensterhebers bequem am Bildschirm vornehmen lassen. Außerdem zeigen sie dem Anwender Systemparameter an und ermöglichen das gezielte Verändern von Signalen und Variablen während der Testläufe. Ein entsprechender Panel Editor zum Gestalten der Panels mit Bedien- und Anzeigeinstrumenten sowie Standard-Panels (Bild 2), die anhand der Datenbasisinformation konfiguriert sind, gehören daher zur Standardausrüstung einer State-of-the-Art-Testumgebung. Für das automatische Generieren von Simulationen und Panels beziehungsweise einer problemlosen Signalzuordnung gilt grundsätzlich: Je detaillierter die betreffenden Netze, Botschaften und Attribute in der zugehörigen Datenbank beschrieben sind, desto präzisere Modelle erstellen die Generatoren. So profitieren vorkonfigurierte Panels von allen verfügbaren Informationen, wie beispielsweise von Signalbeschreibungen, Angaben über Wertebereiche oder von symbolischen Bezeichnungen. Panels erlauben zwar das spontane und flexible Manipulieren von Signalen, sind aber nicht in der Lage, Testabläufe, Bedienvorgänge und sonstige Ereignisse reproduzierbar auszuführen. Dies ist die Domäne der klassischen Programmierung. Oft wollen Anwender jedoch nicht bei jedem Projekt mächtige Programmierwerkzeuge einsetzen. Eine willkommene Alternative für Testingenieure ist deshalb das Erstellen von Ablaufsequenzen in Form einer Tabelle (Bild 3). Diese besteht aus einfach auszuwählenden Kommandos, die ihre Aufgaben in vielen Testanwendungen gut

3/15

Messen/Testen/Tools Systementwicklung Bild 2: StandardPanels ermöglichen interaktives Ändern von Signalwerten.

Situationen zu untersuchen. Ein modernes Test- und Simulationswerkzeug bietet diese Möglichkeiten über spezielle Stressfunktionen, realisiert in Soft- und Hardware.

Restbussimulation mit CANoe Bild 3: Das grafische Erstellen von Befehlsfolgen für Stimulation und Test mit dem Visual Sequencer erfordert keine Programmierkenntnisse.

erfüllen. So lassen sich Werte setzen, Wartezeiten definieren, Signale verändern und Ereignisse auslösen. Diese Vorgehensweise erfordert weder Spezialwissen noch großen Einarbeitungsaufwand und führt über kleine reproduzierbare Tests schnell zum Ziel.

Steilvorlagen für anspruchsvolle Tests und Simulationen Aber auch große Testszenarien muss man heute nicht mehr in klassischer Manier programmieren, wenn ein Simulations- und Testsystem leistungsfähige Hilfen hierfür bereithält. Für Standardfälle gibt es beispielsweise vorgefertigte Testmuster, die für sämtliche Schritte eine Unterstützung zur Verfügung stellen: vom Aufbau der Stimulation und der Auswertefunktionen bis zur Ergebnisanalyse, der HTML-Dokumentation und der grafischen Aufbereitung. In grafischen Auswertefenstern lassen sich die jeweils interessierenden Details darstellen. Beispielsweise ermöglicht es der State Tracker von CANoe, die Zustände, Ereignisse oder Zustandsänderungen über farbliche Hervorhebungen direkt zu detektieren (Bild 4). Diese Darstellung realisiert eine Art Logikanalysator für Automobilnetzwerke beziehungsweise Steuergeräte. Wie bereits angedeutet gibt es bei der Restbussimulation in Bezug auf die denkbare Komplexität nach oben hin kaum Grenzen. Um die vielfältigen Anforderungen im Einzelnen zu erfüllen, sollte sich ein Test- und Simulationssystem durch Eigenschaften wie Skalierbarkeit und Modularität auszeichnen. Neben einer breiten Unterstützung von Busschnittstellen werden durch steigende Echtzeitanforderungen beispielsweise intelligente Hardware-Schnittstellen mit eigener Rechenleistung immer wichtiger. Sie sind in der Lage, zeitkritische Prozesse auszuführen. Eine andere Herausforderung ist das gezielte Erzeugen von Fehlern in Form von ungültigen Botschaften, fehlerhaften Nutzdaten oder Störungen auf der Busphysik, um die Reaktionen des Steuergeräts auch auf solche

Ein umfangreiches Test- und Simulationswerkzeug wie beispielsweise CANoe von Vector beherrscht alle Facetten der Restbussimulation für einfache bis umfassende Testaufbauten. Insbesondere ermöglicht es dem Anwender durch wenige Konfigurationsschritte und ohne die Notwendigkeit zum Programmieren, zügig die benötigten Simulationsmodelle manuell und automatisch zu erstellen. Das Werkzeug verarbeitet alle gängigen Datenformate, Diagnosebeschreibungen sowie Metadaten und unterstützt mit zahlreichen OEM-Paketen die Automobilindustrie. Vielfältige Zugriffsmöglichkeiten auf Botschaften, Signale und symbolische Bezeichnungen erleichtern den Steuergeräteentwicklern ihre Arbeit. Stimulationen beziehungsweise Ablaufsteuerungen lassen sich über Signal Panels, den Visual Sequencer (Bild 3), mit höheren Programmiersprachen über die .NET-API oder ein signalbasiertes CAPL realisieren. Für komplexe Testaufbauten liefert das integrierte Test Feature Set vorgefertigte Testmuster für Stimulation, Auswertung, Ergebnisanalyse und HTML-Dokumentation. High-Level-Features wie die Einbindung von MATLAB/Simulink-Modellen oder die Ausbaufähigkeit mit Zusatz-Hardware zur Simulation angeschlossener Sensoren und Aktoren ermöglichen eine Funktionalität bis hinein in den Bereich von Mid-SizeHiL-Systemen (Hardware-in-the-Loop).

Restbussimulation und Elektromobilität Auch in der Elektromobilität wird das Thema Restbussimulation zukünftig zunehmend an Bedeutung gewinnen. Durch die dynamische Entwicklung der letzten Jahre ausgelöst konzentrieren sich hier Anstrengungen verstärkt auf das Netzwerk-Management mit der Simulation des Teilnetzbetriebes. Denn Abstellzeiten sind für Elektrofahrzeuge naturgemäß gleichzeitig die Ladephasen, in denen bestimmte Steuergeräte sicher abgeschaltet werden müssen, während andere Komponenten zum Laden und Überwachen aktiv bleiben sollen. Dass das Thema Teilnetzbetrieb von Autosar 4.0 auf Autosar 3.2.1 vorgezogen wurde unterstreicht die Aktualität der Elektromobilität. (av) ■

Robuster Datenlogger im harten 24h-Rennsport-Einsatz Case Study GETRAG

Der Kunde

Die Vorteile

Mit 2,6 Millionen produzierten Getrieben gehört die GETRAG

Ein kompaktes Gerät erfasst zuverlässig alle geforderten

Corporate Group zu einem der größten Getriebehersteller weltweit. In 2008 fand die erfolgreiche Markteinführung

Bus- und Messdaten > Alle Busdaten der CAN-Kanäle werden erfasst. Zusätzlich

des GETRAG PowerShift® Doppelkupplungsgetriebes statt,

erfolgt das Aufzeichnen der Messdaten wahlweise über

das unter anderem in dem Mitsubishi Lancer Evolution X verbaut ist.

die gängigen CAN-Protokolle CCP oder XCP. > Messsignallisten sind individuell konfigurierbar > Die robuste technische Auslegung und das stabile

Die Herausforderung Zuverlässiges Erfassen und schnelles Auswerten von Mess-

Aluminiumgehäuse sorgen für Schutz bei dem Einsatz in

daten in anspruchsvoller Motorsport-Anwendung

anspruchsvollen Umgebungen. > Paralleles Aufzeichnen von GPS-Daten

Die Standfestigkeit und sportliche Eignung des GETRAG

> Der einfache und schnelle Datenaustausch ist selbst

PowerShift® Getriebes sollte während des ADAC Zurich 24h-Rennens in einem Mitsubishi Lancer Evolution X unter Beweis gestellt werden. Zur Analyse des Rennverlaufs soll-

während des laufenden Busbetriebes möglich und erfolgt via SD-Karte und gut zugänglichem Karteneinschub. > Offline-Auswertungen mit beliebigem Werkzeug sind

ten von sechs verschiedenen CAN-Steuergeräten Messdaten

möglich, auch ohne mit dem Datenlogger in Verbindung

zuverlässig und schnell auswertbar aufgezeichnet werden.

stehen zu müssen.

Die Lösung Der robuste Flottenlogger GL1000 Der GL1000 wurde als autark arbeitende Messeinrichtung eingesetzt. Er stellte sich als so robust heraus, dass er während des 24-stündigen Dauereinsatzes in dem Rennfahr-

Die Autoren: Dipl.-Ing. (FH) Stefan Albrecht ist seit 2003 bei Vector Informatik und arbeitet als Product Manager im zentralen Produktmanagement für CANoe/CANalyzer. Dipl.-Ing. (FH) Peter Decker ist seit 2002 bei Vector Informatik und arbeitet als Product Manager im Bereich Multibusentwicklung für CANoe/CANalyzer.

zeug zuverlässig alle anfallenden Messdaten einwandfrei verarbeitete. Somit hat sich gezeigt, dass der GL1000 auch in einem rauen Rennsportumfeld – das besondere Ansprüche an mechanische Robustheit stellt – problemlos einsetzbar ist. Der Logger hat durch diese Eigenschaft und durch seine einfache Konfigurierbarkeit die gestellten Anforderungen voll erfüllt.

Auf einen Blick CANoe

Bild 4: Der State Tracker zeigt grafisch Systemzustände und diskrete Werte über eine Zeitachse an.

infoDIREKT www.all-electronics.de

V2.0 | 2016-05

Ein umfangreiches Test- und Simulationswerkzeug wie beispielsweise CANoe beherrscht alle Facetten der Restbussimulation für einfache bis umfassende Testaufbauten. Insbesondere ermöglicht es dem Anwender durch wenige Konfigurationsschritte und ohne die Notwendigkeit zum Programmieren, zügig die benötigten Simulationsmodelle manuell und automatisch zu erstellen. 314AEL0312

Erschienen in Automobil Elektronik, 3/2012 3/16

60

Automobil ElEktronik 03/2012

www.automobil-elektronik.de

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

3/17

Entwicklung + Test

IIII Software-Simulation

Software-Simulation IIII

Steuergeräte modellbasiert entwickeln Matlab/Simulink ist ein in vielen ingenieurwissenschaftlichen Disziplinen verbreitetes Werkzeug. Es wird im automobilen Umfeld beispielsweise zum Modellieren dynamischer Systeme sowie für das Beschreiben von Zuständen und deren Übergängen verwendet. Da diese Algorithmen auf Steuergeräten ablaufen, die untereinander kommunizieren, ist es im VerlaufdesEntwicklungsprozessesnotwendig,denZugangzum Fahrzeugnetzwerk bereitzustellen. Von Jochen Neuffer und Dr. Carsten Böke

D

er Zugang erfolgt mittels Simulink-Blöcken, die mit der Bus-Hardware kommunizieren, direkt aus dem Modell. Daraus resultieren jedoch verschiedene Nachteile: } Das Modell ist immer netzwerkspezifisch. Zwar können durch eine intelligente Strukturierung mit Subsystemen der Netzwerk- und der Applika-

tionsanteil getrennt werden. Jedoch ist es vorteilhafter, ein generisches Modell zu haben, das sich sehr einfach auf unterschiedliche Netzwerke anpassen lässt. } Zusätzliche Protokollschichten wie Netzwerk-Management (NM), Interaction Layer (IL) oder Transport-Protokolle (TP) sowie eine Restbussimulation sind nur sehr auf-

MatlabModell

CAPLCode

realer Bus realer Knoten

simulierter Bus TP CANoe IL NM CAPL-Code

I Bild 1. CANoe-Restbussimulation mit simulierten Knoten. Elektronik automotive 3.2010 3/18

Simulink-Blockset zur Verfügung, das entsprechende Blöcke für den Datenaustausch mit CANoe bereitstellt. Es besteht im Wesentlichen aus Funktionen zum Schreiben und Lesen von Bus-Signalen, Systemvariablen und Umgebungsvariablen.

 Offline Mode für Rapid Prototyping

Software-Simulation mit Matlab/ Simulink und CANoe

CANoe

wendig in einem Simulink-Modell realisierbar. Ein einfacherer Zugang zu einem Netzwerk ist beispielsweise mit der Simulations- und Test-Software CANoe von Vector gegeben. Mit dieser Software wird typischerweise das Steuergerätenetzwerk mit den erforderlichen Knoten simuliert (Restbussimulation). Die Applikationsschicht eines Knotens, also jener Teil, der durch ein Matlab/Simulink-Modell beschrieben ist, setzt dabei auf einer reinen Signalschnittstelle auf (Bild 1). Es besteht kein Bezug mehr zum konkreten Netzwerk. Das Modell schreibt lediglich Signalwerte an seinem Ausgang beziehungsweise liest Signalwerte an seinem Eingang. Durch diese Abstraktion auf Signalebene kann der Anwender seine vorhandenen Modelle nahezu unverändert weiterverwenden. Aber nicht nur Signale lassen sich zwischen CANoe und dem SimulinkModell austauschen, sondern auch Systemvariablen. Dies sind CANoeinterne Variablen, die entweder der Benutzer explizit anlegt oder die automatisch erzeugt werden. Nach der Installation des CANoe-Matlab-Integrationspaketes von Vector steht ein www.elektroniknet.de

Entwicklung + Test

Dieser Modus ist für sehr frühe Entwicklungsphasen zu wählen, wenn am Modell noch häufig Änderungen vorgenommen werden und das real vorhandene Netzwerk noch keine Rolle spielt (Bild 2). Der Applikationsentwickler kann dennoch das Modellverhalten unter Einbeziehung des vollständig simulierten Netzwerks testen. Ein in dieser frühen Phase entwickeltes Modell kann auch in allen späteren Phasen ohne weitere Netzwerkanpassungen weiterverwendet werden. Die Simulation selbst wird im Offline Mode in der Simulink-Umgebung gestartet. CANoe arbeitet im Offline Mode, und Simulink ist der Master für die Simulationszeit. Die Simulation wird entsprechend der jeweiligen Rechnergeschwindigkeit durchgeführt. Alle Simulink-Debug-Funktionen können hierbei genutzt werden, eine reale Hardware mit CANoe-Anbindung zum Bus ist nicht notwendig.

I Bild 2. Offline Mode – Zeitbasis von Simulink.

I Bild 3. Synchronized Mode – Zeitbasis von CANoe.

langsamt und an die Echtzeit-Basis von CANoe angeglichen. Wenn das Modell jedoch in der Berechnung zu aufwendig wird, kann diese Verlangsamung nicht mehr stattfinden. Erfüllt das Modell jedoch die oben genannte Bedingung, ist in dieser Betriebsart der Zugang zu realer Hardware in vollem Umfang gewährleistet. Auch die Debug-Möglichkeiten von Simulink sind nutzbar.

 Synchronized Mode für frühe Entwicklungsphasen

 Online Mode oder Hardwarein-the-Loop Mode

Auch dieser Modus ist für frühe Entwicklungsphasen konzipiert, bei denen das Modell noch nicht seinen endgültigen Stand erreicht hat (Bild 3). Zusätzlich zum Offline Mode bietet der Synchronized Mode allerdings die Möglichkeit, reale Hardware einzubinden. Auch hier wird die Simulation in Simulink gestartet. Im Gegensatz zum Offline Mode dient jedoch die Zeit aus CANoe als Basis für die Simulationszeit, und die Simulation wird in Echtzeit gerechnet. Als Einschränkung ist hier zu erwähnen, dass das Modell nur so komplex sein darf, dass es schneller als Echtzeit gerechnet werden kann. Denn durch das Anpassen der Simulink-Zeit an die CANoe-Zeit wird die Ausführungsgeschwindigkeit in Simulink ver-

Hier wird die Berechnung des Modells komplett in der CANoe-Umgebung ausgeführt. Dazu wird aus dem Simulink-Modell eine DLL erzeugt, die in CANoe geladen und ausgeführt werden kann. Der Real-Time Workshop von Matlab/Simulink steuert hierbei die Code-Generierung. Um Code für CANoe zu erzeugen, wurde für die Real-Time-Workshop-Umgebung ein spezielles Target Makefile entwickelt, das den Generierungsprozess steuert. Mithilfe des Microsoft-Visual-StudioCompilers wird dann der generierte Code compiliert und gelinkt. Das Resultat ist eine Nodelayer-DLL, die eine CANoe-interne API implementiert und als Komponente an einen Knoten im Simulationsaufbau hinzugefügt werden kann. Andere Beispiele solcher

www.elektroniknet.de

Komponenten sind die OEM-spezifischen Interaction Layer, die Komponenten für Netzwerk-Management oder für Transportprotokolle. Diese Komponenten werden von CANoe beim Start einer Messung geladen und nach Abschluss der Messung wieder freigegeben. Die Modellausführung findet somit komplett in der Echtzeit-Umgebung von CANoe statt. Alle Ereignisse, wie Aktionen am Netzwerk, Timer oder Benutzereingaben, werden zyklusgenau berechnet. Das Modell ist Teil der CANoe-Konfiguration und kann auf einfache Weise weitergegeben werden.

 Modellberechnung in CANoe Um die Modellberechnung besser zu verstehen, ist das Verständnis des Ablaufmodells in CANoe von Bedeutung. CANoe rechnet grundsätzlich ereignisgesteuert. Ereignisse sind hierbei eintreffende Netzwerkbotschaften oder Timer. Bei jedem eintreffenden Ereignis wird die Simulationszeit in CANoe auf den Zeitstempel des jeweiligen Ereignisses gesetzt. Dabei wird die Zeitbasis abgeleitet von hochauflösenden Nicht-Windows-Timern auf den Netzwerkschnittstellen. Somit wird eine hohe Genauigkeit der Zeitstempel erreicht, obwohl CANoe unter Windows Elektronik automotive 3.2010 3/19

Entwicklung + Test

IIII Software-Simulation

Software-Simulation IIII

lieren noch parametrieren. Bei der CodeGenerierung werden hierbei für jeden Parameter im Modell Systemvariablen generiert, die CANoe anschließend liest und schreibt. Modellparameter sind typischerweise die Eigenschaften der einzelnen Simulink-Blöcke. Das kann bei einem Integratorblock sein Anfangszustand sein oder bei einem Sinus-Block dessen Frequenz, Phase, Offset oder Amplitude. Eine Systemvariable, die beispielsweise den Verstärkungsfaktor eines Simulink-Gain-Blocks repräsentiert, lässt sich dann in den Analysefenstern (Grafik, Daten, Trace) sowie Panels, CAPL-Programmen und Tests verwenden. Ein weiterer Vorteil ist die Möglichkeit zur Feinabstimmung des Modells, da interne Parameter iterativ leicht zu variieren sind.

I Bild 4. Model Viewer in CANoe.

läuft. Wird nun der Konfiguration ein generiertes Matlab/Simulink-Modell in Form einer DLL hinzugefügt, muss dieses zyklisch gerechnet werden. Wie oben erwähnt, sind auch Timer Ereignisse, welche die Simulationszeit von CANoe setzen können. In dem Modell wird also ein Timer mit genau der Zeit gesetzt, die in den Solver-Einstellungen des Simulink-Modells spezifiziert ist.

 Parametrieren des Modells Eine häufige Anforderung der Anwender ist es, das Modell nachträglich zu verändern, ohne es erneut compilieren zu müssen. Die Anwendungsfälle lassen sich folgendermaßen einteilen: } Die Modelle unterscheiden sich in den einzelnen Steuergeräte- oder Fahrzeugvarianten lediglich durch interne Parameter. Das Ändern der Parameter ist, z.B. im Rahmen von automatischen Tests, auch zur Laufzeit möglich. So können dieselben Modelle für verschiedene Fahrzeugvarianten verwendet werden. } Im Modell sind zu Simulationsbeginn bestimmte Anfangsbedingungen festzulegen, welche die eigentliche ModellLogik nicht verändern dürfen, aber in verschiedenen Testszenarien durchaus verschieden sein können. Beispiel: Es sollen die Verstärkungsfaktoren bei Regelschleifen verstellt werden, um so unterschiedliche Regelcharakteristiken zu testen. Elektronik automotive 3.2010 3/20

} Der Real-Time Workshop und/oder ein Microsoft-Compiler stehen nicht zur Verfügung, die Zeit für häufiges Neu-Compilieren ist zu lang, oder die Modelldatei selbst steht nicht zur Verfügung. So können auch Nutzer ohne Matlab/ Simulink-Installation die Modelle noch zur Laufzeit ändern. In solchen Fällen ist es sinnvoll, das Parametrieren nicht über einzeln generierte DLLs zu realisieren – ständiges, zeitaufwendiges Umkonfigurieren der Komponenten an den Knoten im Simulationsaufbau wäre die Folge. Um diesen Anwendungsfällen gerecht zu werden, lassen sich die für CANoe erzeugten Komponenten auch nach dem Compi-

Straße

 Betrachten eines Simulink-Modells in CANoe Matlab/Simulink-Modelle können in CANoe betrachtet werden, sofern sie in Form einer generierten Komponente vorliegen. Nach entsprechender Konfiguration am jeweiligen Knoten steht hierzu ein separates Fenster in CANoe zur Verfügung (Bild 4). Um das Modell nachträglich zu verändern, können alle generierten, modellinternen Parameter per Drag & Drop aus dem Modellanzeigefenster in die CANoe-Analysefenster verschoben werden. Für diese Anzeige ist keine Matlab/Simulink-Lizenz nötig.

Beschleunigskräfte: Aufbau FahrNicken werksWanken regler

Fahrwerksmodell

Fahrer Auslenkung

Auslenkung Strom

Kraftregler

Strom

Federwege

Regelparameter

Kraftregler FlexRay

I Bild 5. Modell einer aktiven Fahrwerksregelung.

www.elektroniknet.de

 Simulation einer aktiven Fahrwerksregelung mit einem FlexRay-Bus Der Entwurf einer aktiven Fahrwerksregelung inklusive eines Fahrzeugmodells dient als anspruchsvolles Beispiel. Das Fahrzeugmodell soll eine ausreichend realistische Fahrdynamik nachbilden können und mit aktiven Dämpfern als Plattform für die Fahrwerksregelung dienen. Mittels der Regelung soll ein möglichst komfortables Fahrverhalten erzielt werden. Hieraus ergibt sich die Aufteilung des Gesamtmodells in zwei Hauptblöcke: } Umgebungsmodell (Umgebungssimulation für Regler) einschließlich eines Mehrkörpermodells des Fahrzeugs (mechanisches Fahrzeugmodell), eines Modells des Antriebsstrangs (vereinfachtes Motormodell), eines Modells der Bremsen, vier Radmodellen und eines Fahrbahnmodells. } Fahrwerksregelung einschließlich Fahrzeugbeobachter, eines übergeordneten Fahrwerksreglers und vier untergeordneten Kraftreglern für die aktiven Dämpfer. Das Umgebungsmodell unterteilt sich in das Fahrzeugmodell und das Fahrbahnmodell. Das Fahrzeugmodell wird als Mehrkörpermodell mit 15 Freiheitsgraden entworfen. Dabei ist das Mehrkörpermodell symbolisch mit Hilfe eines Computer-Algebrasystems definiert, und daraus sind die Bewegungsgleichungen abgeleitet (ca. 4400 Additionen und ca. 20 800 Multiplikationen). Das Fahrzeugmodell bietet weitere Eingänge zur Stimulierung: Fahr- und Bremspedalstellung, eingelegter Gang, Lenkwinkel, Handbremsenstellung und Regler-Zielwertvorgabe (komfortabel oder sportlich). Die Übermittlung dieser Größen ist in CANoe mittels Systemvariablen realisiert. Dabei können die Fahrervorgaben durch ein Bedien-Panel mit entsprechenden Kontrollelementen interaktiv vorgegeben werden. Durch entsprechende Makroaufzeichnungen lassen sich diese auch als Fahrprofil automatisiert abspielen. Das Fahrbahnmodell wird durch eine Look-upTabelle modelliert, die für jede Position die Höhe der Fahrbahnoberfläche und die Oberflächennormale enthält. www.elektroniknet.de

Ebenso wird die Oberflächenbeschaffenheit durch ihren Reibwert an jeder Position beschrieben. Die Fahrwerksregelung besteht aus einem LQ-Regler mit Beobachter. Der Regler berechnet die Sollkräfte für die aktiven Kraftelemente in den Radaufhängungen. Dabei werden im Wesentlichen zwei Regelungsziele verfolgt: } Reduzierung der Aufbaubeschleunigungen. Ergebnis für den Pkw-Fahrer: erhöhter Komfort. } Radaufstandsfläche konstant halten (Minimierung der Variation der Radaufstandskräfte). Ergebnis für den PkwFahrer: erhöhte Sicherheit und verbesserte Fahrdynamik Der Beobachter rekonstruiert die nicht messbaren Fahrzeugzustände und nutzt dafür ein vereinfachtes lineares Fahrzeugmodell (sieben Freiheitsgrade). Der Fahrwerksregler benötigt die Wank- und Nickwinkelbeschleunigungen des Aufbaus aus zwei GyroSensoren sowie die Hubbeschleunigung des Aufbaus aus einem Beschleunigungssensor als Messgrößen. Diese Größen werden durch die Fahrzeugsimulation zur Verfügung gestellt und in CANoe ebenfalls über Systemvariablen an den Fahrwerksregler übermittelt. Der Kraftregler regelt die Kraft der aktiven Kraftelemente auf ihren von der Fahrwerksregelung vorgegebenen Sollwert. Dieser ist beispielsweise als einfacher PI-Regler für eine Stromregelung ausgelegt. In CANoe werden sechs Simulationsknoten definiert (Bild 5): Dies sind der Knoten Umgebungssimulation (Fahrzeugmodell mit Fahrwerksmodell), der Knoten Fahrwerksregler und vier Kraftregler-Knoten. Die sechs Knoten tauschen die vier Sollkräfte für die Kraftregler und die vier Auslenkungen der Radaufhängungen über einen FlexRay-Bus aus. Das zyklische Übertragen der Signale über einen Bus stellt im geschlossenen Regelkreis eine diskrete Abtastung mit einer Totzeit dar. Diese wirkt sich oft – aufgrund ihrer Unvorherbestimmbarkeit und ihrer Größe – negativ auf die Qualität der Regelung aus. Durch das Verwenden eines FlexRay-Busses werden diese Signale sehr zuverlässig und ohne Jitter übertragen. Zudem ist es möglich, diese Signale mit einer niedrigen Zykluszeit

Entwicklung + Test

(2,5 bis 5 ms) zu übertragen. Dadurch ist die Qualität der Gesamtregelung gegenüber einem CAN-Bus wesentlich verbessert. Die CANoe/Matlab-Integration ermöglicht die gleichzeitige Nutzung von Simulink zur Modellierung von komplexen Applikationsverhalten sowie die Integration des konkreten Fahrzeugnetzwerkes innerhalb des selben Entwicklungsprozesses. Der Anwender kann während der Entwicklung in seiner gewohnten Matlab/Simulink-Umgebung arbeiten und muss sich nicht um netzwerkspezifische Details kümmern. sj

Dipl.-Ing. Jochen Neuffer studierte Nachrichtentechnik an der Fachhoch­ schule Esslingen. Seit 2002 arbeitet er bei Vector Informatik und ist dort als Product Management Engineer im Bereich Tools for Network and Distributed Systems tätig. [email protected]

Dr. rer. nat. Carsten Böke studierte Informatik an der Universität Pader­ born. Von 1995 bis 2004 war er wissenschaft­ licher Mitarbeiter im Heinz Nixdorf Institut, Fachgebiet Entwurf paralleler Systeme. Seit 2004 ist er Senior Software Development Engineer bei der Vector Informatik GmbH und entwickelt dort Werkzeuge für Bus­Analyse und Bus­Simulation von FlexRay­Systemen. [email protected]

Elektronik automotive 3.2010 3/21

30

l

AUTOMOTIVE

10. 2 0 10

l

MESSEN

UND

TESTEN

IDENTISCHE TESTUMGEBUNGEN FÜR OEM UND ZULIEFERER

Lückenlose Kommunikationstests in der VAG-Steuergeräteentwicklung I n d e r S t e u e rg e r ä t e e n t w i ck l u n g s p i e l e n f ü r Z u l i e fe re r d i e O E M - s p e z i fi s c h e n Te s t i m p l e m e n t i e r u n g e n e i n e b e s o n d e re R o l l e . S i e ü b e r p r ü fe n d i e N e t z we rk ko n fo r m i t ä t , s t e l l e n d a s re i b u n g s l o s e Z u s a m m e n s p i e l d e r z a h l re i c h e n S t e u e rg e r ä t e s i c h e r u n d s i n d e i n we s e n t l i c h e s K r i t e r i u m f ü r d i e E n d a b n a h m e s e i t e n s d e s Au t o m o b i l h e rs t e l l e rs . M i t e i n e r VAG - s p e z i fi s c h e n Te s t s o f t wa re k ö n n e n E n t w i ck l e r u n d Z u l i e fe re r d u rc h e i n e a u t o m at i s i e r t e G e n e r i e r u n g vo n C A N - H i g h - S p e e d - Te s t s g e m ä ß d e r V W 8 0 1 1 8 - S p e z i fi k at i o n v i e l Z e i t u n d Ko s t e n s p a re n .

S

teuergeräte haben nicht nur die im engeren Sinne geforderte Funktionalität zu erfüllen, sondern müssen sich auch nahtlos in die Steuergeräteumgebung einfügen – unter Berücksichtigung der OEM-spezifischen Besonderheiten. Neben den Funktionstests sind daher intensive Kommunikationstests notwendig. Sie untersuchen das Steuergeräteverhalten

nicht nur unter Normalbedingungen, sondern insbesondere auch in den unterschiedlichsten Fehlersituationen. Dazu gehören Spannungseinbrüche, Empfang fehlerhafter Botschaften, Protokollverletzungen beim Senden, Unregelmäßigkeiten in den Zykluszeiten, Störungen des Buspotentials durch Kurzschlüsse und vieles mehr.

MESSEN UND TESTEN

AUTOMOTIVE

10. 2 0 10

l 31

wand lassen sich PC-basiert Testkonfigurationen für automatische CAN-Highspeed-Conformance-Tests erzeugen. Das in Zusammenarbeit mit Volkswagen entwickelte Test Package erfüllt in der Version 2.0 die neuesten Testspezifikationen. Es deckt alle von VW für die Zulieferer als obligatorisch ausgewählte Testfälle ab, die in der Spezifikation VW80118 definiert sind. Sowohl die aktuelle Version als auch die Vorgängerversion der Testspezifikation VW80118 werden unterstützt. Zum CANoe Test Package VAG gehören der Testkonfigurationsgenerator mit Konfigurationsdialog, CAPL (Communication Access ProgramBild 1: Schematischer Testaufbau des CANoe Test Package VAG. ming Language) -Testbibliotheken für UDS (Uni© automotive fied Diagnostic Services) und KWP (Key-WordProtokoll) sowie der VAG-Interaction-Layer für die Restbussimulation (Bild 2). CANoe ist also nicht nur für Definiertes Testen beim Zulieferer die eigentlichen Testabläufe verantwortlich, sondern realiDer Zulieferer trägt die Hauptverantwortung für ein korreksiert auch die notwendige Restbussimulation mit Hilfe des tes und definiertes Verhalten des Prüflings unter allen diekostenlos mitgelieferten VAG-AddOns, bestehend aus sen Randbedingungen. Die Kosten für die Testumsetzung Simulationsgenerator, Interaction Layer (IL) und Netzwerksind angesichts der steigenden Komplexität der Automomanagement (NM). Um eine vollständige Automatisierung bilelektronik nicht unerheblich. Die Testapplikationen sind zu erreichen nutzt das Test Package das VH1100 für die zu erstellen und zu pflegen oder ein Testhaus ist zu beaufSpannungsversorgung des Steuergeräts sowie das Störtragen. Letztlich erfordert jedes neue Steuergerät und jede modul CANstress (Bild 1). Modifikation ein aufwändiges Anpassen der selbst erstellten Tests. Problematisch bei dieser Vorgehensweise ist, dass die Testumsetzungen aller Beteiligten – egal ob ZulieSteuerung der Spannungsversorgung ferer, Testhaus oder OEM – in Details mehr oder weniger Bei dem VH1100 handelt es sich um eine Spannungsverdivergieren können. Liefern Tests unterschiedliche Ergebsorgung, mit dessen Hilfe das Testsystem für das zu prünisse hinsichtlich der aktuellen Testspezifikation, sind zeitfende Steuergerät verschiedene Versorgungssituationen raubende Fehlersuchen vorprogrammiert. Außerdem ist nachbildet. Es verfügt über Relais zum unabhängigen die unangenehme Frage zu klären, wer nun für die Ursache Schalten der Klemmenanschlüsse 15, 30 und 31 und verantwortlich ist. Denn Fehler müssen nicht zwingend ermöglicht exakte Messungen der Stromaufnahme des zu vom Steuergerät ausgehen, auch in der Spezifikation bzw. prüfenden Steuergeräts. Ferngesteuert lassen sich über deren Interpretation sind Lücken nicht ausgeschlossen. USB verschiedene Spannungsverläufe und Störungen Die alte Weisheit, Fehler möglichst frühzeitig zu erkennen, simulieren und so das Verhalten des Prüflings bei Überum Kostenexplosionen bei der Beseitigung zu vermeiden, bewahrheitet sich hier einmal mehr. Testen auf Knopfdruck Kostenreduktion und Qualitätssteigerung bei Steuergerätetests müssen kein Widerspruch sein, wie eine Erweiterung des Test- und Simulationssystems CANoe von Vector zeigt. Die Verwendung des „CANoe Test Package VAG“ führt VAG-Entwickler, Testhäuser und selbstverständlich auch In-houseAbteilungen beim OEM ungleich schneller zum Ziel. Auf Knopfdruck und ohne weiteren Vorbereitungsauf-

3/22

l

Bild 2: Auf Knopfdruck erstellt das CANoe Test Package VAG eine komplette Test-Konfiguration, startet den Testablauf und generiert einen Report.

© automotive

3/23

l

AUTOMOTIVE

10. 2 0 10

l

MESSEN

UND

TESTEN

Übersichtliche HTML-Testreports In Abhängigkeit von der Anzahl der Sendeund Empfangsbotschaften werden mehrere hunderte Testfälle generiert (Bild 3). Jeder Testfall liefert einen ausführlichen HTML-Testreport sowie Log-Dateien im ASCII-Format. Die Testreports sind in Kapitelnummern untergliedert, die den Bezeichnungen in der VAG-Testspezifikation entsprechen. Durch die farbliche Hervorhebung von Fehlern gewinnen die Anwender einen schnellen Überblick über Erfolg oder Misserfolg der durchlaufenen Testfälle.

Bild 3: Ablaufsteuerung des VW80118-Tests.

spannungen, Unterspannungen bzw. Spannungseinbrüchen ausloten. Zum Simulieren von digitalen und analogen Störungen auf dem CAN-Bus dagegen dient das USB-Hardwaremodul CANstress. Es wird direkt in die Busleitung geschaltet und beeinflusst reproduzierbar die physikalischen Eigenschaften und logischen Pegel. Eine flexible Trigger- und Störlogik ermöglicht das gezielte Zerstören von CAN-Botschaften an beliebigen Bit-Positionen und die Manipulation von Bit-Feldern. Hier leistet die volle Fernsteuerbarkeit über COM (Component Object Model) einen wertvollen Beitrag zur Automatisierung der VAG-Tests. OEM liefert Testgrundlage an Zulieferer Zu den wichtigen Voraussetzungen für die erfolgreiche Konfiguration der Testumgebung gehört eine konsistente Kommunikationsbeschreibung des Steuergerätes in Form der TBD-Datei (Test Basis Dokumentation) sowie die CANNetzwerk-Datenbasis (DBC). Beide Dateien werden vom OEM erstellt und an den Zulieferer weiter gegeben. Während in der DBC-Datei die OEM-spezifischen Informationen über das Netzwerk und die Restbussimulation gespeichert sind, enthält die TBD-Datei detaillierte Angaben über das Steuergerät. Sie ist für jedes Steuergerät neu zu erstellen und gibt im XML-Format Auskunft über Steuergeräteinformationen. Diese Informationen enthalten Sende- und Empfangsbotschaften, Diagnoseparameter, Diagnostic Trouble Codes (DTCs), Spezifikationsversionen usw. Die TBD-Datei liefert somit die notwendigen Informationen über ein VAGSteuergerät, um die VW80118-Tests korrekt zu konfigurieren. Diese Datei kann auch vom Zulieferer - mit Hilfe eines von VAG bereitgestellten Editors – beispielsweise um DTCs ergänzt werden. Der Testkonfigurationsgenerator liest die TBD- und DBC-Dateien und erzeugt daraus die CANoe Testkonfiguration (Bild 2), bestehend aus der Restbussimulation und einem XML-Testablaufmodul.

3/24

Fazit und Ausblick Das CANoe Test Package VAG bildet zusammen mit der Test Hardware VH1100 sowie dem CANstress-Modul eine kostengünstige Testumgebung auf © automotive der Basis von CAN-Standard-Werkzeugen. Die beschriebene Lösung versetzt Entwickler, Zulieferer und Testhäuser in die Lage, mit minimalem Aufwand die gleichen Tests wie der OEM durchzuführen. Die automatisierten Konfigurationserstellungen und Testabläufe sparen Zeit und reduzieren Entwicklungskosten. Gleichzeitig profitieren OEM und Zulieferer von frühzeitiger Fehlererkennung, weniger Iterationen und einer Qualitätsverbesserung. Das CANoe Test Package VAG ist das einzige am Markt verfügbare Testsystem, das von VW für die CAN-HighSpeed-Conformance-Tests zertifiziert ist und explizit für die Tests im Haus der Zulieferer empfohlen wird. Eine Erweiterung der bestehenden Lösung um weitere weltweit geltende VAG-Testspezifikationen - wie zum Beispiel für Netzwerkmanagement-Botschaften (NM-High) - ist für die nächste Version bereits eingeplant. (oe)

Integration virtueller Hardware-Prototypen in CANoe Case Study Fraunhofer-Institut für Integrierte Schaltungen IIS

Der Kunde

Die Vorteile

Das Fraunhofer-Institut für Integrierte Schaltungen IIS ist eine der wichtigsten deutschen Forschungseinrichtungen

Komponentenspezifikationen ohne Hardware-Prototypen > Sehr frühzeitige Tests zur Integrierbarkeit in das System

für die Entwicklung von mikroelektronischen Systemen und

> Einsparung von Kosten und Zeit für Hardware-Proto-

Software. Die Wissenschaftler im Institutsteil Entwurfs-

typing > Ansteuerung des virtuellen Prototypen mittels CANoe ist

automatisierung EAS in Dresden entwickeln zuverlässige Methoden und Werkzeuge für den Entwurf komplexer elektronischer und mechatronischer Systeme.

identisch mit der Ansteuerung der realen Hardware > Verbindung des virtuellen Prototypen mit realer Hardware; so kann z. B. ein virtuelles Steuergerät schon in der

Die Herausforderung

Spezifikationsphase an das Bussystem angeschlossen

Beherrschen des komplexen Entwurfsprozesses elektro-

und getestet werden

nischer Systeme der Automobiltechnik

> IP-geschützter Modellaustausch

Bei der Entwicklung von elektronischen Komponenten für

> Aufdeckung von Konzept- bzw. Architekturproblemen

die Automobiltechnik müssen vom Halbleiterhersteller über den TIER1 bis zum OEM verschiedenste Partner zusammenarbeiten. Dabei stellen speziell die Spezifikationen der Einzelkomponenten eine große Herausforderung dar: Der Systemlieferant muss nach diesen Vorgaben seine Systemspezifkation erstellen und benötigt zur Validierung einen Hardware-Prototypen, der zu diesem Zeitpunkt nicht immer verfügbar ist. Die Lösung Integration von SystemC/SystemC-AMS basierten virtuellen Prototypen in die CANoe Plattform SystemC/SystemC-AMS ist eine in der Halbleiterindustrie

Gavin C. Rogers B.Eng. M.Sc. ist bei Vector Informatik Team Manager in der Produktlinie “Tools for Networks and Distributed Systems” und Produkt Manager für CANoe Test Packages.

weit verbreitete Systemmodellierungssprache, die es ermöglicht, abstrakte und somit sehr schnell zu simulierende Modelle für die unterschiedlichen Hard- und Software-Komponenten eines Systems zu erstellen. Solche Modelle können kompiliert und an Partner und Kunden geliefert werden,

Beispielhafter Simulationsaufbau

ohne internes Know-how preiszugeben. Das vom BMBF geförderte Projekt AutoSUN demonstriert, wie sich vom TIER1 oder TIER2 gelieferte Modelle in die beim OEM verwendete Dipl. Inform. (FH) Klaus Theobald ist bei Vector Informatik Senior Software Development Engineer in der Produktlinie "Tools for Networks and Distributed Systems" und hat das VAG Test Package entwickelt.

CANoe Plattform integrieren lassen. Dazu wird die CAPLSchnittstelle verwendet und die zeitliche Synchronisation zwischen der SystemC-AMS Simulationszeitachse und der CANoe Zeit realisiert. Das SystemC-AMS Modell wird dafür zusammen mit der Synchronisationsbibliothek zu einer DLL

V2.0 | 2012-01

32

gelinkt. Somit ist es möglich, das Modell kompiliert und

@

Vector Informatik www.vector.com

somit IP geschützt auszutauschen.

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

3/25

Entwicklung + tEst

Entwicklung + tEst

Prüfstand für komplexen Steuergeräteverbund Je nach Aufgaben und Funktionsumfang können Steuergerätetests komplex ausfallen. Das trifft umso mehr zu, wenn ein Verbund aus fünf bis neun Steuergeräten auf einmal zu testen ist, deren Funktionen untrennbar miteinander verbunden sind und in Abhängigkeit von Fahrzeugtyp, Ausstattung und Kundensonderwünschen variiert. Dafür hat die EvoBus GmbH einen Komponentenprüfstand auf Basis des VT-Systems von Vector Informatik in Betrieb genommen. Das Ergebnis: Flexible, automatisierbare Tests ermöglichen eine hohe Testabdeckung sowie eine genaue Reproduzierbarkeit aller Testfälle. Von Katja Hahmann, Michael Schneider und Philipp Merkle

Informationen zu EvoBus Seit 1995 sind unter dem Dach der EvoBus GmbH die beiden Omnibus-Marken MercedesBenz und Setra vereint. EvoBus gehört als Tochterunternehmen der Daimler AG zum Geschäftsfeld Bus. Mit einem Marktanteil von 50 Prozent in Deutschland und von 21 % in Europa ist Daimler Marktführer im Bereich Busse über 8 Tonnen.

Elektronik automotive 10.2012 3/26

I

m Omnibusbereich gilt der Anspruch, mit den technischen Bedingungen eines Nutzfahrzeuges ein Fahrzeug zu erstellen, das in Hinblick auf Komfort einem Pkw in Nichts nachsteht. Im Fokus befindet sich die Entwicklung von Plattformen, die bis zu 120 Funktionen auf einer gemeinsamen Hardware abbilden. Die Komplexität reicht dabei von sehr einfach bis sehr komplex. Zahlreiche Kombinationsmöglichkeiten einzel-

ner Funktionen miteinander sind eine weitere Anforderung. Ein hoher Anspruch an Individualität und die Berücksichtigung spezifischer Kundenwünsche, teilweise sogar noch kurz vor Auslieferung, erfordern eine hohe Modularität und Flexibilität der Architektur im Bereich der Aufbau- und Komfortelektronik. Bei den im Vergleich mit der Pkw-Industrie niedrigen Stückzahlen ist eine Wiederverwendung in allen Baureihen (Stadt-, Überland- und Reisebusse) erwünscht. Durch vereinheitlichte, adaptierbare Hardware lassen sich Synergieeffekte nutzen und Kosten reduzieren. Die E/E-Anforderungen bei Bussen unterscheiden sich in einigen Punkten erheblich von denen im Pkw-Bereich, weil die Ausstattungen eines Omnibusses weitaus mehr von individuellen Kundenwünschen bestimmt sind. Dieser Fakt ist auf Seiten des E/E-Konzepts zu berücksichtigen und erfordert eine durchdachte Modularität und Flexibilität. Die Elektronik(-Hardware) soll innerhalb der gesamten Omnibus-Produktpalette möglichst breit einsetzbar

und jeweils kostengerecht adaptierbar sein. Zu den weiteren Herausforderungen zählen die Reduktion von Kraftstoffverbrauch und Abgasemissionen sowie die Weiterentwicklung aktiver und passiver Sicherheits- und Assistenzsysteme. Um diese Forderungen flexibel im E/E-Konzept abzubilden, hat EvoBus ein skalierbares Multiplexsystem, das MuxSystem, entwickelt. Aus bis zu neun Modulen bestehend, bildet dieses System innerhalb der Elektronikarchitektur eine Art verteiltes System im verteilten System. Hard- und Firmware des MuxSystems sind wie Middleware zu betrachten, die die Grundlagen und Werkzeuge zur Applikationsentwicklung bereitstellt. Diese Middleware ist dank IEC-61131-konformer und herstellerspezifischer Logikbausteine frei programmierbar und unterhalb der Anwendungsebene positioniert. Die einzelnen Mux-Module sind auf verschiedene Busstränge des gesamten Fahrzeugnetzwerks verteilt, bestehend aus fünf Haupt-CAN-Bussen für die Bereiche Antriebsstrang, Fahrwerk, Innenraum, Telematik und Diagnose sowie zahlreiche LIN-Subnetze.

geht es um die korrekte Funktionsweise der Middleware; die Applikation wird später im Testprozess betrachtet. Das Mux-System selbst ist ein skalierbares Peer-to-Peer-System. Die Anzahl der im Fahrzeug verwendeten Mux-Module ist abhängig von den gewählten Ausstattungsvarianten und Kundensonderwünschen. Jedes Mux-Modul verfügt über eine Anzahl weitgehend konfigurierbarer digitaler und analoger Einund Ausgänge. Über die CAN-Busse sind die Mux-Module zu einem Gesamtsystem verbunden (Bild 1). Mit Hilfe des VT-Systems testen die EvoBus-Ingenieure die Grundlagen für umfangreiche Funktionen, wie eine Ventilsteuerung für die Niveauregulie-

MUX 1

Umgebungen simulieren und Tests automatisieren Das Mux-System ist weiterhin daraufhin zu testen, ob es mit Hardware-Änderungen einwandfrei arbeitet. Testinhalte sind u.a. das Daten- und DiagnoseRouting zu den Sub-CAN- und Sub-LINBussen des Mux-Systems. Ein besonderes Augenmerk ist auf den Test der Di-

Digitales Schaltfeld

SMLAnforderung SML = an

MUX 2

Zentrales Gateway

CAN/Innenbereich

Steuergeräteverbund aus bis zu neun Modulen Aufgrund der hohen Funktionsdichte und der Vielzahl von Freiheitsgraden bei der Konfiguration des Mux-Systems ist der Testumfang besonders hoch. Um die zeitintensive und aufwendige Testphase zu optimieren, hat EvoBus 2011 einen individuell für die Belange des Mux-Systems zugeschnittenen Prüfstand in Betrieb genommen. Der Prüfstand basiert auf dem VT-System von Vector Informatik. Dieser ist in der Lage, sämtliche Komponenten und Systemzustände der Mux-Umgebung zu simulieren, die für die Tests erforderlich sind. Dazu gehören sowohl die Signale der zahlreichen Hardware-Ein-/-Ausgänge als auch die CAN- und LIN-Kommunikation. Als Benutzerschnittstelle dient ein PC mit der Test- und Simulations-Software CANoe von Vector. Der Komponententest stellt nach den Tests beim Zulieferer den ersten Schritt in der Testprozesskette innerhalb des V-Modells dar, die vom Komponententest über Software-Modul-Tests, Hardware-in-the-Loop bis hin zum Versuch im realen Fahrzeug reicht. Dabei

Mux-Geräte informiert sein muss, finden fortlaufend Synchronisationsprozesse statt. Beim Austauschen der Prozessabbilder sind vorgegebene Timing- und Echtzeit-Vorgaben zu erfüllen, was ein weiteres Prüfkriterium darstellt.

SML = an

SML = an

CAN/Fahrwerk MUX 3

MUX 4 CAN/Außenbereich CAN-Botschaft zum Anschalten der Seitenmarkierungsleuchte (SML) Bild 1. Beispiel einer verteilten Funktion im Mux-System – Seitenmarkierungsleuchte. rung, Klappensteuergeräte für Gepäckraum und Motorraumklappen oder die komplexe Innenbeleuchtung. Letztere lässt viel Freiraum für kundenspezifische Wünsche. Eine wesentliche Herausforderung ist das Netzwerk-Management: Statusübergänge, beispielsweise das Aufwachen aus dem PowerDown-Modus und umgekehrt, das Herunterfahren des Netzwerks müssen zuverlässig in korrektem Zusammenspiel mit Applikation und Hardware ablaufen. Dazu wird neben der CANKommunikation des Restbusses auch das OSEK-Netzwerk-Management simuliert. Da jedes Mux-Modul stets zeitnah über die Systemzustände der anderen

agnosefunktionen zu richten: Die I/OKanäle des Mux-Systems erlauben eine flexible und vielfältige Konfiguration des Diagnoseverhaltens. Dementsprechend groß ist die Anzahl an Diagnosetestfällen. Allein zum Test der FehlerCodes des Mux-Systems sind derzeit 1.000 der wichtigsten Testfälle umgesetzt. Die Varianz des Systems ermöglicht jedoch sogar mehr als das Zehnfache an Permutationen. Manuell ist diese Aufgabe nicht wirtschaftlich zu leisten. Mit dem VT-System kann diese Prüfung innerhalb weniger Stunden automatisiert und dokumentiert werden. Die Komplexität und Vielfalt der Mux-Tests lässt sich nur durch eine konElektronik automotive 10.2012 3/27

Entwicklung + tEst

sequente Automatisierung der Testabläufe ökonomisch sinnvoll bewältigen. Das im 19-Zoll-Industrieformat modular aufgebaute VT-System ist für die charakteristischen Aufgaben der Testautomatisierung optimiert und ermöglicht Konfigurationen vom kompakten Tischgerät mit sechs Einschüben bis hin zum HiL-System für das Testlabor (Bild 2). Das VT-System realisiert eine umfassende Emulation der Steuergeräteumgebung hinsichtlich Ein- und Ausgangsbeschaltung sowie der Kommunikation auf den angeschlossenen CAN-/LIN-Bussen. Der Hauptvorteil der Emulation besteht darin, dass sich das Verhalten von Fahrern, Fahrgästen, der Fahrzeugtechnik oder der sonstigen Umgebung reproduzierbar nachbilden lässt. Das Testen der Türsteuerung erfordert beispielsweise ein wiederholtes Betätigen des Druckknopfes zum Öffnen der Omnibustür zu genau definierten Zeiten. Statt einer manuellen Betätigung werden diese Aktionen durch das Testsystem ausgeführt; damit ist der zeitliche Ablauf sichergestellt und jederzeit reproduzierbar.

Entwicklung + tEst

verfügt außerdem über ein Steckfeld, über das sämtliche Eingangs-Pins der Mux-Steuergeräte separat für manuelle Messungen zugänglich sind; des Weiteren sind alle CAN-/LIN-Busse ebenfalls über Break-out-Kontakte herausgeführt. Umfangreiche Steuergerätetests schließen in der Regel auch Testabläufe ein, bei denen vom Normalbetrieb abweichende Bedingungen vorherrschen. Das VT-System ist aus diesem Grund in der Lage, definierte Fehler in der Steuergeräte-Umgebung zu generieren, zum Beispiel defekte Sensoren an den Eingängen oder untypisches Lastverhalten der an den Ausgängen ange-

Skalierbares Testsystem ermöglicht individuellen Hardware-Aufbau Das System unterstützt alle gängigen analogen und digitalen Ein- und Ausgangsstandards, inklusive komplexer Funktionen wie das Erzeugen und Verarbeiten von PWM-Signalen oder das Bestimmen von Effektivwerten. Während Last- und Messmodule vom Typ VT1004 an die Ausgänge eines Steuergeräts angeschlossen werden, enthalten die Module mit der Bezeichnung VT2516 und VT2004 die Elektronik zur Stimulation digitaler und analoger Eingänge. Die Stromversorgungsmodule VT7001 steuern die Betriebsspannungen und messen die Stromaufnahme der Mux-Module. Weiterhin werden VT6104- Module für die Netzwerkkommunikation der CAN- und LIN-Netzwerke verwendet. Das PC-Modul VT6050 ist der CANoe-Realtime-PC, auf dem die Simulationen und Tests ausgeführt werden. Allein die Ein-/Ausgabeebene des in einem 19-Zoll-Schaltschrank aufgebauten EvoBus-Prüfstands besteht aus fünf logischen Ebenen, die mit jeweils zwölf VT-System-Modulen voll bestückt sind. Derzeit deckt das System die Anforderungen für fünf der neun möglichen Mux-Module ab. Der Schaltschrank Elektronik automotive 10.2012 3/28

Bedien-PC mit CANoe Ethernet VT-System CANoe RealTime: - Restbussimulation - Testausführung

Echtzeitfähigkeit durch modularen Systemaufbau Die Restbussimulation verwendet das OEM-Package für den Daimler-spezifischen Interaction Layer und das OSEKNetzwerk-Management. Dadurch lässt sich eine vollständige Nachbildung des Sende- sowie des realitätsnahen Kommunikationsverhaltens auf den Datenbussen mit niedrigem Aufwand sicherstellen. Echtzeitrelevante Aufgaben, wie die Restbussimulation und die Testsequenzen, werden direkt auf dem Realtime-Modul VT6050 ausgeführt. Das VT6050 ist wiederum über Ethernet mit dem CANoe-Bedien-PC verbunden, über den die Benutzerinteraktionen sowie die Beobachtung und Analyse laufen. Diese Arbeitsteilung leistet einen wichtigen Beitrag zu der außergewöhnlich hohen Skalierbarkeit des gesamten Testsystems (Bild 3).

CANoe als Front-End für Prüfstand

Bild 2. VT-System als Komponentenprüfstand des Mux-Systems von EvoBus.

Ausbau des EvoBus-Prüfstands geplant

schlossenen Aktoren. Auf Wunsch erzeugt das System Leitungsbrüche und Kurzschlüsse in Zuleitungen, Kurzschlüsse nach Masse und Batteriepotential oder Über- und Unterspannungen. Es gibt fünf elektronische Lasten, die jeweils einen Strom von 10 A als Quelle oder Senke führen können.

Das Standardwerkzeug CANoe auf dem Arbeitsplatz-PC dient als Plattform für alle Bedienvorgänge, Testdefinitionen und Auswerteaktionen. Die Zweischirmkonfiguration bei EvoBus stellt genügend Raum zur Verfügung, um beispielsweise die Fenster des Hauptpanels, der Ausgangs-Pins, Eingangs-Pins oder Messwertanzeigen übersichtlich darzustellen. CANoe hat sich in der Elektronikentwicklung rund um Automotive-Anwendungen als Industriestandard etabliert und stellt zahlreiche Funktionen zur Verfügung, von denen die Mux-Tests profitieren. Die Einarbeitung in die Bedienung des Prüfstands verläuft aufgrund des intuitiven Nutzer-Interfaces zügig und reibungslos. Sämtliche Parameter des VT-Systems sind von CANoe aus zugänglich. Mit dem Test-Feature-Set erfüllt Vector die Forderung nach einer leistungsfähigen Testautomatisierung. Darüber lassen sich Testsequenzen definieren, Tests ausgeführen und Reports erzeugen. Beim Generieren und Aus-

MUXSystem beim Test

Netzwerkmodul (CAN, LIN)

CAN, LIN 5 ...

I/O-Module

I/O

Steuerung MUXStromversorgung Elektronische Lasten

Bild 3. Schemadarstellung: Aufbau des Mux-Testsystems. führen reproduzierbarer Testfälle für das Diagnoseprotokoll leistet die CANoe-Option Diagnostic Integration and Validation Assistant, kurz DiVa, wertvolle Dienste. Der Test-Automation-Editor enthält eine Schnittstelle zu einer DOORS-Datenbank, in der die Testspezifikation hinterlegt ist. Nach Testausführung auf dem VT-System lassen sich die Ergebnisse im XML-Format in die Datenbank zurückdokumentieren und sichern. Eine Nachverfolgbarkeit von Auffälligkeiten, deren Korrektur sowie statistische Informationen über das Testobjekt sind so für jeden Musterstand sichergestellt. Für EvoBus spielten eine durchgängige Werkzeugkette und eine minimierte Anzahl von Schnittstellen eine wichtige Rolle. Diese Anforderungen finden sich im Vector-Konzept wieder, von der Definition der Testanforderungen über die Ausführung bis hin zur Auswertung der Reports. Mit dem VT-System ließ sich die Effizienz beim Testen des Mux-Steuergeräteverbundes erheblich steigern. Umfangreiche Tests, die einschließlich der Bereitstellung der spezifischen TestSoftware bisher rund zwei Wochen dauerten, lassen sich jetzt in einem Tag abschließen. Die Pins der Steuergeräte

(Bilder: Vector Informatik)

wurden früher auf speziell angefertigte rein passive Prüfboxen geführt, die für jeden einzelnen Test manuell zu beschalten waren. Weil diese Vorgehensweise nicht automatisierbar ist, stehen weniger Testmöglichkeiten zur Verfügung. Obendrein ist sie fehleranfälliger. Waren Tests zu wiederholen, wurden personelle Kapazitäten ein weiteres Mal für längere Zeit gebunden. Mit dem VT-System ist das Reproduzieren von Testläufen auf Knopfdruck möglich. Bei größerer Testtiefe, Testabdeckung und Genauigkeit erreicht EvoBus heute 500 Einzeltests ohne Diagnose. Vorher wurden nur etwa 100 stichprobenartige Tests durchgeführt. Ein herausragendes Merkmal ist die neu gewonnene Flexibilität. Der VT-Prüfstand kommt nicht nur zum automatisierten Testen bei neuen Software-Versionen zum Einsatz. Er dient auch als Analysewerkzeug bei der Rückmeldung von Auffälligkeiten in Kundendienst und Produktion. Solche Situationen erfordern eine zeitnahe Reaktion. Daher lässt sich die Hardware auch ohne das Schreiben von Testskripten über eine CANoe-Oberfläche manuell und spontan einsetzen, um Probleme zu ergründen und zu beheben.

Das VT-System bei EvoBus ist mit dem voll ausgebauten, etwa zwei Meter hohen Schaltschrank eines der größeren realisierten VT-System-Projekte von Vector. Der Zeitrahmen von der Spezifikationsphase bis zur Inbetrieb- und Einlernphase hat etwa fünf Monate umfasst. Die fortschreitende Entwicklung neuer Fahrzeugbaumuster sowie hybrider Antriebe macht es notwendig, das Prüfsystem zu erweitern. Die Erweiterung des Prüfstands um ein zusätzliches Ein-/Ausgabe-Modul ist von EvoBus vorgesehen. Der Prüfstand kann dann Mux-Systeme mit bis zu sechs Modulen testen. Dabei wird es notwendig sein, das System um einen zweiten Schaltschrank zu ergänzen. Das stellt einen Zwischenschritt zum Vollausbau des Systems auf neun Module dar. Die Ausstattung großer Reisebusse kann beachtliche Dimensionen annehmen, wobei die Elektronik der Komfortfunktionen, Klimatisierung, Innenbeleuchtung, verteilten Funktionen für Hybridfahrzeuge, schnellen Türöffnungs- und -schließmechanismen oder Entertainment-Systeme sorgfältiger Tests bedürfen. eck

Dipl.-Ing. Katja Hahmann studierte Elektrotechnik an der TU Chemnitz. Sie trat 1997 in die Vector Informatik GmbH ein und ist dort Gruppenleiterin der CANoe Anwendungsentwicklung für Networks and Distributed Systems.

Dipl.-Ing. Michael Schneider studierte Allgemeine Elektrotechnik an der Ruhr-Universität Bochum und an der RWTH Aachen. Er ist seit 1998 Systementwickler im Bereich Basissysteme bei DaimlerBuses.

Dipl.-Ing. (FH) Philipp Merkle studierte Industrieelektronik – Fachrichtung Fahrzeugelektronik an der Hochschule Ulm. Er ist seit 2007 Test-Ingenieur für Zentralelektroniken bei DaimlerBuses.

Elektronik automotive 10.2012 3/29

Entwicklung + Test

Steuergerätetest llll

llll Steuergerätetest

wirkt ein niedriger Reifendruck durch die größere Verformung bei Bedarf eine bessere Selbstreinigung der Reifen.

ˆ Modellbasierte Weiterentwicklung der Reifendruckregelanlage Das erfolgreiche Elektronikkonzept der Unimog-Baureihen wird aufgrund der Anforderungen an Leistungsfähigkeit und Bedienkomfort derzeit weiterentwickelt. Die Weiterentwicklung der Reifendruckregelanlage umfasst bei der nächsten Generation eine modellbasiert entwickelte Applikation auf einer neuen leistungsfähigeren HardwarePlattform. Für den Fahrer bedeutet das eine Erhöhung des Bedienkomforts: Im Automatik-Modus wählt er lediglich

(Bild: Daimler AG)

Hardware-Simulation bei der Unimog-Reifendruckregelanlage Zeitersparnis und neue Möglichkeiten durch Steuergerätestests am Modell Erhöhen der Traktionsleistung, Minimieren des Treibstoffverbrauchs und Vermeiden von Flurschäden: Das sind gute Gründe für geländegängige Nutzfahrzeuge, stets mit angepasstem Reifendruck zu fahren. Für realitätsnahe Tests der nächsten Generation der Reifendruckregelanlage von geländegängigen Unimog-Fahrzeugen haben Entwickler der Daimler AG ein neuartiges Testsystem verwendet. Es simuliert sämtliche Sensoren und Aktoren der Steuergeräteumgebung und ermöglicht umfassende HiLTests, einschließlich der Nachbildung von Fehlersituationen in UmgebungsHardware und Verkabelung. Von Katja Hahmann und Mario Wirmel

A

m Standort Wörth am Rhein befindet sich eines der größten LKW-Werke Europas. Neben der Produktion der bekannten Mercedes-Benz Trucks Atego, Axor und Actros entwickelt und fertigt hier die Daimler AG Sonderfahrzeuge wie Unimog, Econic und Zetros. Elektronik automotive 6.2010 3/30

Die Produktlinie Unimog U3000/ 4000/5000 erreicht mit Portalachsen, Schraubfedern, zuschaltbarem Allradantrieb und Schubrohrtechnik eine extreme Geländegängigkeit, die durch eine Watfähigkeit bis 1,20 m ergänzt wird (Bild 1). Als Antrieb kommen emissionsarme Dieselmotoren mit Leistun-

gen von 110 kW (150 PS) bis 160 kW (218 PS) zum Einsatz. Als Sonderausstattung bietet Mercedes-Benz unter anderem die Option „tirecontrol“ – eine elektropneumatische Anlage zur Reifenbefüllung und -entlüftung, die dem Fahrer erlaubt, vom Führerhaus aus den Reifendruck zu verändern. Während hoher Reifendruck auf der Straße für geringen Rollwiderstand und Treibstoffverbrauch sorgt, stehen beim Fahren im Gelände andere Eigenschaften im Vordergrund. Durch ein Verringern des Reifendrucks lässt sich beim Fahren auf weichem Untergrund der Aufstandsdruck derart verkleinern, dass keine nennenswerten Flurschäden entstehen (Bild 2). Auch hinsichtlich der verfügbaren Traktionsleistung besteht ein direkter Zusammenhang zwischen Bodenbeschaffenheit und verwendetem Reifendruck. Durch Senken des Reifendrucks im Gelände kann eine Verdoppelung der Zugkraft erreicht werden. Für den Erfolg oder Misserfolg einer Aufgabe kann das ein entscheidender Faktor sein. Zudem bewww.elektroniknet.de

l Bild 1. Geländegängigkeit steht bei Unimog im Vordergrund. (Bild: Daimler AG)

den Geländetyp aus, woraufhin die Anlage mittels einer Vierkanal-Pneumatik automatisch für den korrekten Druck in allen Reifen sorgt.

PC-basierte MiL-Tests Für die neue Reifendruckregelanlage wurde zunächst auf Basis von Messdaten und Konstruktionsunterlagen ein Modell der neuen Pneumatik inklusive Reifen (Streckenmodell) erstellt und verifiziert. Danach erfolgten die ersten Implementierungen des Applikationsmodells. Für die Erstellung der Matlab/ Simulink-Modelle beauftragte Daimler die Firma ITK Engineering. Die Modelle bilden das dynamische Verhalten der realen Anlage wirklichkeitsgetreu ab. Drucksensoren erfassen kontinuierlich den Druck der einzelnen Reifen, die über eine zentrale Luftdurchfühwww.elektroniknet.de

rung in den Portalachsen ständig mit dem Pneumatiksystem verbunden sind. Ein weiterer Sensor dient dem System als Referenz und verifiziert automatisch die fest zugeordneten Sensoren. Aktuelle Drücke, die Kompressorleistung und Leitungsquerschnitte sind ebenfalls im Modell enthalten. Diese Zusammenhänge, einschließlich der beim Erhöhen und Verringern des Reifendrucks wirksamen Zeitkonstanten, werden im Modell exakt berechnet. So sind in dieser Entwicklungsphase bereits PC-basierte Model-in-the-LoopTests (MiL-Tests) möglich.

Simulink-Modelle in SiL-Tests Der modellbasierte Ansatz wird auch in den weiteren Entwicklungsphasen verfolgt. Durch die Integration der Modelle in das Simulations- und TestWerkzeug CANoe von Vector wird das Modellverhalten im Zusammenhang mit der Buskommunikation getestet. Mit dem CANoe-Blockset für Matlab/ Simulink werden die Modellschnittstellen direkt an Bussignale, System- oder Umgebungsvariablen angebunden. Der Simulink Real-Time Workshop erzeugt eine Windows-DLL, die in die CANoeSimulations-Umgebung geladen wird. Der CANoe Interaction Layer sorgt für das Versenden der Botschaften entsprechend dem in der Datenbasis hinterlegten Sendeverhalten. Zuletzt werden die Testabläufe mit dem CANoe Test Feature Set erstellt und automatisch durchgeführt. Anschließend erfolgen erste Tests im Fahrzeug. Bisher waren diese Tests erst mit der Verfügbarkeit von Prototyp-Steuergeräten oder RapidPrototyping-Plattformen möglich. Durch den Einsatz von CANoe mit dem integrierten Applikationsmodell kann das Bedien- und Anzeigekonzept im Fahrzeug geprüft werden, ohne dass dafür ein spezieller Hardware-Aufbau benötigt wird. CANoe ist für die CANKommunikation zum Fahrzeug zuständig. Ein Sensor-/Aktor-Modul, in diesem Fall das bisherige Steuergerät, stellt die I/O-Funktionen über CAN im Fahrzeug zur Verfügung. Die bereits erstellten Testabläufe lassen sich hierfür weiterverwenden. Die ersten Softwarein-the-Loop-Tests (SiL-Tests) werden so bereits in einer Phase durchgeführt,

Entwicklung + Test

in der noch nicht alle Anforderungen l Bild 2. Reifendrucksteuerung vollständig beschrieben sind. ist auch während der Fahrt ˆ Der Weg zum Komponentenmöglich, um HiL-Prüfstand z.B. FlurschäDa den Entwicklern nicht jederzeit ein den zu vermeiVersuchsfahrzeug zur Verfügung ste- den. hen kann, entschied sich Daimler für (Bild: Daimler AG) die Anschaffung eines KomponentenPrüfstands auf Basis der Vector-TestHardware VT-System. Es ist ein modular konfigurierbares und leistungsfähiges Testsystem, das vom kleinen Tischaufbau am Arbeitsplatz bis zum großen Labor-HiL-System skaliert werden kann. Bei dem VT-System liegt der Schwerpunkt auf der Simulation der an den Steuergeräten angeschlossenen Sensoren und Aktoren sowie auf der Nachbildung möglicher Fehlersituationen, wie beispielsweise Kurzschlüsse, Über- und Unterspannungen. Anhand verschiedener VT-Module zur Lastsimulation, Messung und Stimulation wird das System bausteinartig zusammengestellt. Ein wichtiger Punkt für die Entscheidung war auch, dass diese Hardware in das bei Daimler schon länger eingesetzte CANoe- SoftwareSystem eingebunden ist. Gerade die direkte Integration dieser Module in CANoe macht eine spätere Erweiterung oder Anpassung des Systems für neue Projekte leicht möglich. Das Testsystem wird mit dem Ethernet-Port des Testrechners verbunden, wobei das echtzeitfähige Ethernet-Protokoll

Restbussimulation

CANoe Messaufbau

- Streckenmodell - CAN Interaction Layer Daimler NetzwerkSchnittstellen

CAN

Test Feature Set Testmodul

Ethernet (EtherCAT)

GPIBSchnittstelle

VT-System

Steuergerät Stromversorgung

l Bild 3. Aufbau des Komponenten-HiL-Prüfstands. (Quelle: Vector Informatik GmbH)

I/O-Anbindung Steuergerät (DUT)

Elektronik automotive 6.2010 3/31

l Bild 4. Modular aufgebautes VTSystem als Komponenten-HiLSystem. (Bild: Vector Informatik GmbH)

llll Steuergerätetest

EtherCAT genutzt wird. CANoe gestattet den Zugriff auf sämtliche Parameter des VT- Systems und ist das Werkzeug zur Testautomatisierung (Bild 3). Für die HiL-Tests am realen Steuergerät wird das Streckenmodell in CANoe eingebunden. Hier zeigt sich ein weiterer Vorteil bei der Verwendung von Modellen: quasi auf Knopfdruck lassen sich beliebige Initialzustände herstellen. Bei dem Streckenmodell betrifft das insbesondere die Drücke in den Reifen und im Druckvorratsbehälter. Denn bei den Tests an realen Fahrzeugen kann es bis zu 20 Minuten dauern, bis vier platte Reifen durch den fahrzeugseitigen Luftpresser wieder auf den vorgeschriebenen Betriebsdruck gefüllt sind. Das Labor-Testsystem hingegen ist hierzu sofort in der Lage. Es spricht die Parameter des Modells direkt an und stellt die Werte grafisch dar, etwa als Druckverläufe.

ˆ VT-System als Komponenten-HiL-Prüfstand Das Streckenmodell überüber das CADas Streckenmodellist ist das Noe-Blockset in die CANoe-SimulatiCANoe-Blockset in die CANoe-Simuon integriert – –getestet lation integriert getestetwird wirddas das reale reale Steuergerät. und Ausgänge Steuergerät. Alle Alle EinEin- und Ausgänge des sind dabei des Steuergeräts Steuergeräts sind dabei an an entspreentsprechende chende Bussignale Bussignale oder oder Hardware-KaHardware-Kanäle näle des des VT-Systems VT-Systems angeschlossen. angeschlossen. Die zwischen der Die Kommunikation Kommunikation zwischen der CANoe-Simulation und den CANoe-Simulation und den SimulinkSimulinkModellen geschieht direkt direkt über Modellen geschieht über eine eine Signalschnittstelle oder über über CANoeSignalschnittstelle oder CANoe-

Umgebungs- und -Systemvariablen. Die Steuergeräte überprüfen ihre Ein-/ Ausgänge standardmäßig daraufhin, ob die entsprechenden Komponenten tatsächlich angeschlossen sind und Sensordaten beziehungsweise Abschlusswiderstände plausibel sind. Daher benötigt man für aussagefähige Tests entweder Originalsensoren und -aktoren oder es ist das Steuergeräteumfeld möglichst realitätsnah nachzubilden. Da eine vernünftige Testautomatisierung mit Originalkomponenten jedoch einen erheblichen Aufwand bedeutet, etwa durch das Betätigen von Bedienelementen über Roboter, ist eine Simulation der Umgebung meistens vorzuziehen. Für das Nachbilden der Umgebungs-Hardware ist jetzt das VT-System verantwortlich. An Steuergeräteeingängen, an denen im realen Fahrzeug die Reifendrucksensoren angeschlossen sind, werden über die Stimulationsmodule VT2004 entsprechende Spannungswerte angelegt. Damit können etwa auch die Schalter zum Be- und Entlüften simuliert werden. Hingegen werden mit den Last- und Messmodulen VT1004 die Ventile durch die elektronischen Lasten simuliert oder die Werte an den Steuergeräte-Ausgängen gemessen. CANoe stellt zusätzlich die Netzwerksimulation und die Testautomatisierung bereit. Dieser Komponenten-HiL-Prüfstand für den Test eines einzelnen Steuergeräts wird später ebenso für Tests am realen Fahrzeug weiterverwendet (Bild 4). Ein Schwerpunkt des neuen Testsystems liegt auf dem Nachbilden von Fehlersituationen, verursacht durch falsche Verkabelung oder defekte Sensoren und Aktoren. Sie liefern keine beziehungsweise falsche Werte oder haben von der Spezifikation abweichende Innenwiderstände und Stromaufnahmen. Im Fall der Drucksensoren werden beispielsweise Spannungen außerhalb des Messbereichs erzeugt, elektronische Lasten simulieren die Ventile und es lassen sich Stromaufnahmen abweichend vom Normalwert parametrieren. Die Reaktionen des Steuergeräts auf derart unvorhersehbare Ereignisse sind für die UnimogExperten zur Weiterentwicklung von höchstem Interesse, ebenso ob das Steuergerät korrekte Fehlerspeichereinträge generiert.

ˆ Unabhängig von der Verfügbarkeit von Testfahrzeugen Für die Testanwendung der Reifendruckregelanlage bei Daimler stellt es keinen Unterschied mehr dar, ob ein reales oder ein simuliertes Steuergerät getestet wird. Die Entwickler sind unabhängig von der Verfügbarkeit realer Testfahrzeuge, was den durchgängigen Einsatz des Testsystems vom Design bis zum Funktionstests ermöglicht. Erst dadurch sind die Testergebnisse für das Steuergerät direkt vergleichbar. Die Entwickler in Wörth planen, motiviert vom Erfog des VT-Systems bereits die nächsten Projekte. Dazu gehört z.B. die Weiterentwicklung des hydrostatischen Fahrantriebs, bei dem das System durch 16-kanälige Digitalmodule und das Stromversorgungsmodul erweitert wird. sj

VN8900 Prüfstände weltweit umrüsten in Rekordzeit Case Study ZF TRW

Der Kunde

Bei ZF TRW befinden sich 32 Prüfstände weltweit im Ein-

ZF TRW gehört zu den weltweit größten Automobilzuliefe-

satz. Künftig werden diese auch für Tests von Radar- und

rern. Mehr als 40 bedeutende Automobilhersteller werden

Kamerasystemen im Bereich des autonomen Fahrens ge-

mit fortschrittlichen Systemen aus dem Bereich der Fahr-

nutzt.

zeugsicherheit beliefert. Dazu gehören beispielsweise Brems-, Lenkungs- und Radaufhängungssysteme sowie anspruchs-

Die Vorteile

volle Insassenschutzsysteme und Fahrzeugelektronik.

Drastisch reduzierte Umrüstzeiten – schnellere Projekte > Prüfstände fügen sich nahtlos in die ZF-TRW-Werkzeug-

Die Herausforderung

kette ein > Restbussimulationen sind mit minimalen Anpassungen in

Weltweit Prüfstände konfigurieren für den Test verschiedener Steuergeräte unter verkürzten Rüstzeiten Sowohl die Anzahl der Steuergeräte als auch deren erweiterte

> Rüstzeiten sind drastisch reduziert

Funktionalität verursachten bei ZF TRW immer höhere Kos-

> Hohe Stabilität und Robustheit bei Langlauftests

ten und Zeitaufwände für Steuergerätetests. Jedes Steuerge-

> Kostengünstige CANoe stand-alone extended Lizenz

rät muss unzählige elektrische, funktionale und mechanische

Dipl.-Ing. Katja Hahmann studierte Elektrotechnik an der TU Chemnitz. Sie ist seit 1997 bei der Vector Informatik GmbH in Stuttgart tätig und dort als Gruppenleiterin für die CANoe- Anwendungsentwicklung in der Produktlinie Networks and Distributed Systems verantwortlich.

Tests direkt weiterverwendbar

ermöglicht autonomen Betrieb des VN8900

Umwelt- und EMV-Tests vor der Freigabe absolvieren. Um die-

> Breite und kostenlose Unterstützung der benötigten

ser steigenden Komplexität und den verfügbaren Zeitschienen

OEM-spezifischen Protokolle durch Vector > Kostenlose Updates des VN8900 auf neue CANoe

auch in Zukunft gerecht zu werden, suchten die Prüfstandsingenieure nach einer flexibleren Prüfstandslösung. Sie sollte

stand-alone-Versionen

global und einheitlich an allen Standorten umgesetzt werden. Die Lösung Intelligentes Netzwerk-Interface im Mittelpunkt Eine zentrale Rolle im neuen Konzept der komponentenbasierten Prüfstände spielt das modulare Netzwerk-Interface VN8900 von Vector. Neben seiner hohen Leistungsfähigkeit bietet es als weiteren entscheidenden Vorteil die Möglichkeit des autonomen Betriebs. Dabei laufen CANoe Restbussimulationen und Testabläufe mit der kostengünstigen CANoe stand-alone extended Lizenz auf dem VN8900 ohne einen angeschlossenen CANoe Bedien-PC. Jeder Prüfstand besteht aus einem 19“-Schrank mit sechs Einschüben,

Dipl.- Ing. (FH) Mario Wirmel studierte Nachrichtentechnik an der FH Karlsruhe. Nach einer Tätigkeit in der Produktionsplanung bei Mercedes-Benz Trucks in Wörth ist er seit 2003 Mitarbeiter in der Entwicklung Elektrik/Elektronik im Produktbereich Mercedes-Benz Sonderfahrzeuge.

in die jeweils ein VN8900 integriert ist. Damit lassen sich sechs Steuergeräte je Prüfstand parallel prüfen. Aus den

Blockschaltbild eines von sechs Einschüben in einem Prüfstand

Entwicklungsabteilungen vorhandene CANoe Restbussimulationen lassen sich somit mit minimalen Anpassungen in den Tests direkt weiterverwenden. Durch das neue Konzept sind die Rüstzeiten drastisch reduziert: von bis zu acht Monaten zum Umrüsten eines Steuer-

V2.0 | 2015-08

Entwicklung + Test

gerätetests von OEM1 auf OEM2 auf jetzt zwei bis drei Wochen. Gleichzeitig sind die Anpassungszeiten kurz vor Teststart auf unter eine Woche verringert.

Elektronik automotive 6.2010 3/32

www.elektroniknet.de

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

3/33

TOOLS

ECU-Test mit XCP-Unterstützung Im Rahmen der Steuergeräteentwicklung oder bei der Analyse eines Steuergerätefehlverhaltens gehören Blackbox-Tests zum Standard-Prozedere. Dennoch ist es für bestimmte Tests nötig, DIREKT IN DAS STEUERGERÄT ZU BLICKEN, denn nur so besteht die Möglichkeit, aussagekräftige Testergebnisse zu erzielen oder den Testaufwand zu reduzieren.

I

n den meisten Fällen reicht für die Funktionsprüfung einer Komponente tatsächlich der Blick auf die Ein- und Ausgänge des Steuergeräts (Bild 1). Schwierig wird es aber dann, wenn im Steuergerät (ECU) Zustandsmaschinen zum Einsatz kommen, denn deren aktueller Zustand lässt sich an den Ausgängen des Steuergeräts nur indirekt – durch die Wirkung – erkennen. Auch bei Sensoren, deren Werte nicht über das Bussystem übertragen werden, kann der Testingenieur nur schwer auf Fehler in der Software-Anbindung schließen, weil es von außen nicht ersichtlich ist, an welcher Stelle das System den Sensorwert falsch verarbeitet. Je nach Zeitpunkt in der Steuergeräteentwicklung kommen unterschiedliche Methoden zum Einsatz, die den Zugang zu internen Steuergerätedaten er-

lauben. In frühen Phasen liefert die ECU beispielsweise die steuergeräteinternen Werte oft über das Hilfsmittel sogenannter „reservierter Entwicklungsbotschaften“ nach außen (Bild 1). Für den Funktionsentwickler eines Zulieferers ist dies eine effektive und schnelle Möglichkeit, die genau auf den jeweiligen Zweck zugeschnitten ist. Diese Zusatzbotschaften müssen aber für die späteren Entwicklungsphasen und insbesondere für die Systemintegration und die Serienfertigung wieder entfernt werden, denn sie bedeuten eine zusätzliche Buslast, und im schlimmsten Fall kollidieren sie im System sogar mit Botschaften anderer Komponenten. Eine weitere Möglichkeit, an die internen Werte zu gelangen, ist die Diagnose (Bild 1). Mit ihr stehen einige Informationen direkt zur Verfügung, zum Beispiel

über den Fehlerspeicherzugriff. Ebenso lesen spezielle Diagnoseservices die benötigten Werte aus dem Speicher aus – und zwar ganz vorteilhaft über einen Standardzugriff. Lediglich der Diagnosetreiber muss dabei bereits fertig integriert sein, aber in aktuellen Steuergeräten ist er meist vorhanden. Nachteilig bei dieser Methode ist allerdings, dass neben den zu messenden Werten viele zusätzliche Diagnoseprotokollinformationen übertragen werden und somit die Bussystemschnittstelle entsprechend belastet ist.

XCP als Testzugang

Muss die Belastung des Bus-Zugangs gering gehalten werden, bietet sich als Alternative ein Kalibrierungsprotokoll an. Ursprünglich wurden diese für den Steuergeräte-Applikateur entwickelt. Er verändert darüber online Parameter oder

Alle Bilder: Vector Informatik GmbH

TOOLS

Bild 1: Herkömmliches Testsystem für den Steuergerätetest mit eingeschränktem Zugriff auf steuergeräteinterne Werte über die Diagnosefunktion oder mittels einer individuellen Botschaft des Entwicklers.

Kennfelder im Steuergerät und optimiert so seine Algorithmen. Mit dem vom ASAM standardisierten XCP-Protokoll liest der Anwender bei Bedarf einzelne Werte direkt aus dem Steuergerät. Auch liefert es über sogenannte Data-Aquisition-(DAQ)-Listen zyklisch einen definierten Satz Messwerte vom Steuergerät. Das XCP-Protokoll ist so definiert, dass es Daten effizient über das Busmedium liefert. Zum Beispiel werden die DAQListen nach der Konfiguration über das Testsystem mittels eines einzelnen Identifiers übertragen. Zudem lassen sich die Messzeitpunkte für die DAQ-Listen auch auf steuergeräteinterne Vorgänge synchronisieren. Automatisierte Testsysteme stellen ähnliche Anforderungen an das System. Über den Weg des XCP-Protokolls ist es somit möglich, ohne große Belastung des Steuergeräts und des verwendeten Bussystems interne Werte in die Testabläufe zu integrieren. Für das Verwenden eines weit verbreiteten Standards wie XCP spricht außerdem, dass die Konfiguration in der Werkzeugkette sehr einfach möglich ist. Alle nötigen Informationen, wie die programminternen Speicherstellen mit ihren Namen oder die Kommunikationsparameter, stehen bereits in der A2L-Datei. Je nach Entwicklungsumgebung wird die A2L-Datei automatisch erstellt oder muss in einem weiteren Schritt aus der Linker-Map-Information generiert werden. Diese Datei hat der Anwender lediglich im Testwerkzeug für jedes im Test verwendete Steuergerät zu konfigurieren. In einem zweiten Schritt wählt er nun die für die Testabläufe nötigen Symbole aus der A2L-Datei aus.

CANoe Option XCP

Die Option XCP ergänzt das Testwerkzeug CANoe von Vector um die einfache Möglichkeit, steuergeräteinterne Werte zu lesen oder zu schreiben. Dabei wird

34 3/34

AUTOMOBIL-ELEKTRONIK � Juni 2010

Bild 2: CANoe Testsystem mit direktem Zugriff auf steuergeräteinterne Werte mit Hilfe der Option XCP.

neben dem XCP-Standard auch das Vorgängerprotokoll CCP unterstützt. Ist die A2L-Datei einmal konfiguriert und sind die nötigen Werte ausgewählt, erfasst CANoe diese automatisch und bildet sie als Systemvariablen ab. Mit diesen Variablen kann der Anwender die Informationen nun in allen Testaufgaben einsetzen. Somit ist neben dem Zugriff auf die Steuergeräteein- und -ausgänge auch ein Blick tief in den Steuergerätespeicher möglich (Bild 2). Bei einfachen Analyseaufgaben stellt der Anwender die Daten im Trace- oder Grafik-Fenster sowie mit Hilfe von Panels dar und bewertet selbst die Ergebnisse. Für komplexere Testabläufe bietet das Test Feature Set in CANoe umfangreiche Möglichkeiten, Testfälle zu erstellen und automatisch zu bewerten. Damit ist es beispielsweise möglich, die korrekte Funktionsweise der Netzwerk-Management-Zustandsmaschine zu prüfen. Die entsprechende Stimulation erfolgt über die Restbussimulation von CANoe, und die Reaktion des Steuergeräts ist nicht nur auf dem Bus, sondern direkt im Steuergerät über XCP messbar. Deutlich verringert ist auch der Aufwand für die Durchführung von Testfällen, die zum Beispiel Sensoren benötigen. Die Sensorwerte schreibt das Testsystem über XCP direkt in die Speicherzelle im Steuergerät. Somit entfällt das aufwändige Anschließen und Ansteuern der Originalsensoren am Steuergeräteeingang. Dem Steuergerät wird dadurch vorgegeben, dass der Sensor und der entsprechende Hardware-Treiber den Wert korrekt gemessen haben. Dasselbe funktioniert natürlich auch in die andere Richtung. Hierbei geht man davon aus, dass die Leistungsendstufe und der Aktuator getestet und abgenommen sind. In diesem Fall misst das Testsystem über XCP den Wert, den die Applikation der Treiberstufe vorgibt.

Zugriff mit hohen Datenmengen

Müssen in einem Testfall große Datenmengen zwischen dem Testsystem und dem Steuergerät ausgetauscht werden oder sind besonders schnelle Vorgänge zu überwachen, so ist eine XCP-Verbindung über den CAN-Bus nicht mehr möglich. In diesem Fall bietet sich ein direkter Zugriff auf die DebuggingSchnittstellen des Steuergeräts an, was zum Beispiel über eine NEXUS- oder JTAG-Schnittstelle geschehen kann. Diese Protokolle greifen - zum Teil unter Umgehung des Mikrocontrollers - direkt auf den Steuergerätespeicher zu. Hierdurch kann der Anwender schnell sehr hohe Datenmengen aus dem System auslesen ohne den Bus und das Steuergerät zu belasten. Den direkten Zugriff auf die NEXUSoder JTAG-Schnittstelle eines Steuergeräts erlaubt beispielsweise die VX Hardware von Vector (Bild 2), die über XCP on Ethernet mit dem Testsystem kommuniziert. Somit ist die Integration in CANoe genauso einfach wie die Integration bei dem XCP-Zugriff über CAN. Durch die Kombination von VX Hardware mit dem CANoe Testsystem ist die Leistung des Testsystems weiter gesteigert – und zwar ganz ohne negative Einflüsse im Kommunikationsmedium.

Oliver Falkner ist Gruppenleiter im Produktmanagement der Produktlinie Networks and Distributed Systems und Produktmanager für die CANoe Option XC bei der Vector Informatik GmbH in Stuttgart.

infoDIRECT Link zu Vector

www.all-electronics.de 337AEL0310

Erschienen in Automobil Elektronik, AUTOMOBIL-ELEKTRONIK � Juni6/2010 2010 35 3/35

3/36

3/37

FlexRay-Steuergeräte effektiv und reproduzierbar testen Case Study Bertrandt AG

Der Kunde

Die Vorteile

Die Bertrandt AG gehört zu den europaweit führenden

Eine leistungsstarke und flexible Umgebung für komplexe

Entwicklungspartnern der Automobil- und Luftfahrtbran-

Steuergeräte-Tests am FlexRay-Bus

che. Rund 5.500 Mitarbeiter erarbeiten an 30 Standorten in

Für die Simulation nutzt Bertrandt CANoe.FlexRay zusam-

Europa und den USA individuell zugeschnittene Lösungen:

men mit CANoe RT und dem Real Time Rack und realisiert

Von einzelnen Komponenten und Modulen bis hin zu kom-

damit ein leistungsfähiges Testsystem für FlexRay: > Testen eines Steuergeräts mittels Restbussimulation

pletten Systemen und Fahrzeugen.

ð Testen ist schon in frühen Entwicklungsphasen mögDie Herausforderung FlexRay-Steuergeräte effektiv und reproduzierbar testen

lich, ohne dass reale Steuergeräte verfügbar sein müssen > Einsatz von OEM-spezifischen Modulen wie Interaction

Das korrekte Verhalten von FlexRay-Steuergeräten im Nor-

Layer, Transport Protokoll, Checksummenberechung etc.

malbetrieb und bei Störungen soll schon in frühen Entwick-

in der Restbussimulation ð schnelle und einfache

lungsphasen getestet werden. Dabei müssen sowohl kom-

Realisierung der Restbussimulation und standardisierte

plexe Testfälle durchlaufen werden, als auch Einzeltests

Ausführung von OEM-spezifischen Funktionen > Ausführung der Restbussimulation mit CANoe RT ð Die

manuell gestartet werden können. Die Tests erfordern eine echtzeitrelevante Restbussimulation, um zuverlässige Aussagen über das Kommunikationsverhalten des Prüflings zu ermöglichen.

Simulation zeichnet sich aus durch deterministische Ausführung, kurze Latenz- und schnelle Antwortzeiten. > Exklusive Ausführung der Restbussimulation auf dem Real Time Rack ð Keine störenden Einflüsse des

Die Lösung Steuergerätetests innerhalb einer Restbussimulation mit

PC-Betriebssystems auf die Simulation > Das Real Time Rack ist skalierbar ð Flexibel anpassbar

einem FlexRay-Prüfstand

auf zukünftige Anforderungen des Testsystems, z. B. auf

Für das reproduzierbare Testen von FlexRay-Steuergeräten

die Anzahl der FlexRay-Kanäle oder Adaption auf andere

hat Bertrandt ein spezielles Testsystem erstellt. Dieses

Bussysteme

enthält eine simulierte Fahrzeugumgebung, die mit einer umfangreichen und echtzeitrelevanten Restbussimulation realisiert wird. Hierbei kommt CANoe .FlexRay zum Einsatz, das die Restbussimulation für das zu testende Steuergerät bereitstellt. Um die hohen zeitlichen Anforderungen zu erfüllen, wird mit CANoe RT die Funktionalität von CANoe .FlexRay auf zwei Rechner verteilt: Die Simulation wird auf einem leistungsfähigen Rechner ausgeführt, dem Real Time Rack. Die Konfiguration und das Benutzer-Interface laufen auf dem Steuer-Rechner des Teststands. Beide Rechner sind

V2.0 | 2009-08

über Ethernet miteinander verbunden.

3/38

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

3/39

MESSEN & TESTEN // STEUERGERÄTETESTS

Wie Sie Steuergeräte mit flexiblen Prüfsystemen effizient testen

MESSEN & TESTEN // STEUERGERÄTETESTS

Bild 1: Das VT System wird für den Test zwischen Steuergerät und Aktoren/Sensoren geschaltet

Funktionstests von Kfz-Steuergeräten stellen höchste Anforderungen – die sich mit modularen und speziell auf die Bedürfnisse der KfzIndustrie zugeschnittenen Testsystemen erfüllen lassen.

alle Bilder: Vector Informatik

DR. STEFAN KRAUSS *

Fehlerfälle: Das Fehlverhalten von Steuergeräten in seltenen oder im Normalfall unmöglichen Situationen stellt die Hersteller vor große Probleme, sobald sie später im Feld doch einmal auftreten. Zum Prüfen der Funktionalität wird das Steuergerät über die Hard- und SoftwareSchnittstellen stimuliert und es werden seine Reaktionen bewertet. Dabei ist es wichtig dem Steuergerät ein Umfeld darzustellen, das der Umgebung im realen Fahrzeug möglichst nahe kommt. Dies kann auf unterschiedliche Art und Weise geschehen. In erster Linie kommt es aber darauf an, dass das Steuergerät keinen Unterschied zwischen der simulierten Umgebung am Prüfstand und der tatsächlichen Umgebung im Fahrzeug wahrnimmt.

Sensoren und Aktoren während des Tests anschließen

Herausforderung Steuergerätetest: Speziell auf die Bedürfnisse der Automobilindustrie zugeschnittene Testsysteme erlauben effiziente Funktionstests schon in frühen Entwicklungsphasen

D

er Funktionstest von Steuergeräten im Automobil erfordert neben dem Prüfen der eigentlichen Funktionalität auch das Testen der wichtigsten Fehlerfälle. Die verwendeten Testsysteme müssen daher hohe Anforderungen erfüllen. Mit dem modularen und speziell auf die Bedürfnisse der Automobilindustrie zugeschnittenen Test-

* Dr. Stefan Krauß ... ist Produktmanager für das VT System bei der Vector Informatik GmbH in Stuttgart.

54 3/40

system VT System des Unternehmens Vector Informatic lassen sich Funktionstests bereits in frühen Entwicklungsphasen effizient durchführen. Die Komplexität der heute im Automobil verbauten Systeme aus Elektronik und Software macht umfassende Tests in allen Entwicklungsphasen notwendig. Früh entdeckte Fehler sind einfacher und billiger zu beheben als Fehler, die erst in späten Phasen gefunden werden. Deshalb werden die Steuergeräte zuerst einzeln in den Funktionstests auf Herz und Nieren geprüft. Besonderes Augenmerk verdienen dabei die zahlreichen

Weil Steuergeräte in vielen Fällen automatisch die Sensoren und Aktoren überprüfen, ist deren Anschluss während des Tests unverzichtbar. Denn das Steuergerät erzeugt Fehlerspeichereinträge oder deaktiviert bestimmte Funktionen, wenn externe Komponenten fehlen. Die originalen Aktoren und Sensoren werden deshalb für den Test direkt an das Steuergerät angeschlossen. Eine Alternative bietet das Simulieren der Lasten und Sensoren. Ein großer Vorteil der Sensorund Aktorsimulation besteht in der möglichen Automatisierung der Testabläufe. Mit geeigneten Modellen ist auch ein HardwareIn-The-Loop-Test (HIL) möglich. Für das Abdecken von Fehlersituationen im Steuergerätetest sind zusätzliche Einrichtungen notwendig, die zwischen Steuergeräteanschluss und den Sensoren und Aktoren geschaltet werden (Bild 1). Diese Testkomponenten erlauben insbesondere den Test folgender Fehlersituationen: „ Die elektrische Verkabelung ist beschädigt: Leitungsunterbrechungen, Kurzschlüsse nach Masse oder Batteriespan-

ELEKTRONIKPRAXIS Automotive Electronics Engineering September 2011

nung, Kurzschlüsse zwischen Anschlussleitungen. „ Sensoren oder Aktoren sind beschädigt: Sensoren liefern keine Werte, die Werte liegen außerhalb des erlaubten Wertebereichs, die elektrischen Eigenschaften der Komponenten wie Innenwiderstand entsprechen nicht der Spezifikation. „ Falsche Eingangswerte, insbesondere falsche Sensordaten: Aus Sicht des Steuergeräts ist der Sensor in Ordnung, auch die Messwerte liegen im erlaubten Rahmen. Sie sind jedoch unplausibel oder widersprechen anderen Sensorwerten. Das Steuergerät muss in diesen Fällen definiert reagieren und zum Beispiel entsprechende Fehlerspeichereinträge generieren. Diese sind dann wiederum vom Testsystem – in diesem Fall über die Diagnoseschnittstelle – zu überprüfen.

Kompakte Testsysteme mit VT System Systeme auf der Basis von VT System und den Software-Tool CANoe zeigen, dass die hohen Anforderungen an leistungsfähige Testsysteme in Bezug auf SchnittstellenHardware, die Testautomatisierung, die Bedienung der Softwareschnittstellen und die Möglichkeiten der Restbussimulation auch

in kompakten Testsystemen für den Arbeitsplatz umgesetzt werden können. Mit CANoe von Vector steht ein ausgereiftes und weit verbreitetes Werkzeug zur Analyse, Simulation und Testautomatisierung zur Verfügung. Die Vector Hardwareschnittstellen ermöglichen eine verlässliche Busanbindung an CAN, LIN, FlexRay oder MOST. Der Anschluss von Mess- und Test-Hardware ist über GPIB, die serielle Schnittstelle oder Ethernet möglich. Ebenso können Standard-I/O-Karten von verschiedenen Herstellern eingesetzt werden. Das VT System ist ein modulares I/O-System, das die Steuergeräte-Ein- und Ausgänge für den Funktionstest mit CANoe ansteuert. Es erlaubt den Aufbau von kompakten Prüfständen unterschiedlichster Komplexität. Der PC mit CANoe wird über das echtzeitfähige EtherCAT mit dem Ethernet-Port des Rechners verbunden. Mit geringem Integrations- und Verkabelungsaufwand lassen sich so flexible Testsysteme zusammenstellen.

Module zum Ansteuern der Ein- und Ausgänge Für das Ansteuern der unterschiedlichen Ein- und Ausgänge eines Steuergeräts stehen verschiedene Module zur Verfügung. Über

ELEKTRONIKPRAXIS Automotive Electronics Engineering September 2011

folgende Eigenschaften verfügen jedoch alle Module: „ Die I/O-Leitungen des Steuergeräts werden direkt mit dem VT System verbunden. Auf den Modulen sind alle für die Beschaltung eines I/O-Kanals notwendigen Komponenten integriert, was den Aufbau von Prüfständen erheblich vereinfacht (Bild 2). „ Bei Bedarf können Originalsensoren und -aktoren an das Modul angeschlossen werden. Über Relais auf dem VT-Modul kann zwischen der Verwendung der extern angeschlossenen Originalkomponenten und der auf dem Modul befindlichen Simulation umgeschaltet werden. „ Auf jeder Leitung zum Steuergerät lassen sich über Relais Fehler erzeugen, beispielsweise Leitungsunterbrechung, Kurzschluss zwischen Leitungen, gegen Masse und gegen die Versorgungsspannung. „ Alle Module und Messeinrichtungen sind für jene Spannungen und Ströme ausgelegt, wie sie in der Automobilelektronik üblich sind. Zusätzliche Signalkonditionierungs-Hardware wird aus diesem Grund nicht benötigt. „ Die Module des VT Systems melden sich automatisch bei CANoe an und sind mit nur minimalem Konfigurationsaufwand einsatzbereit. Alle Mess-, Ausgangs- und Steu-

55 3/41

MESSEN & TESTEN // STEUERGERÄTETESTS

Bild 2: Die Module des VT Systems integrieren alle für den Test einer bestimmten Anzahl von I/OKanälen notwendigen Einrichtungen

ersignale stehen in CANoe direkt zur Verfügung und können zusammen mit anderen Signalen wie Bussignalen in Testskripten eingesetzt oder in Analysefenstern ausgewertet werden.

Last- und Messmodul zur Simulation der Aktoren Das Last- und Messmodul VT1004 wird an den Ausgängen eines Steuergeräts angeschlossen, die im realen Betrieb im Fahrzeug mit Aktoren wie Stellmotoren und Lampen verbunden sind. Zur Simulation dieser Aktoren enthält es für jeden Kanal eine elektronische Last. Die Spannung am Steuergeräteausgang wird mit einer Abtastrate von 250 kS/s gemessen, auf dem Modul vorverarbeitet und CANoe als Momentan-, Mittel- und Effektiv-Werte zur Verfügung gestellt. Ebenso kann das Modul die Parameter von PWMSignalen bestimmen. Es beherrscht hohe Dauerströme bis 16 A, wie sie bei dem Ansteuern von Lampen und Motoren auftreten können.

Digitalmodul steuert Einund Ausgänge an Das Digitalmodul VT2516 steuert die Vielzahl von digital verwendeten Ein- oder Ausgängen eines Steuergeräts an, die im Fahrzeug zum Beispiel mit Schaltern, Kodierbrücken, kleinen Anzeigelampen oder LEDs verbunden sind. Steuergeräteeingänge werden über digitale Signale mit einstellbaren Pegeln stimuliert, wobei neben auf dem Modul abgespeicherten Bitfolgen auch PWM-Signale ausgegeben werden können. Umgekehrt misst das Modul an jedem Kanal vom Steuergerät ausgegebene Digitaloder PWM-Signale und Spannungen. Über einen zuschaltbaren Widerstand werden Lasten simuliert oder Pull-up/down-Schaltungen realisiert.

Spezielles Modul simuliert die Sensoren Für die Sensoreingänge eines Steuergeräts ist das Stimulationsmodul VT2004 zuständig. Für die Simulation von Sensoren verfügt es an jedem Kanal über eine vom Testskript steuerbare Widerstandsdekade. Das Steuergerät kann alternativ über Spannungen stimuliert werden, wobei auf dem Modul abgespeicherte Spannungsverläufe mit hoher Präzision abgespielt werden können. Das Modul kann auch PWM-Signale generieren und auf einem Kanal ein Potentiometer, wie es zum Beispiel bei Tankgebern Verwendung findet, simulieren.

Die Stromversorgungsleitungen eines Steuergeräts werden an das Modul VT7001 angeschlossen (Bild 3). Die Stromaufnahme wird in einem sehr weiten Bereich exakt erfasst und erlaubt so zum Beispiel das Prüfen von Ruhezuständen oder das Analysieren der Leistungsaufnahme unterschiedlicher Softwarevarianten. Das Modul erzeugt auch die Steuerspannungen für externe Netzteile, was insbesondere das Simulieren definierter Störungen auf den Stromversorgungsleitungen erlaubt. Mit Dauerströmen bis zu 70 A bedient das VT7001 auch Steuergeräte mit hoher Leistungsaufnahme. Die beiden Stromversorgungseingänge Klemme 15 und Klemme 30 eines Steuergeräts können separat angesteuert werden. Des weiteren gibt es Module für die Bussystemanschlüsse, für die Ausführung der Simulation und der Tests in Echtzeit auf der VT-Hardware sowie für die Integration kundenspezifischer I/O-Schaltungen in das VT System. Weitere Module sind in der Entwicklung.

Getrennte Testeinrichtungen für jeden Kanal Die mehrkanaligen VT-Modulen stellen die Testeinrichtungen für jeden Kanal getrennt zur Verfügung. Die Anschlüsse der Steuergeräte können dadurch unabhängig angesteuert werden. Dies vereinfacht die Testautomatisierung und -programmierung und erlaubt die problemlose Darstellung von Mehrfachfehlern und komplexeren Bedienvorgängen.

Von kleinen Prüfaufbauten bis zu umfassenden Prüfständen Das VT System eignet sich aufgrund seines modularen Aufbaus sowohl für kleine Prüfaufbauten an den Arbeitsplätzen der Entwickler als auch für umfassende Prüfstände im Testlabor. Zusammen mit CANoe steht dem Testingenieur eine flexible und leistungsfähige Lösung für den Aufbau kompakter Prüfsysteme für die Automobilindustrie zur Verfügung. Die Testautomatisierung wird effizient in CANoe umgesetzt, in das sich das VT System nahtlos integriert. // TK Vector Informatik +49(0)711 806700

InfoClick Mehr über Steuergerätetests Das VT-Testsystem im Detail Näheres zum Softwaretool CANoe Bild 3: Das Modul VT7001 bedient die Stromversorgungseingänge eines Steuergeräts

www.elektronikpraxis.de

InfoClick 2838684

Erschienen in Elektronik Praxis, Special Edition „Automotive“, 9/2011

56 3/42

ELEKTRONIKPRAXIS Automotive Electronics Engineering September 2011 3/43

inDuStrie ENtWICkluNGSProzESSE

Porsche validiert Gateway-steuerGeräte automatisch Beim Panamera setzt Porsche für die Validierung von Gateway-Steuergeräten den sogenannten „Porsche Echtzeit trace Analyser Petra“ ein. Petra basiert auf dem testwerkzeug CANoe von Vector Informatik und generiert aus routing-tabellen automatische Gateway-tests. Diese werden in Erprobungsfahrten eingesetzt und prüfen die routing-Funktionen online. Auch spätere Analysen anhand von Aufzeichnungen der Buskommunikation können mit Petra durchgeführt werden. zusätzlich zu den sequenziellen testumfängen im labor erhält Porsche damit ein testwerkzeug zum automatischen Erkennen von routing-Fehlern.

AutorEN

Dipl.-ing. (Fh) kArl-peter Spring

ist Sachgebietsleiter in der Abteilung Vernetzung, Diagnose und Gateways, verantwortlich für alle zentralen Gateway-Steuergeräte, bei der Dr. Ing. h. c. F. Porsche AG in Weissach.

Architektur

Die Elektronik-Architektur des Panamera basiert auf mehr als 30 CAN-Steuergeräten, die sich auf sechs CAN-Netzwerke verteilen. Sie wird ergänzt durch zwölf LIN-Netzwerke mit insgesamt 25 LIN-Slaves. Zur Vernetzung der Infotainment-Systeme dient ein Most-Bus. Die sechs CAN-Busse für die Aufgabenbereiche Diagnose, Komfort, MMI (Man Machine Interface), Antrieb, Fahrwerk und Crash-Gefahren sind gemeinsam mit maximal zwei LIN-Zweigen an einem zentralen Gateway-Steuergerät angeschlossen, ❶. Gateways verknüpfen im Kraftfahrzeug die verschiedenen Netzwerke und sorgen für einen schnellen netzwerkübergreifenden Datenaustausch.

Dipl.-inF. thomAS hohmAnn

arbeitet in der Gateway-Entwicklung, Abteilung Vernetzung, Diagnose und Gateways bei der Dr. Ing. h. c. F. Porsche AG in Weissach.

Dipl.-ing. kAtjA hAhmAnn

ist Gruppenleiterin der CANoeAnwendungsentwicklung in der Produktlinie Networks and Distributed Systems bei der Vector Informatik GmbH in Stuttgart.

intelligente gAtewAy-Funktionen

Im Kraftfahrzeug geht es darum, die Informationen möglichst schnell und intelligent zwischen den Netzwerken zu transferieren. Dabei müssen die unterschiedlichen Bandbreiten der Busse berücksichtigt werden. Eine zyklische Botschaft, die empfängerseitig auf einem CAN-Highspeed-Bus alle zehn Millisekunden eintrifft, darf das Gateway in der Regel nicht genauso schnell auf ein Netzwerk mit niedrigerer Bandbreite routen. Die Kopier-

vorschrift könnte hier lauten, den aktuellen Wert nur alle 100 Millisekunden auf dem langsamen Bus zu senden. Durch das Unterdrücken von Botschaften lässt sich das Datenvolumen reduzieren und gezielt an die niedrigere Busgeschwindigkeit anpassen. Im umgekehrten Fall – von langsam nach schnell – hat das Gateway gegebenenfalls die Aufgabe, die Botschaften auf der Senderseite zu vervielfachen, also eine Botschaft häufiger zu senden als sie tatsächlich empfangen wird. Andere Botschaften wiederum gilt es, ohne Vervielfachung oder Unterdrückung möglichst schnell eins-zu-eins weiterzusenden. Dazu wird im Gateway für jede zu routende Nachricht eine Routing-Regel hinterlegt. Diese Regeln enthalten Informationen über Quell- und Zielnetzwerk sowie über die Kopiervorschrift. Die Integration des Gateway-Steuergeräts in das Fahrzeug liegt in der Verantwortung des Automobilherstellers. Für die korrekte Zusammenarbeit der Netzwerke und Steuergeräte ist die Fehlerfreiheit der Gateways eine unabdingbare Voraussetzung. Um das Routing-Verhalten zu verifizieren sind zahlreiche Tests in verschiedenen Fahrsituationen und eine detaillierte Analyse unverzichtbar. Bisher lag der Schwerpunkt auf Labortests, bei denen durch Stimulation der Eingangssignale sequentiell alle Routing-Vorschriften des

60

e-010-0394-y_ECU_Validierung_Vector.indd 60 3/44

Gateways umgesetzt werden. Auf dem Ausgangs-Bus werden die erwarteten Ergebnisse anhand der Routing-Algorithmen geprüft. Porsche führt diese Tests auch unter verschiedenen physikalischen Randbedingungen wie Unter- und Überspannung und mit verschiedenen Temperaturprofilen durch.

porSche echtzeit trAce AnAlySer

Die Lösung entstand in Zusammenarbeit mit Vector Informatik und führte zu einem Werkzeug mit der Bezeichnung Porsche Echtzeit Trace Analyser (Petra). Grundlage für Petra ist die Test- und Simulationssoftware CANoe. Dieses Werk-

grenzen Der lAborteStS

Die mit speziellen Test- oder HiL-Systemen im Labor erzeugten Testdaten erlauben zwar den Test der Grundfunktionalität, sporadische Fehler treten jedoch häufig erst unter realen Belastungsszenarien und beim Zusammenspiel aller Bussysteme und Steuergeräte zu Tage. Insbesondere Stresssituationen unter hoher Buslast und das gleichzeitige Auftreten bestimmter Ereignisse führen zu komplexen Fehlern. Das zentrale Gateway des Panamera routet über die sechs CAN-Busse mehr als 3000 verschiedene CAN-Signale im Bruchteil einer Sekunde und muss dabei 25 verschiedene Sendearten berücksichtigen. Angesichts der in dieser Entwicklungsphase oftmals zeitaufwändigen manuellen Fehleruntersuchung in den Erprobungsfahrzeugen reifte bei den Porsche-Ingenieuren während der Panamera-Entwicklung der Wunsch nach einer effizienteren Analysemethode für die Auswertung von 06I2010

1/24/2013 1:32:19 PM

Fahrzeug-Netzwerktraces. Das neue System sollte in der Lage sein, den Gateway-Datenverkehr während realer Testfahrten in Echtzeit zu verifizieren. Recherchen auf dem Markt der Werkzeughersteller und Testspezialisten lieferten jedoch die Erkenntnis, dass ein entsprechendes Werkzeug oder Testsystem weder verfügbar noch bekannt war.

atze-010-0394-y_ECU_Validierung_Vector.indd 61

5. Jahrgang

❶ Aufbau des PanameraGateway-Steuergeräts mit sechs CAN-Bussen und bis zu zwei lIN-Bussen

61

1/24/2013 1:32:2 3/45

inDuStrie ENtWICkluNGSProzESSE

❷ Petra lässt sich über eine grafische oberfläche einfach konfigurieren

zeug ist auf Steuergerätetests optimiert. Durch entsprechende Konfigurationen lassen sich automatische Testabläufe einschließlich Restbussimulationen erstellen, aufgezeichnete Netzwerk-Kommunikation abspielen und ausführliche Testprotokolle generieren. Zur Implementierung automatischer Abläufe stellt das in CANoe enthaltene Test Feature Set (TFS) Testfunktionen in der Skriptsprache Communication Access Programming Language (CAPL) zur Verfügung. Diese zeichnet sich durch eine C-ähnliche Syntax aus. CAPL kennt spezielle Funktionen um Tests zu formulieren und kann so auf busbezogene Ereignisse wie den Empfang einer Botschaft reagieren. In XML-Dateien können Tests aus vordefi-

nierten Test-Funktionen und SteuerungsFunktionen zusammengesetzt und parametriert werden. Ein vollständiger Testlauf wird in CANoe durch ein Testmodul repräsentiert. Petra wurde als Auftragsarbeit von Vector entwickelt und dient zusammen mit den Standardfunktionen von CANoe TFS zur Validierung der CAN-Gateway-Funktionen des zentralen Panamera-GatewaySteuergeräts, ❷. Es generiert alle für die Validierung eines Gateway-Versionsstands notwendigen CANoe-Testmodul-Komponenten, die sowohl während der Erprobungsfahrten als auch offline bei der Auswertung von Daten-Aufzeichnungen einsetzbar sind. Die Routing- und Kopiervorschriften der Botschaften von mehre-

❸ Nur die in der ersten Spalte markierten Botschaften werden beim Generieren der testkonfiguration berücksichtigt

62

atze-010-0394-y_ECU_Validierung_Vector.indd 62 3/46

ren Bussen lassen sich dabei gleichzeitig bewerten. Um bei einzelnen Tests den Fokus auf bestimmte Botschaften richten zu können, legten die Porsche-Mitarbeiter von Anfang an Wert auf weitreichende Filtermöglichkeiten. Die Gateway-Entwickler wollten ausdrücklich ein System, das sowohl die Gesamtheit aller Botschaften überprüft als auch die Möglichkeit bietet, durch eine einfache Konfiguration einzelne Routing-Beziehungen zu analysieren. Insbesondere der spezielle Datenverkehr von Ausnahmesituationen, wie er zum Beispiel beim Starten des Fahrzeugs, Herunterfahren des Netzwerks und so weiter entsteht, wollte man bewusst ausblenden können, da jedes Testsystem hier eine Fülle bedeutungsloser Fehlermeldungen hervorbringt. online- unD oFFline-teStS

Eine Routing-Tabelle im Excel-Format beschreibt sämtliche Signale und Botschaften, die vom Gateway zu routen sind. Jede Zeile entspricht einer entsprechenden Vorschrift und definiert die Art und Weise wie eine Nachricht zu routen ist. Nachrichten, die vollständig (1:1) weitergeleitet werden, gliedern sich in folgende Botschaftstypen: Zyklische Botschaften, BÄS-Botschaften und BAF-Botschaften. Bei BÄS-Botschaften (Bei Änderung Sofort) handelt es sich um Sonderfälle zyklischer Botschaften, die das verantwortliche Steuergerät zusätzlich zum normalen zyklischen Versand versendet. Dies geschieht, sobald sich ein Eingangswert – etwa von einem Sensor – ändert. BAFBotschaften (Bei Aktiver Funktion) sind eins-zu-eins-Botschaften, die das Gateway direkt und ohne Anpassung der Zykluszeiten weiterrouten soll. Darüber hinaus generiert und versendet das Gateway Botschaften mit Signalen aus verschiedenen Empfangsnachrichten („Sammelbotschaften“). Für jede Empfangsnachricht gibt es in der generierten Botschaft ein sogenanntes „Veraltet-Bit“. Stellt das Gateway bei eingehenden zyklischen Botschaften eine Verzögerung fest, die die erlaubte Toleranz übersteigt, setzt es vor dem Weiterleiten dieser Sammelbotschaft das Veraltet-Bit. Aktive Veraltet-Bits signalisieren den empfangenden Steuergeräten, dass der Informationsgehalt der Sammelbotschaft nur noch eingeschränkte Aussagekraft besitzt.

Über Petra erstellt der Anwender aus der Routing-Tabelle automatisch eine erweiterte Konfigurationstabelle, ebenfalls im Excel-Format. Diese dient dem Testingenieur nun zur Auswahl der zu analysierenden Botschaften des GatewayDatenverkehrs, ❸. Wird in der ersten Spalte eine Routing-Beziehung markiert, berücksichtigt der Testgenerator diese Zeile beim Erstellen der Testkonfigurationen. Alle anderen Botschaften werden bei diesem Test ignoriert. Weiterhin lassen sich diverse Bewertungsgrenzen zum Beispiel Toleranzen für die Zykluszeitüberwachung und die erlaubte Gate-Zeit von BAF- und BÄS-Botschaften spezifizieren. Automatisch erstellt Petra dann alle für eine Testausführung notwendigen Dateien, ❹. Dazu gehören ein XML-Testmodul mit einer CAPL-Testbibliothek sowie ein CAPL-Filter der im CANoeMessaufbau beispielsweise vor dem Trace-Fenster verwendet wird. Der CAPLDurchlassfilter lässt nur die Botschaften passieren, die für die generierten Überwachungen benötigt werden. Damit sind die wesentlichen Voraussetzungen für einen CANoe-Testlauf erfüllt, 5. Petra ist ein Stand-Alone-Werkzeug, mit dem sich Testmodule auch ohne installierte CANoe-Lizenz erstellen lassen. teStprotokoll Spricht SprAche DeS AutomobilherStellerS

Das Testsystem erstellt während der Tests ein detailliertes Protokoll über die aufgetretenen Ereignisse. Das Testprotokoll wurde auf die Porsche-spezifischen Prozesse und Bezeichnungen optimiert, so dass dieses gleichermaßen von den Experten der Gateway-Entwicklung und von Kollegen aus anderen Fachabteilungen lesbar ist. Die Checks decken lückenlos alle für den jeweiligen Botschaftstyp relevanten Kopiervorschriftsverletzungen auf und arbeiten je nach Situation sowohl auf Byte- als auch auf Signal-Ebene. Für Tests auf der Straße lässt sich das System so konfigurieren, dass beim Auftreten eines Fehlers sofort eine entsprechende Meldung auf dem Bildschirm erscheint. Eventuelle Routing-Fehler als Folge von Bedien- und Fahrmanövern lassen sich so unmittelbar wiederholen. Bei Offline-Tests werden die bei Testfahrten aufgezeichneten Logging-Dateien in CANoe über Replay-Blöcke abgespielt. 06I2010

1/24/2013 1:32:23 atze-010-0394-y_ECU_Validierung_Vector.indd PM 63

5. Jahrgang

Hilfreich bei der Fehlersuche ist hier unter anderem die Möglichkeit, direkt an die Stelle der Trace-Daten zu springen, an der ein Fehler aufgetreten ist. Häufig geben die direkten Ereignisse vor und nach dem Fehlerfall Aufschluss über die Fehlerursache. Wichtige Hinweise über die Häufigkeit von Fehlern und die „Fehlerqualität“ liefert die Fehlerstatistik: Sie beantwortet Fragen, ob ein Fehler fortlaufend auftritt oder etwa nur alle 1000 km, ob bestimmte Zykluszeitverletzungen im Mittel sehr groß oder vergleichsweise gering sind. FAzit unD AuSblick

Das Werkzeug CANoe ist im Hause Porsche schon länger im Einsatz und bis heute sukzessive optimiert. Die vorhandene Werkzeugkette mit dem „Porsche Echtzeit Trace Analyser“ wurde ständig ausgebaut. Petra erfordert von den Mitarbeitern nur geringen Einarbeitungsauf-

wand. Die neue automatisierte Vorgehensweise bei der Analyse des Routings von realen Kommunikations-Daten ergänzt die stimulierenden Testszenarien der Labortests in idealer Weise. Die Entwicklung des neuen GatewayValidierungssystems basiert auf einer engen Zusammenarbeit der Mitarbeiter von Porsche und Vector Informatik. Dadurch wurden potenzielle Fehler während der Steuergeräte-Entwicklung für den Panamera frühzeitig gefunden und ein hoher Reifegrad erreicht. Der Zeitvorteil bei der Analyse von Kommunikationsdaten liegt gegenüber der bisherigen manuellen Fehlersuche bei rund 65 %. Durch den Generatoransatz lässt sich das Petra-Konzept flexibel auf künftige Baureihen und Fahrzeuggenerationen übertragen. Bei Bedarf können andere Bussysteme, wie Flexray oder Ethernet, ebenfalls in das Petra-Konzept integriert werden.

❹ Für die testausführung erstellt Petra automatisch ein XMl-testmodul und eine CAPltestbibliothek

5 Petra prüft die Einhaltung der routing- und kopiervorschriften und gibt die Ergebnisse in einem testprotokoll aus

63

Erschienen in ATZ elektronik, 6/2010

1/24/2013 1:32:24 3/47 PM

Leichter Einstieg in die Busanalyse

konzentrieren. Zudem lassen sie sich nicht schließen, wo-

­besteht also ein nahtloser Migrationspfad von CANalyzer

Das Vernetzen von Steuergeräten steht in einem ständigen Spannungsfeld: Immer komplexere Aufgaben verlangen ent-

durch auch das Suchen versehentlich geschlossener Fens-

Beginner zu CANalyzer – und übrigens auch zu CANoe; denn

ter wegfällt. Konfiguriert werden die Fenster ausschließlich

Konfigurationen, die mit CANalyzer Beginner erstellt wur-

per Drag & Drop und mithilfe der Funktionen in der Toolbar.

den, lassen sich auch in CANoe laden.

Mit wenigen Mausklicks ist eine eigene Konfiguration er-

Die zukünftige Planung für den CANalyzer Beginner sieht

stellt. Der Benutzer fügt dazu lediglich für jeden Bus einen

vor, weitere Aufgaben zu unterstützen und eventuell Kon-

Kanal und eine passende Netzwerkbeschreibungsdatei

zepte in CANalyzer zu übernehmen.

sprechend komplexere Werkzeuge. Oft gibt es jedoch einfache Aufgaben, deren schnelle Erledigung durch diese Komplexität und Feature-Vielfalt der Werkzeuge behindert wird. Für solche Aufgaben wünscht sich der Anwender ein einfach zu bedienendes Werkzeug. Wenn es die Aufgabe erfordert, möchte er aber auch auf einen umfangreichen Feature-Umfang zurückgreifen können.

(DBC für CAN oder LDF für LIN) im zentralen Konfigura­ Übersetzung der englischsprachigen Veröffentlichung im CAN Newsletter, Ausgabe Dezember/2012

Dieses Spannungsfeld tritt bei typischen Aufgaben wie Bus-­

nen. Die einzelnen Aufgabenfelder können kombiniert und

Baud­rate zu konfigurieren und der Anwender wählt dann

Monitoring, Stimulation oder Datenaufzeichnung auf. Im

jederzeit hinzugefügt oder entfernt werden. Der volle Feature-­

die Aufgaben aus, die zu erledigen sind. Während der

Rahmen des Monitorings ist insbesondere das Beobachten

Umfang von CANalyzer ist zunächst nicht sichtbar aber

­Messung bietet beispielsweise das Trace-Fenster vielfältige

Bildrechte:

des Datenverkehrs auf dem Bus aus verschiedenen Blick-

dennoch jederzeit abrufbar. Somit lassen sich die eingangs

Möglichkeiten auf bestimmte Ereignisse zu filtern, wie etwa

Alle Bilder Vector Informatik GmbH

winkeln interessant. Die Trace-Funktion zeigt hierbei den

erwähnten Aufgaben schnell und zielgerichtet ausführen.

Sperr- und Durchlassfilter für Botschaften oder Kanäle.

zeitlichen Verlauf aller Busereignisse. Es gibt auch die Mög-

Der CANalyzer Beginner ist als Bestandteil jeder CANalyzer

Außerdem zeichnet es sich durch eine sehr lange Datenhis-

Links:

lichkeit, einzelne Größen grafisch anzuzeigen. Des Weiteren

Installation sofort nutzbar (CAN- und LIN-Bus). Somit

torie aus, so dass auch Langzeitmessungen über Tage hin-

Webpage CANalzyer: www.vector.com/canalyzer

möchte der Anwender einen Überblick über die Busstatistik

spart der Anwender Kosten und Zeit, da kein separates

weg vollständig erhalten bleiben. Das Statistikfenster bie-

erhalten. Bei der Stimulation geht es hingegen darum, be-

Werkzeug beschafft und installiert werden muss. Der Be-

tet einen detaillierten Überblick über die aktuelle Situation

stimmte Botschaften spontan oder zyklisch auf den Bus zu

ginner-Modus nutzt die Vorteile des völlig überarbeiteten

auf dem Bus und bereitet Statistikinformationen auf Kno-

senden. Und selbstverständlich sollen für eine nachgelager-

Fenster-Layouts in CANalyzer. Die einzelnen Aufgaben sind

ten- oder sogar Botschaftsebene auf.

te Offline-Analyse Daten aufgezeichnet werden.

hierbei in festen Desktops organisiert, die nicht verändert

Sind komplexe Aufgaben zu erledigen ist dies ebenfalls kein

Diese drei Kernaufgaben sind die Domänen des CANalyzer

werden müssen und auf denen sich bereits vorkonfigurierte

Problem. Eine mit dem Beginner-Modus erstellte Konfigura-

Beginner, einem speziellem Ausführungsmodus von ­CANalyzer

Fenster befinden (Bild 1). Somit entfällt das weitere, zeit-

tion kann jederzeit mit dem vollen Umfang von CANalyzer

aus dem Hause Vector. Der auf diese Kernaufgaben fokus-

raubende manuelle Konfigurieren. Da die Fenster fest an-

geladen werden. Auch eine weitere Offline-Analyse auf­

sierte Modus ist selbst für Neueinsteiger einfach zu bedie-

geordnet sind, fällt es leicht, sich auf das Wesentliche zu

gezeichneter Daten ist mit CANalyzer durchführbar. Es

Bild 1: Fest konfigurierter Desktop für die Bus-Monitoring-Aufgabe

3/48

tionsfenster hinzu (Bild 2). Gegebenenfalls ist noch die

Jochen Neuffer studierte Nachrichtentechnik an der Fachhochschule Esslingen. Seit 2002 arbeitet er bei Vector Informatik und ist dort als ­Product Management Engineer im Bereich Tools for Network and Distributed Systems tätig.

Bild 2: Erstellen einer neuen Konfiguration mit CANalyzer Beginner

3/49

Messen/Testen

Alle Bilder: Vector Informatik GmbH

Messen/Testen

Bild 1: Spezielle Datenlogger für den Einsatz in Fahrzeugen sind robust und verfügen über zweckmäßige Schnittstellen.

Um im Rahmen einer nachgelagerten Offline-Analyse und Fehlersuche bestimmte Fahrsituationen eindeutig einem bestimmten Fehlerbild zuzuordnen, hat der Testfahrer die Möglichkeit, Audiokommentare sowie Kamerabilder während der Testfahrt mit aufzuzeichnen. Auch GPS-Daten zum geographischen Abgleich lassen sich parallel zu der Buskommunikation den geloggten Daten hinzufügen. Nach dem Aufzeichnen werden die Daten typischerweise auf dem PC konvertiert, um dann in anderen Programmen, wie beispielsweise CANoe, CANalyzer oder CANape, eine Datenanalyse vorzunehmen.

Testfahrten lückenlos Aufzeichnen Datenlogger erfassen zuverlässig Fahrzeugdaten Flottenlogger müssen auch unter extremen Umgebungsbedingungen zuverlässig ihren Dienst versehen. AUTOMOBIL-ELEKTRONIK zeigt, worauf es bei flexiblen Systemen ankommt: Von den Kanälen und Bussen auf der Eingangsseite bis zur Schnittstelle am Ausgang. Autor: Jochen Neuffer

D

urch das Verwenden verschiedener Bussysteme im Fahrzeug werden die Fehlersuche und -analyse immer aufwändiger. Labortests reichen nicht aus, um reale Situationen für die Kommunikation im Gesamtsystem Fahrzeug nachzubilden. Allein umfangreiche Testfahrten in der realen Umgebung sorgen für die notwendige Testtiefe. In den Testflotten verbaute Datenlogger sind hierbei das Mittel der Wahl für das Aufzeichnen des Datenverkehrs aller Busse sowie ausgewählter I/O Leitungen. Im Rahmen der Qualitätssicherung kann dann jederzeit auf Daten aus den Testfahrten zurückgegriffen werden. Kurz vor Serienreife werden Fahrzeuge typischerweise mittels Testfahrten auf Herz und Nieren geprüft. Um hier eine möglichst große Testabdeckung zu erzielen, finden diese Tests zum Teil unter extremen äußeren Bedingungen statt. Ob Wintertests in Finnland bei -30 °C, Hitzetests im Death Valley bei über 50 °C oder wochenlanges Fahren durch den brasilianischen Urwald bei hoher Luftfeuchtigkeit und schlechten Straßenverhältnissen: Letztendlich muss das Fahrzeug mit allen Komponenten fehlerfrei funktionieren. Die verbauten Datenlogger müssen diesen Bedingungen aber ebenso standhalten. Auch sie müssen somit mechanisch robust sein und über einen weiten Temperaturbereich zuverlässig funkti-

onieren. Im Kraftfahrzeug oder Nutzfahrzeug kommen mit CAN, LIN und Flexray unterschiedliche Bussysteme zum Einsatz. Zu den technischen Anforderungen gehört unter anderem das Feature, die Daten von allen Bussen gleichzeitig, also zeitsynchron, aufzuzeichnen. Dabei darf der Logger den Busverkehr nicht beeinflussen; er darf lediglich mithören. Da die Logger in den Testflotten zum Teil fest verbaut sind und eine Testserie mehrere Wochen dauern kann, dürfen sie im heruntergefahrenen Zustand nur eine sehr geringe Stromaufnahme aufweisen – dies ist eine weitere Anforderung an Datenlogger. Außerdem müssen die Geräte in der Lage sein, schnellstmöglich einsatzbereit zu sein, damit bereits die erste auftretende Botschaft aufgezeichnet werden kann. Die Logger sind typischerweise nicht nur fest verbaut. Oft befinden sie sich an besonders unzugänglichen Stellen, etwa unter dem Sitz oder im Kofferraum hinter einer Klappe, die aber beispielsweise wegen anderer Messgeräte nicht zugänglich ist. Daher ist es von Vorteil, wenn der Testingenieur Daten drahtlos über UMTS oder WLAN aus einem Logger auslesen kann. Alternativ dazu sollten Daten auch direkt über USB oder durch Austausch des Speichermediums auslesbar sein.

Spezielle Datenlogger für Testflotten Eine naheliegende Idee wäre es, für das Loggen im Fahrzeug eine Notebook-basierte Lösung zu verwenden. Das Notebook bietet in Verbindung mit einem entsprechenden Netzwerk-Interface potenziell alle Möglichkeiten, da sich die Funktionalität in Software realisieren lässt. Allerdings verfügen handelsübliche Notebooks nicht über den geforderten Temperaturbereich. Außerdem muss das System zuerst gebootet werden, was auch bei schnellen Notebooks seine Zeit dauert. Hieraus ergibt sich eine weitere Anforderung an Datenlogger: Kurze Startzeiten. Das System muss die Daten so schnell erfassen, dass es bereits die erste Botschaft auf dem Bus aufzeichnet. Spezielle Flottenlogger wie etwa die Geräte der Logger-Familie GL3000/GL4000 von Vector (Bild 1) erfüllen diese Anforderungen. Durch ihren erweiterten Temperaturbereich ist auch ein Einsatz unter extremen Umweltbedingungen möglich. Diese speziellen Flottenlogger besitzen zudem eine Echtzeituhr, mit der die eindeutige zeitliche Zuordnung erfasster Daten gesichert ist.

Datenverarbeitung Um die Menge der anfallenden Daten schon während der Testfahrt zu reduzieren, ist es mit diesen Loggern möglich, die Aufzeichnung nur auf Grund von vorher definierten Ereignissen zu starten. Hierzu wird beim getriggerten Logging ein Ringpuffer ständig beschrieben. Tritt das Trigger-Ereignis auf, so wird dieser Ringspeicher geschlossen und die Daten gespeichert. Anschließend setzt der Logger die Aufzeichnung in einem neuen Ringspeicher fort. Mit dieser Methode verringern sich die Datenmengen im Gegensatz zum permanenten Loggen erheblich. Je nach Konfiguration des Ringspeichers stehen aufgezeichnete Daten vor dem Triggerzeitpunkt, sowie – durch eine einstellbare Nachlaufzeit – auch nach dem Triggerzeitpunkt zur Verfügung. Dieses Konfigurieren erfolgt üblicherweise mittels spezieller Software (Bild 2).

Bild 2: Trigger-Konfiguration im Vector Logger Configurator

Für das Ausführen komplexer Logging-Aufgaben kann die spezielle Script-Sprache Logger Task Language (LTL) zum Einsatz kommen. Ein einfaches Programmierbeispiel verdeutlicht anschaulich, wie das Erstellen von Klassiertabellen während des Loggens abläuft. Dabei konvertiert das System zunächst aus einer Datenbasis die symbolischen Signale Speed und Brake automatisch in LTL-Code, so dass der Testingenieur nur noch den Code für die Klassierung mit Hilfe des CLASSIFY Operators ergänzt: ■ VAR Speed = CAN1 DATA 200h [2 3] ■ Brake = CAN1 DATA 100h [3(0)] ■ CLASSIFY ■ MyClassify COUNT (Brake) ■ OVER Speed (20 CLASSES OF 10 BASE 0) Hierbei bildet die Software den Wert der Variable Speed, in km/h auf 20 Klassen der Breite 10 km/h ab, wobei per Definition 0 km/h als Startwert der ersten Klasse dient. Damit ergibt sich folgende Klassenaufteilung: Die Daten jeder Klassier-Aufgabe legt die Klasse Wertebereich [km/h] 1 0- 9 Software in textbasierten Ergebnis-Tabel2 10 - 19 len ab, die sich leicht in Programme wie … … beispielsweise Microsoft Excel einlesen 19 180 - 189 20 190 - ….. und weiter verarbeiten lassen. ■ Der Autor: Dipl.-Ing. Jochen Neuffer arbeitet bei Vector Informatik als Product Management Engineer im Bereich Tools for Network and Distributed Systems.

Auf einen Blick Flottenlogger Auf dem Markt gibt es zwar ein großes Angebot an Datenloggern, aber nur Flottenlogger sind für den anspruchsvollen Einsatz im Automotive-Bereich geeignet. Sie sollten einen reichhaltigen Funktionsumfang bieten, der während Testfahrten einen Großteil der üblichen Anforderung moderner Fahrzeuge abdeckt. Dazu gehören eine große Anzahl an Kanälen für CAN, LIN und FlexRay, eine kurze Startzeit sowie I/O-Anschlüsse auf Loggerseite. UMTS, WLAN, USB und Ethernet auf der Konfigurationsseite wiederum bieten die nötige Flexibilität, um die Logger zu konfigurieren und die aufgezeichneten Daten zu übertragen. Mit einem erweiterten Temperaturbereich sowie einer stabilen Bauform ist ein Testingenieur bestens für den Einsatz unter extremen Umweltbedingungen gerüstet. infoDIREKT www.automobil-elektronik.de

311AEL0111

Erschienen in Automobil Elektronik, 2/2012 18 3/50

Automobil ElEktronik 01/2011

www.automobil-elektronik.de

www.automobil-elektronik.de

Automobil ElEktronik 01/2011

19 3/51

E nT wI C K l u n G S PROZESSE

Diagnose

1 Einleitung Die starke Konkurrenz auf dem weltwei­ ten Automobilmarkt zwingt einerseits zu einer Verkürzung der Entwicklungs­ zyklen, andererseits nimmt aber die Komplexität der Architektur in der Elek­ tronikvernetzung stetig zu. Kostenredu­ zierung, höhere Sicherheit und Zuverläs­ sigkeit sowie bessere Steuerbarkeit sind die Hauptziele beim Austausch konventi­ oneller gegen elektronisch gesteuerte Systeme. Trotz aller Vorteile darf nicht vergessen werden, dass durch mehr elek­ tronische Komponenten in Fahrzeugen die Wahrscheinlichkeit elektronisch be­ dingter Störungen steigen kann. Da die Zuverlässigkeit der Fahrzeuge für die Kunden ein wesentliches Kriterium beim Neukauf darstellt, ist es unabdingbar neue Methoden einzuführen, um diese Komplexität sicher zu beherrschen, den Entwicklungsprozess zu beschleunigen und die korrekte Funktion der verbauten Steuergeräte zu garantieren. Speziell im Bereich der vom Steuergerät zur Verfü­ gung gestellten Diagnosefunktionalität ist die Korrektheit der Diagnoseservices maßgeblich. Sie transportieren die Infor­ mationen, die dem Mechaniker in der Werkstatt helfen, die Fehlerursache schnell zu finden und abzustellen. An­ hand dieser Informationen muss er in der Lage sein zu entscheiden, auf wel­ ches Bauteil eine Störung zurückgeht und was ausgetauscht werden muss, um die vollständige Betriebsbereitschaft wie­ derherzustellen. Ist dies nicht gewähr­

Automatische Validierung der Diagnoseservices

leistet, kann es zum irrtümlichen Aus­ tausch funktionstüchtiger Einheiten kommen [1], wodurch die Garantiekos­ ten steigen und die Kundenzufriedenheit nachlässt. Die E/E­Architektur des Opel Insignia besteht aus mehreren Controller Area Network­ (CAN) [2] und Local Interconnect Network­ (LIN) Bussystemen [3]. Auf alle Bussysteme wird über einen zentralen Di­ agnoseanschluss (DLC) zugegriffen, Bild 1. Die Kommunikation wird durch ein GM­ spezifisches Protokoll definiert. Diese GM­Diagnosespezifikation basiert auf KWP2000 [4] und dem Standard CAN 2.0A. Sie enthält alle zugelassenen Diag­ noseservices zur Adressierung des Diag­ nosesystems eines Steuergeräts, um die Diagnoseinformationen zu erhalten. Die­ se Services werden dann vom Diagnose­ testgerät ausgegeben, um die Diagnose­ kommunikation herzustellen. Sobald ei­ ne Anfrage gesendet wurde, kann/können das/die adressierte(n) Steuergerät(e) ent­ weder positiv oder negativ antworten: – Positive Antworten enthalten die vom Diagnosegerät angeforderten Diagno­ seinformationen. Fallen viele Diagno­ seinformationen an, kann die Ant­ wort mehrere Nachrichten­Frames umfassen. – Negative Antworten enthalten einen klar definierten Negative Response Code, der auf die Ursache für die ne­ gative Antwort schließen lässt. Die Negative Response Codes werden ge­ mäß der GM­Diagnosespezifikation angegeben.

Erstmalig kam in der Entwicklung bei General Motors Europe (GME) eine vollständig automatisierte Testfallerzeugung zur Validierung der Diagnose zum Einsatz. Der Artikel von GME und Vector Informatik beschreibt die Einführung automatisierter Tests der Diagnoseimplementierung am Beispiel des neuen Opel Insignia. Durch die Integration des Werkzeugs der Vector Informatik in die bestehende Tool-Landschaft ergaben sich wirtschaftliche, zeitliche und prozesstechnische Verbesserungen im Vergleich zur herkömmlichen, manuellen Validierung beim Opel Corsa.

Die Autoren Dr. Philipp Peti ist Entwicklungsingenieur im Bereich Global Systems Engineering bei General Motors Europe in Rüsselsheim.

Dipl.-Ing. Armin Timmerberg ist als Entwicklungsingenieur für die Diagnosevalidierung zuständig im Bereich Global Systems Engineering bei General Motors Europe in Rüsselsheim.

Dipl.-Ing. Thomas Pfeffer ist Gruppenleiter für Diagnose und Testautomatisierung im Bereich Global Systems Engineering bei General Motors Europe in Rüsselsheim.

Dipl.-Inf. Simon Müller ist in der Produktlinie Kfz-Diagnose als Produktmanager verantwortlich für die Canoe Option Diva bei der Vector Informatik GmbH in Stuttgart.

Dipl.-Ing. (BA) Christoph Rätz leitet die Produktlinie Kfz-Diagnose bei der Vector Informatik GmbH in Stuttgart.

Bild 1: E/E-Architektur und Diagnosekommunikation beim Opel Insignia 58

atze-008-0116-y_Vektor_GM_Diagnose.indd 58 4/0

ATZelektronik 06I2008 Jahrgang 3

ATZelektronik 06I2008 Jahrgang 3

1/24/2013 1:33:32 PM

atze-008-0116-y_Vektor_GM_Diagnose.indd 59

59

1/24/2013 1:33:36 PM 4/1

En T wI C K l u n GSPROZESSE

Diagnose

Bild 2: Vergleich der Diagnosevalidierung und Tool-Landschaft bei Opel Corsa und Opel Insignia

Basierend auf den empfangenen Antwor­ ten muss der Techniker in der Lage sein, die Ursache einer Störung zu bestim­ men, um die entsprechenden Arbeiten zur Problemlösung durchzuführen. Der Erfolg einer Fehlerbehebung in der Werkstatt ist deshalb wesentlich da­ von abhängig, dass die vom Diagnosesys­ tem ausgegebenen Daten richtig und ge­ nau sind. Daher ist die korrekte Imple­ mentierung der Diagnoseservices uner­ lässlich, um eine schnelle und fachge­ rechte Instandsetzung beziehungsweise Wartung zur Zufriedenheit der Kunden durchzuführen. Auch am Band­Ende spielt die Diagnose eine wichtige Rolle: Sie wird zur Programmierung von Steuer­ geräten und zur Qualitätssicherung ein­ gesetzt. Aus diesem Grund ist eine um­ fassende Validierung der Diagnosefunk­ tionalität unbedingt erforderlich.

Entwicklung des Corsa die Validierung zum großen Teil manuell durchge­ führt wird, ist bei der Insignia­Ent­ wicklung der überwiegende Teil durch vollautomatisierte Tests abgedeckt. In Bild 3 wird ein typischer Diagnose­ validierungsprozess eines Steuergeräts durch einen Testingenieur bei GME dar­ gestellt. Die Entwicklung der Steuerge­ rätesoftware ist in mehrere Phasen un­ terteilt. Zu Beginn einer Steuergeräteent­ wicklung liegt der Schwerpunkt eher auf der Umsetzung der Steuergerätefunktion als auf den Diagnoseservices. Letztere werden in den nachfolgenden Software­ versionen weiterentwickelt. Wie in Bild 3 dargestellt, wird mit der Einführung der Softwareversion der Phase 1 (SWR 1) nur eine geringe Anzahl an Diagnoseservices implementiert. Durch die Verwendung

von Diagnose­Softwarekomponenten bei GME („CANdesc“) ist bei Entwicklungs­ start schon ein Teil des Diagnoseumfangs implementiert und damit die Integrati­ on im Steuergerät früher fertig gestellt (siehe Bild 3). Mit jedem Entwicklungszyklus nimmt die Menge der zu prüfenden Diagnose­ funktionen zu. Sind alle Diagnoseser­ vices implementiert, werden Regres­ sionstests durchgeführt (SWR 7). Wenn keine Fehler der Diagnoseservices im je­ weiligen Entwicklungsstadium mehr er­ fasst werden, ist das Steuergerät im Hin­ blick auf die Ausführung von Diagnose­ services serienreif. Da ein Testingenieur normalerweise mehrere Steuergeräte gleichzeitig prüft, ist es ihm ohne adäquate Tool­Unterstüt­ zung nicht möglich, die große Anzahl an Tests vorzunehmen, um alle implemen­ tierten Diagnoseservices der einzelnen Softwareversionen abzudecken. Folglich werden nur neu implementierte Diagno­ seservices eingehend geprüft und, basie­ rend auf der Erfahrung des Testingeni­ eurs, exemplarisch Regressionstests für einzelne früher integrierte Services durchgeführt. Mit der Verwendung eines geeigneten Automatisierungswerkzeugs für die Validierung können mehr Tests bei gleichzeitig reduziertem Aufwand durchgeführt werden.

3 Anforderungen in Bezug auf das Validierungswerkzeug Ein Werkzeug zur automatisierten Diag­ nosevalidierung muss folgenden Anfor­ derungen genügen:

2 Validierungsprozess und Tool-Landschaft bei GME Mit der Entwicklung des Opel Insignia hat GME das Werkzeug „CANoe.DiVa“ (Diagnostic Integration and Validation Assistant) von Vector Informatik neu eingeführt. Das Werkzeug automati­ siert die Erzeugung und die Durchfüh­ rung von Diagnosetests. Bild 2 zeigt die verwendete Tool­Landschaft beim Opel Corsa und beim Opel Insignia. In bei­ den Fällen wird „CANoe“ [5] als Test­ werkzeug verwendet. Während bei der 60

4 Von der Spezifikation zur Testdurchführung und Berichtsauswertung Wie in Bild 2 dargestellt, stellt „DiVa“ das Bindeglied zwischen „CANdelaStu­ dio (Diagnosespezifikation) und dem bewährten Werkzeug zur Validierung dar. „DiVa“ integriert sich nahtlos in di­ ese bei GME bestehende und etablierte Werkzeugkette. Aus der Diag­ nosespezifikation (CDD­Datei) werden Testfälle zur Überprüfung der jewei­ ligen Services automatisch abgeleitet. Der generierte Code basiert auf der „CA­ Noe“­Programmiersprache CAPL (Com­ munication Access Programming Lan­ guage) und kann somit jederzeit einge­ sehen werden. Der Testingenieur hat die Möglichkeit, bei Unstimmigkeiten in den automatisierten Ablauf einzugrei­ fen und diesen nachzuvollziehen (Trans­ parenz). Darüber hinaus ermöglichen die Logging­Funktionen von „CANoe“ die Rückverfolgung und die Auswertung des Diagnosedatenflusses auf CAN­Kom­ munikationsebene. Folgende Schritte sind notwendig, um einen Test mit „DiVa“ durchzuführen: – Auswählen des Steuergeräts und der Variante – Konfiguration des Tests – Generierung des Tests – Einfügen des erzeugten Testmoduls in die Testumgebung – Ausführen der Tests – Auswerten des Testreports.

ATZelektronik 06I2008 Jahrgang 3

atze-008-0116-y_Vektor_GM_Diagnose.indd 60 4/2

Bild 3: Umfang der Diagnosefunktionen in verschiedenen Phasen der Steuergeräteentwicklung bei GME

– nahtlose Integration in die vorhande­ ne Werkzeugkette – Transparenz und Reproduzierbarkeit: Der Testingenieur muss die durchge­ führten Tests nachvollziehen und wie­ derholen können. – Konformität im Hinblick auf die be­ stehenden Testverfahren von General Motors: Das Werkzeug muss bestehen­ de Testverfahren unterstützen. Im Be­ reich der Diagnose definiert die GM­ Diagnosespezifikation bereits ver­ bindliche Prüfabläufe für die GMLAN­ Diagnoseservices der Steuergeräte. – Erweiterbarkeit durch den Testinge­ nieur – automatische Generierung von Test­ fällen: Hierzu muss die Spezifikation in einem maschinell lesbaren Format vorliegen.

Das Ändern von Testrandbedingungen in „DiVa“ ist jederzeit durch den Benut­ zer möglich. Unter anderem wird der Intensity­Parameter genutzt, um den Testumfang zu konfigurieren, beispiels­ weise vollständiger Test, Schnelltest oder Gutfalltest. Zusätzlich hat der Be­ nutzer unter Supported Services die Möglichkeit, bestimmte Services vom Test auszuschließen und unter Data­ Customization­Dateninhalte der Ser­ vices zu verändern, Bild 4. Bei einer Aktualisierung der Diagno­ sespezifikation, also der CDD­Datei, er­ möglicht „DiVa“ die Synchronisierung mit der neuen Spezifikation unter Bei­ behaltung der zuvor definierten Einstel­ lungen. Aus technischer Sicht generiert „Di­ Va“ CAPL­Code für das „CANoe“­Testmo­ dul zum Test aller vom Steuergerät un­ terstützten Diagnoseservices. Um die Konformität mit der GM­Diagnosespezi­ fikation sicherzustellen, bildet die „Di­ Va“­Erweiterung die Testprozeduren dem GM­Standard entsprechend ab. Der Test­Generierungsprozess erzeugt eine ausführliche Beschreibung der ge­ nerierten Testfälle, CAPL­Testcodes für das Testmodul und die dazugehörige Testumgebung.

5 Testdurchführung und -berichtsauswertung Nachdem der Test generiert ist, öffnet der Anwender in „CANoe“ die erzeugte Testumgebung und startet den Test. Die Testdauer hängt von der Komplexität der Diagnosespezifikation und der benutzer­ definierten Auswahl des Testumfangs ab und schwankt von wenigen Minuten bis zu mehreren Stunden, Tabelle 1. Die „CA­ Noe“­Testumgebung fungiert bei General Motors als gemeinsame Plattform zur Testautomatisierung und vereinfacht die Wiederverwendung von bestehenden GM­Testprogrammen. Beispielsweise sind die Bandende­Flash­Testprozeduren eben­ falls in der „CANoe“­Programmierspra­ che CAPL programmiert. Um die Analyse durch den Testingenieur zu erleichtern sind die Testberichte entsprechend der GM­Diagnosespezifikation strukturiert. Bild 5 zeigt einen typischen Testbericht.

6 Testabdeckung Durch die Automatisierung der Tests soll der Testumfang erweitert und gleichzei­ tig der Zeitaufwand für die Durchfüh­ rung verkürzt werden. Inwieweit „DiVa“ die in der GM­Diagnosespezifikation be­ schriebenen Testabläufe abdeckt, wird nachfolgend beschrieben. Die Qualität und die Anzahl der generierten Testfälle hängen wesentlich von der Vollständig­ keit der maschinenlesbaren Diagnose­ spezifikation ab. Alle generierten Tests werden von ihr abgeleitet. Insgesamt sind rund 350 Testabläufe in der GM­Diagnosespezifikation defi­ niert. Die Testabläufe umfassen sowohl „Gutfall“­ als auch „Schlechtfall“­Tests. Ein großer Teil (etwa 80 %) der Testabläu­ fe wird in „DiVa“ über vollständig auto­ matisierte Tests abgedeckt. Für 45 (15 %) der in der GM­Diagnosespezifikation de­ finierten Testabläufe ist eine applikati­ onsspezifische Benutzereingabe erfor­ derlich. In diesem Fall hält „DiVa“ die Testdurchführung an und fordert den Benutzer auf, das Steuergerät in den er­ forderlichen Zustand zu versetzen. Die verbleibenden 5 % der Testabläufe wer­ den von „DiVa“ nicht unterstützt und müssen entweder manuell oder mit an­ deren Mitteln getestet werden. Hierzu zählen auch Tests, die den sonstigen Tes­ tablauf gefährden würden (zum Beispiel Erzeugung und Erkennen von EEPROM­ Fehlern) oder das Steuergerät nachhaltig verändern (beispielsweise ein Steuerge­ rät ohne Applikationsdaten). Die Test­ tiefe wird durch das Ausführen von zu­ sätzlich enthaltenen, nicht GM­spezi­ fischen Testfällen weiter erhöht. Laut den bei GME durchgeführten Vergleichen der Validierung beim Opel Corsa und Insignia, verkürzt „DiVa“ durch die meist automatische Ausfüh­ rung aller generierten Testfälle die Test­ durchführungszeit massiv, Bild 6. Tabel­ le 1 zeigt eine Übersicht über die Durch­ führungszeiten und die Anzahl an gene­ rierten Testfällen für Steuergeräte im Opel Insigna. Manuelle Tests können wegen des Zeitaufwands oft nur spora­ disch durchgeführt werden. Das Tester­ gebnis ist daher stark von der Erfahrung des Testingenieurs und der zur Verfü­ gung stehenden Zeit abhängig. „DiVa“ ermöglicht bei GME sowohl den voll­ ständigen Test der Steuergeräte entspre­ ATZelektronik 06I2008 Jahrgang 3

1/24/2013 1:33:39 PM

atze-008-0116-y_Vektor_GM_Diagnose.indd 61

61

1/24/2013 1:33:39 PM 4/3

En T wI C K l u n GSPROZESSE

Diagnose

rungszeit. In diesem Stadium der Opel­ Insignia­Entwicklung kann, je nach Komplexität des Steuergeräts, eine Effi­ zienzsteigerung um den Faktor 20 bis 40 erreicht werden. Der Kostenaufwand der neuen Lösung ist gering, da nur Lizenzen für „DiVa“ be­ nötigt werden. Ein mit „CANoe“ ver­ trauter Anwender bei GME kann, ohne vorherige Schulung, Tests durchführen. Zusätzliche Hardware ist zur Testdurch­ führung nicht erforderlich: „DiVa“ ver­ wendet die verfügbare CAN­Infrastruktur über „CANoe“. Bild 4: Einstellen der Testrandbedingungen in Diva (hier: Konfiguration der Services)

8 Grenzen der automatischen Generierung von Testfällen und Durchführung der Tests chend den Diagnosespezifikationen, als auch einen größeren Testumfang in al­ len Entwicklungsstadien.

7 Wirtschaftliche Aspekte und Effizienzsteigerung Bei der Einführung eines Werkzeugs steht der wirtschaftliche Nutzen im Vor­ dergrund. Der neue Opel Corsa ist auf dem Markt sehr erfolgreich, es gibt keine negative Rückmeldung in Bezug auf diag­ nosebedingte elektronische Störungen. Daher wurde die manuell betriebene Va­ lidierung beim Opel Corsa als Referenz­ projekt ausgewählt. Im Gegensatz dazu stand beim neuen Opel Insignia die Ver­ wendung von „DiVa“ als Hauptwerkzeug zur Validierung der Diagnoseservices. Damit wurden erstmals Validierungs­ tests zum großen Teil automatisiert durchgeführt. Zu Vergleichszwecken ist die Zeit ausgewertet, die für die Validie­ rungsphase Testdurchführung und ­aus­ wertung auf Basis repräsentativer Steuer­ geräte benötigt wurde. Die genannten Werte basieren auf dem Implementie­ rungslevel SWR 5, Bild 3. Die meisten Services sind hier schon implementiert und eine große Anzahl an fehlgeschla­ genen Testfällen wurde bereits erfasst. Bild 6 zeigt den Validierungsaufwand in Stunden für den manuellen Test beim Opel Corsa und den automatisierten Test beim Opel Insignia. Durch den Einsatz von „DiVa“ lassen sich die Durchführungs­ und Auswerte­ zeiten beim Opel Insignia gegenüber de­ 62

nen beim Corsa erheblich verkürzen. Im vorliegenden Fall wird eine Verbesserung um den Faktor 3­5 erreicht (siehe Bild 6). Insbesondere bei Steuergeräten mit einer großen Anzahl von Diagnoseservices ist die Zeitersparnis enorm. Betrachtet man spätere Entwicklungsphasen wie SWR 6 oder SWR 7 nimmt die zum Auswerten der Testergebnisse benötigte Zeit weiter ab. Dies ist auf die geringere Anzahl fehl­ geschlagener Testfälle in der besser aus­ gereiften Implementierung zurückzu­ führen. Dieser Trend setzt sich bis zum Produktionsstart in jeder neuen Phase fort. Das serienreife Steuergerät darf kei­ ne Störungen aufweisen, folglich ent­ spricht die Auswertezeit der Durchfüh­

Auch wenn automatisierte Werkzeuge im Hinblick auf Testumfang und Zeitauf­ wand besser sind als manuelle Teststrate­ gien, stößt die automatische Testerzeu­ gung an Grenzen: – Qualität der Spezifikation: Da die Spe­ zifikation die Grundlage für die Gene­ rierung von Testfällen darstellt, ist die Vollständigkeit und die Richtigkeit der Spezifikationen unerlässlich, das heißt, der Test kann nur so gut sein wie die Spezifikation. Darüber hinaus muss die Konformität mit den Anfor­ derungen an die Diagnoseinfrastruk­ tur von General Motors (GGSE­I) gege­ ben sein [6]

– Reproduzierbarkeit: Durch die nicht­ deterministischen Eigenschaften der CAN­Kommunikation in einem Fahr­ zeug können bestimmte Fehlersituatio­ nen beim Testen nur schwer reprodu­ ziert werden. – Folgefehler: Im Fehlerfall kann das automatisierte Testwerkzeug, im Ge­ gensatz zu einem Testingenieur, nicht zwischen einer ursprünglichen Stö­ rung und einer Folgestörung unter­ scheiden. – Benutzerinteraktion: Bei applikations­ spezifischen Tests kann es erforder­ lich sein, das Steuergerät in einen Zu­ stand zu versetzen, für den zusätz­ liche Hardware erforderlich ist. Diese Fälle können mit dem dargestellten Ansatz nicht vollautomatisiert behan­ delt werden.

9 Zusammenfassung Ohne den Einsatz von Testautomatisie­ rungs­Werkzeugen ist es kaum möglich, die Diagnosefunktionalität moderner Fahrzeuge im gewünschten Umfang zu validieren. CanoeDiva ist zur Unterstüt­ zung aller etablierten Testverfahren an die GM­Anforderungen angepasst wor­ den und fügt sich nahtlos in die vor­ handene Werkzeugkette von General Motors Europe ein. Es wird als automa­ tisiertes Testwerkzeug zur Validierung der Diagnoseservices beim neuen Opel Insignia eingesetzt. Mit „DiVa“ verkürzt GME nicht nur die Testdauer, sondern erhöht gleichzei­ tig die Testintensität durch die Möglich­ keit häufiger Regressionstests. Darüber hinaus wird der Testumfang durch das Ausführen von zusätzlichen nicht GM­ spezifischen Testfällen erweitert. Im di­ rekten Vergleich zur manuellen Validie­ rung bei erfolgreichen Vorgängerpro­ jekten wird die Effizienz sowohl tech­ nisch als auch wirtschaftlich signifikant gesteigert. Je nach Entwicklungsphase und Qualität der Implementierung ist eine Effizienzsteigerung um Faktor 4 bis 20 realistisch. Gleichzeitig wird der ho­ hen Erwartung der Kunden hinsichtlich Qualität Rechnung getragen.

Tabelle 1: Durchführungszeiten und Anzahl generierter Testfälle für Steuergeräte im Opel Insigna Insignia Steuergerät

Generierte Testfälle

Durchführungszeit (ohne Benutzerinteraktion für DTC-Prüfung)

Kombi Instrument

1700

13:25 min

Klimasteuerung

3350

39:10 min

Airbag

4630

1:19:32 min

Mobil Telefon

1120

11:05 min

Literaturhinweise

[1] Thomas, D.; Ayers, K.; Pecht, M.: The “trouble not identified” phenomenon in automotive electronics. In: Microelectronics reliability, Vol. 42, S. 641-651, 2002 [2] lIn Consortium: lIn Specification Package Revision 2.1, OV. 2006 [3] Robert Bosch GmbH: CAn-Spezifikation 2.0, 1991 [4] International Organization for Standardization: Keyword Protocol 2000, ISO 14230, 1999 [5] Krauss, S.: Testing with CAnoe, Application note An-InD-1-002. Vector Informatik, 2005 [6] General Motors. GGSE ECu Diagnostic Infrastructure Requirements, Version 1.07, 2007

Bild 6: Testaufwand pro Steuergerät beim Opel Corsa mit manueller Validierung, im Vergleich zu automatisierter Validierung der Diagnoseservices beim Opel Insignia (Durchführungs- und Auswertezeit)

Bild 5: Automatisch generierter Testbericht in Diva

ATZelektronik 06I2008 Jahrgang 3

ATZelektronik 06I2008 Jahrgang 3

63

Erschienen in ATZ elektronik, 6/2008 atze-008-0116-y_Vektor_GM_Diagnose.indd 62 4/4

1/24/2013 1:33:43 PM

atze-008-0116-y_Vektor_GM_Diagnose.indd 63

1/24/2013 1:33:44 PM 4/5

20

l

AUTOMOTIVE

10. 2 0 11

l

ENGINEERING TOOLS

ENGINEERING TOOLS

■ Berücksichtigung der Sicherheitsanforderungen nach

TEIL 1: DIAGNOSE MIT AUTOSAR

Die Standard-Mischung macht’s:

Diagnose mit AUTOSAR und ODX

ISO 26262. AUTOSAR ist heute die Referenzarchitektur für die Steuergerätesoftware. Die ersten Serienanläufe mit vollständiger AUTOSAR-Software stehen kurz bevor. Die Anzahl der Entwicklungsprojekte nach AUTOSAR-Methodik nimmt stetig zu. Das AUTOSAR-Konsortium arbeitet momentan an den Versionen 3.2 und 4.x. In der Vergangenheit wurden unter anderem die Versionen 2.x, 3.x und 4.0 freigegeben, auf deren Basis bereits Fahrzeugprojekte realisiert wurden. Heute arbeiten die meisten Fahrzeughersteller auf den Versionen 3.x. Die Funktionsorientierung gewinnt in der Elektronikentwicklung zunehmend an Bedeutung. AUTOSAR standardisiert die Beschreibung einzelner Teil- oder Fahrzeugfunktionen und die Beschreibung des Gesamtsystems in der sogenannten System Configuration Description. Die Methodik zur Verteilung der Fahrzeugfunktionen auf Steuergeräte ist ebenfalls standardisiert. Entwickelte Funktionen können so in weiteren Fahrzeugprojekten unverändert wiederverwendet werden. Das Beispiel in Bild 1 verdeutlicht dies. Für jedes Steuergerät gibt es in AUTOSAR einen ECU Extract of the System Configuration, welcher den relevanten Systemanteil des Steuergerätes – und somit oft auch eines Zulieferers – umfasst. Die elementaren Bestandteile der AUTOSAR-Architektur für Steuergerätesoftware sind: ■ Funktionssoftware (SWC), ■ Run-Time-Environment (RTE),

l

AUTOMOTIVE

10. 2 0 11

l 21

■ Basissoftware (BSW). Die hohe Wiederverwendbarkeit der Funktionssoftware ergibt sich aus der Abstraktion der Kommunikation durch den Virtual Function Bus (VFB). Die Anwendung kann ohne Kenntnis der zugrunde liegenden Kommunikationsmechanismen entwickelt und getestet werden. Dabei spielt es keine Rolle, ob die Kommunikation innerhalb des Steuergerätes oder über ein Netzwerk (CAN, FlexRay, …) erfolgt. Die Run-Time-Environment (RTE) dient als Laufzeitumgebung für die Funktionssoftware und realisiert den Virtual Function Bus für ein konkretes Steuergerät. Die Basissoftware wird als Komponentenbaukasten entwickelt und ist am Markt verfügbar (Commercial-Off-TheShelf). Sie ist in drei Bereiche untergliedert (Bild 2): ■ Der Service Layer stellt Basisdienste für die Funktionssoftware und andere Basissoftwaremodule bereit. ■ Der ECU Abstraction Layer abstrahiert höhere Schichten von der Steuergerätehardware. ■ Der Microcontroller Abstraction Layer abstrahiert höhere Schichten vom konkreten Microcontroller. Die Basissoftware und die RTE werden mithilfe der ECU Configuration Description konfiguriert. Initial wird diese Konfiguration aus dem ECU Extract of the System Configuration Description erzeugt (zum Beispiel Kommunikation über das Netzwerk). Die ECU Configuration Description spielt für das Verhalten der gesamten Steuergerätesoftware eine zentrale Rolle und wird im Laufe der Weiterentwicklung nach und nach erweitert und angepasst.

AU TO S A R i s t d i e z u k u n f t swe i s e n d e R e fe re n z a rc h i t e k t u r f ü r S t e u e rg e r ä t e s o f t wa re . D i e D i a g n o s e w i rd i n AU TO S A R i n d e n M o d u l e n D C M ( Ko m m u n i k at i o n ) u n d D E M ( Fe h l e rs p e i c h e r ) b e h a n d e l t . D i e s e r B e i t ra g g e h t z u n ä c h s t a u f d i e D i a g n o s e i n AU TO S A R m i t d e n z u g e h ö r i g e n D at e n fo r m at e n e i n . E i n e A l t e r n at i ve z u r Ko n fi g u rat i o n d e r D i a g n o s e s o f t wa re s i n d B e s c h re i b u n g s d at e n i m O D X - Fo r m at ( O p e n D i a g n o s t i c D at a E x c h a n g e ) . Au f d a s Th e m a „ O D X i m AU TO S A R - E n t w i ck l u n g s p ro z e s s “ w i rd i m n ä c h s t e n H e f t eingegangen.

I

n der Elektronikentwicklung der Automobilindustrie liegt die Standardisierung voll im Trend. Die Verwendung von offenen Architekturen und konfigurierbaren Komponenten soll es ermöglichen, sich stärker auf den innovativen und differenzierenden Anteil der Entwicklung zu fokussieren. Außerdem soll sie auch als zentrale Maßnahme zur Kostensenkung beitragen. Die Architektur von Steuergerätesoftware in Kraftfahrzeugen war bisher nicht standardisiert. Für den Zulieferer hatte dies jeweils unterschiedliche, herstellerspezifische Software-Architekturen zur Folge, verbunden mit unterschiedlichen Entwicklungsprozessen, Entwicklungswerkzeugen und Datenaustauschformaten. AUTOSAR hat sich zum Ziel gesetzt, eine

4/6

gemeinsame, offene Automobil-Software-Architektur zu standardisieren. Die wesentlichen Ziele der AUTOSAR-Architektur sind: ■ Hardware-Abstraktion, ■ Eindeutig spezifizierte Schnittstellen, ■ Standardisiertes Verhalten der Basissoftware, ■ Standardisierte Datenaustauschformate zwischen OEM und Zulieferer, ■ Definition einer harmonisierten Methodik für die Entwicklung der Software, ■ Unterstützung der modellbasierten Funktionsentwicklung, ■ Skalierbarkeit über alle Steuergeräte- und Fahrzeugklassen,

Bild 1: Die Fahrzeugfunktion Lighting aus der Function Library ist in drei Teilfunktionen untergliedert. Im Fahrzeug A werden die Teilfunktionen auf zwei Steuergeräte des Netzwerks verteilt, im Fahrzeug B unverändert auf drei Steuergeräte. Die Kommunikation zwischen den Teilfunktionen ist in der System Configuration Description definiert. © automotive

4/7

22

l

AUTOMOTIVE

10. 2 0 11

l

ENGINEERING TOOLS

Diagnose mit AUTOSAR Die Diagnosesoftware in AUTOSAR besteht aus drei Modulen: DCM, DEM und FIM. Der Diagnostic Communication Manager (DCM) realisiert die Diagnosekommunikation gemäß ISO 14229-1 (UDS) und SAE J1979 (OBDII). Alle Diagnoseanfragen werden zunächst vom DCM vorverarbeitet. Eine der Aufgaben des DCM besteht in der umfassenden Behandlung von ungültigen Diagnoseanfragen. Ein Großteil der gültigen Anfragen kann bereits vollständig durch den DCM bearbeitet werden, andere leitet er an die Funktionssoftware weiter. Mit jedem AUTOSARRelease hat der Funktionsumfang des DCM weiter zugenommen, entsprechend hat der verbleibende Diagnoseanteil der Funktionssoftware stetig abgenommen. In Bild 3 ist diese Entwicklung am Beispiel der Behandlung eines DIDs dargestellt. Bis zur Version 3 mussten Signalstrukturen in der Funktionssoftware aufgelöst werden. In der Version 4 kann diese Aufgabe auch vom DCM übernommen werden. Der DCM wird mithilfe einer ECU Configuration Description konfiguriert. Diese enthält unter anderem die ServiceIdentifier, Subfunktionen, Data-Identifier (mit der zugehörigen Signalstruktur) und Routine-Identifier (mit den Parameterlisten). Außerdem kann man die Ausführbarkeit der Diagnoseanfragen vom aktuellen Steuergerätezustand (Session und Security Level) abhängig machen.

ENGINEERING TOOLS

AUTOMOTIVE

10. 2 0 11

l 23

Der Diagnostic Event Manager (DEM) realisiert einen Fehlerspeicher. Bis zur AUTOSAR Version 3.x (einschließlich) ist der DEM nur als Fassade spezifiziert, da das Verhalten des Fehlerspeichers im Detail herstellerspezifisch ist. Seit der Version 4 wird das Ziel verfolgt, einen Fahrzeughersteller-unabhängigen Fehlerspeicher zu standardisieren, sodass auch das Verhalten in AUTOSAR festgelegt wird. Der DEM hat im Wesentlichen folgende Aufgaben: ■ Verwaltung der DTC-Status Bits, ■ Organisation der Fehlerablage, inklusive NVRAM, ■ Organisation der Snapshot Daten (Freeze Frame), ■ Verwaltung der Extended Data Records, ■ Verlernen von Fehlern, ■ Bereitstellung einer Schnittstelle zum Fehlerauslesen für den DCM. Ein standardisiertes Interface sowie unterschiedliche Entprell-Algorithmen für Diagnose-Monitore (Fehlerpfad) ermöglichen eine einheitliche und projektübergreifende Entwicklung der Funktionssoftware. Ein oder mehrere Fehlerpfade können auf einen Diagnostic Trouble Code (DTC) abgebildet werden. Auch der DEM wird mithilfe der ECU Configuration Description konfiguriert. Diese enthält unter anderem Informationen rund um Fehlerpfade, DTC-Nummern und den Aufbau der erweiterten Fehlerdaten (Snapshot und Extended Data Records).

Bild 3: Behandlung eines DIDs: Bis zur Version 3 mussten Signalstrukturen in der Funktionssoftware aufgelöst werden. In der Version 4 kann diese Aufgabe auch vom DCM übernommen werden. © automotive

Der FIM (Function Inhibition Manger) bietet die Möglichkeit, im Fall von aktiven Fehlern die Ausführung bestimmter Funktionen zu unterbinden, Ersatzfunktionen zu starten und Folgefehler zu unterdrücken. Auch der FIM wird mit Hilfe der ECU Configuration Description konfiguriert. Basissoftwaremodule für die Diagnose mit AUTOSAR Vector bietet mit MICROSAR eine AUTOSAR-Lösung für Steuergeräte-Software bestehend aus RTE und den Basissoftwaremodulen an, die den gesamten Umfang des AUTOSAR-Standards abdecken. Jedes AUTOSAR BSWModul ist einem MICROSAR-Paket zugeordnet. Speziell für die Diagnose ist das Paket MICROSAR DIAG erhältlich. Es enthält die drei BSW-Module DCM, DEM und FIM aus der AUTOSAR-Architektur. Fahrzeugprojekte erhalten mit MICROSAR DIAG als Diagnosesoftware eine AUTOSARkompatible Umsetzung des UDS-Protokolls ISO 142291:2006. (oe) Teil 2 „ODX im AUTOSAR-Entwicklungsprozess“ erscheint im nächsten Heft (Hanser Automotive 11/2011).

Bild 2: Die Basis-Software enthält grundlegende Systemfunktionen und abstrahiert die Funktionssoftware von der Hardware. © automotive

4/8

l

Literatur [1] AUTOSAR Spezifikationen: www.autosar.org [2] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Wege zur Steuergeräte-Software Teil 1, Elektronik automotive 11.2009 [3] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Wege zur Steuergeräte-Software Teil 2, Elektronik automotive 12.2009 [4] ISO 14229: Road vehicles – Unified diagnostic services (UDS) [5] ISO 26262: Road vehicles – Functional safety

[6] ISO 22901: Road vehicles – Open diagnostic data exchange (ODX) [7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetzliche On-Board-Diagnose und ODX, Diagnose in mechatronischen Fahrzeugsystemen III S. 44 ff., Expert-Verlag 2010

Dr. Klaus Beiter leitet ein Entwicklungsteam in der Produktlinie Kfz-Diagnose bei der Firma Vector Informatik GmbH in Stuttgart. Er ist Mitglied in der ASAM/ISO ODX-Arbeitsgruppe.

Dipl-Ing. (BA) Christoph Rätz leitet die Produktlinie Kfz-Diagnose bei der Firma Vector Informatik GmbH in Stuttgart.

Dipl Ing. (FH) Oliver Garnatz ist bei Vector als Produkt-Manager im Bereich EmbeddedSoftware-Komponenten tätig. Er ist Mitglied in der ISO im Bereich Kfz-Diagnose sowie in AUTOSAR.

@

Vector Informatik www.vector.com

4/9

16

l

AUTOMOTIVE

11. 2 0 11

l

ENGINEERING TOOLS

ENGINEERING TOOLS

ODX IM AUTOSAR-ENTWICKLUNGSPROZESS

Die Standard-Mischung macht’s:

Diagnose mit AUTOSAR und ODX Teil 2

D i e s e r B e i t ra g i s t d e r z we i t e Te i l d e r R e i h e „ D i a g n o s e m i t AU TO S A R u n d O D X “ u n d b e h a n d e l t d a s Th e m a O D X u n d w i e

ve r f ü g b a re O D X - D at e n g ew i n n b r i n g e n d i n d i e AU TO S A R - E n t w i ck l u n g i n t e g r i e r t we rd e n k ö n n e n .

O

DX wurde im Rahmen einer ASAM/ISO-Arbeitsgruppe seit 2003 zunächst im ASAM und später in der ISO standardisiert. Die Notwendigkeit für die ODX-Entwicklung ergab sich aus der mangelnden Akzeptanz der damals bestehenden Standards zur Beschreibung von Diagnosedaten. Der Austausch von Diagnosedaten über Prozessgrenzen hinweg war nur mit erheblichem Aufwand möglich. Ein wichtiges Ziel der ODX-Standardisierung ist die Daten-Wiederverwendung. Die Daten sollen mit verschiedenen Werkzeugen auch in unterschiedlichen Unternehmensbereichen eingesetzt und weiter verarbeitet werden können Das ODX-Datenmodell in der Version 2.2.0 besteht aus sieben Teilmodellen (Bild 4). Der Fokus der Standardisierungsaktivitäten lag auf der Parametrierung von Diagnosetestern. Deshalb sind die unteren drei Teilmodelle mit der Definition der Diagnosedienste, den Kommunikationsparametern und der Beschreibung der Fahrzeugzugänge das Herzstück des Standards. In den oberen vier Teilmodellen sind Flash-Container, Steuergerätekonfiguration, funktionsorientierte Diagnose und sogenannte Multiple ECU Jobs beschrieben. Ihre Verbreitung und Bedeutung ist nie-

4/10

driger im Vergleich zu den erst genannten Teilmodellen. Im Weiteren werden hier nur ODX-D und ODX-FD vertieft, da diese beiden Kategorien im Zusammenhang mit AUTOSAR von besonderem Interesse sind. ODX-D enthält die Service-Beschreibung mit der Definition der DiagnoseAnfragen und den zugehörigen Antworten samt der Interpretation der übertragenen Daten. ODX-FD stellt einen Aufsatz auf ODX-D dar, in dem die Diagnose-relevanten Aspekte der Fahrzeugfunktionen beschrieben werden. Funktionen lassen sich hierarchisch aufbauen und auch nach beliebigen Kriterien gruppieren. Jeder Funktion können Ein-/Ausgabeparameter und Diagnosedaten (z. B. DTC, DID, …) zugeordnet werden. Die Konkretisierung dieser Daten samt der Zuordnung zu Diagnosediensten erfolgt über Referenzen in den ODX-D-Teil. ODX-FD stellt also im Wesentlichen eine Dokumentation der Fahrzeugdiagnose aus Sicht der Funktionen dar. Wenn Probleme in einer Fahrzeugfunktion auftreten, so kann anhand der ODX-FD-Daten der Zusammenhang zwischen der Funktion und den möglichen Fehlerquellen – also Steuergeräten, Sensoren und Aktoren – hergestellt werden. ODX wurde 2008 als ISO-Standard 22901-1 verabschiedet.

Bild 4: ODX-Kategorien. Die unteren drei Teilmodelle bilden gleichzeitig den typischen Umfang, der für die Kommunikation eines Testgeräts mit einem oder mehreren Steuergeräten inklusive der Dateninterpretation erforderlich ist. © automotive

Die erste Version des Standards wurde 2004 vom ASAM als ODX 2.0.0 herausgegeben. Dazwischen lagen zwei weitere Ausgaben, in die Korrekturen, Klarstellungen, Verbesserungen und Erweiterungen eingeflossen sind (Bild 5).

l

AUTOMOTIVE

11. 2 0 11

l 17

dass er möglichst viele Fahrzeug- oder Steuergerätekonfigurationen unterstützt. Durch eine mehrdeutige Beschreibung der Testerdaten gewinnt man hier an Flexibilität. So ist es in ODX möglich, mehrere Steuergeräteantworten für einen Diagnosedienst zu beschreiben. Zur Laufzeit wird die passende Antwort zur Dekodierung der Diagnosedaten herangezogen. Das ist dann besonders hilfreich, wenn nicht ganz klar ist, welche Software genau auf dem Steuergerät läuft. Für die Code-Generierung hingegen ist eine eindeutige, exakte Datenbeschreibung in Spezifikationsqualität unerlässlich. Es ist offensichtlich, dass die Beschreibung mit mehreren Antworten nicht zur Steuergerätesoftware-Generierung herangezogen werden kann, da das Steuergerät eindeutig (auf definierte Art und Weise) auf eine Diagnose-Anfrage reagieren muss. Das Beispiel zeigt, dass die Anforderungen an die (Qualität der) Diagnosedaten für beide Anwendungsfälle unterschiedlich – sogar widersprüchlich – sind.

Die folgende Liste zeigt einige Datenkonstellationen, die den Spezifikationscharakter verletzen: ■ Mehrere Antworten auf eine Diagnoseanfrage (siehe oben). ■ Diagnosedienste, die für das zugrunde liegende Protokoll nicht definiert sind, z. B. KWP-Dienste in einem UDSSteuergerät.

ODX und Steuergerätesoftware ODX lässt dem Autor der Diagnosedaten weitreichende Freiheiten, was die verwendeten Strukturen angeht. Ein und dasselbe Verhalten kann unterschiedlich beschrieben werden. Diagnosedaten können so optimal für die Verwendung in bestimmten Testsystemen vorbereitet werden. Allerdings ist die Unterstützung aller denkbaren Variationen des Standards in verarbeitenden Werkzeugen nach wie vor eher Anspruch als Wirklichkeit. Die Austauschbarkeit der Daten ist so lange gegeben, wie die verwendeten Strukturen in beiden Welten unterstützt werden. Ein gängiges Mittel, um den austauschbaren Umfang festzuschreiben, sind Autorenrichtlinien. Sie geben den Prozesspartnern Art und Umfang der zu verwendenden ODX-Untermenge vor. Dieses Vorgehen ist heute etabliert. Auch die an der ODX-Standardisierung beteiligten OEMs griffen das Vorgehen auf und schufen eine Autorenrichtlinie für den Datenaustausch zwischen Fahrzeugherstellern (ODX-RS, Recommended Style). Die Hauptmotivation der ODX-Standardisierung war die Parametrierung datengetriebener Testsysteme. In anderen Einsatzgebieten sind die Daten nur eingeschränkt verwendbar, da verschiedene Einsatzzwecke unterschiedliche Anforderungen Bild 5: ODX-Historie. an die Struktur und den Detaillierungsgrad stellen. Von einem generischen Tester wird erwartet,

© automotive

4/11

18

l

AUTOMOTIVE

11. 2 0 11

l

ENGINEERING TOOLS

Bild 6: Behandlung eines DIDs: Bis zur Version 3 mussten Signalstrukturen in der Funktionssoftware aufgelöst werden. In der Version 4 kann diese Aufgabe auch vom DCM übernommen werden. © automotive

■ Mehrere Diagnosedienste mit derselben Service-Signa-

tur (SID/LID), sodass ein eindeutig definiertes Steuergeräteverhalten nicht abgeleitet werden kann. ■ Nutzung spezieller Kontextkonventionen im Fehlerspeicher: Die detaillierte Beschreibung des Fehlerspeichers in ODX ist nicht Gegenstand des Standards. Es ist zwar prinzipiell möglich, Zusatzinformationen zu DTCs zu beschreiben, der Standard gibt hier aber nur die Form (SDG = verschachtelte Liste von Name-Wert-Paaren) vor. Die Semantik der Daten hingegen ist nicht definiert und die generische Verarbeitung in automatisierten Werkzeugen somit nicht möglich. ■ In der weit verbreiteten ODX-Version 2.0.1 fehlt ein Mechanismus, um die Abhängigkeit eines Diagnosedienstes von Sessions/Security-Levels zu beschreiben. Die entsprechenden Ausführbarkeitsüberprüfungen und daraus resultierende ablehnende Antworten sind also nicht generierbar, sondern müssen in der individuellen Applikation umgesetzt werden. In der Version ODX 2.2.0 besteht das Problem nicht mehr. Hier lassen sich die Zustandsinformation formal beschreiben. Die Liste zeigt, dass Konformität zum ODX-Standard notwendig, aber nicht hinreichend für die Parametrierung von Softwarekomponenten ist. Die im Standard definierten Checkerregeln decken in erster Linie den Anwendungsfall der Testerparametrierung ab. Um Spezifikationsqualität der Daten sicher zu stellen, sind zahlreiche zusätzliche Konsistenzprüfungen notwendig, die u. a. die hier aufgeführten Datenkonstellationen ausschließen müssen. Zusammenfassend ergibt sich also folgendes Bild: ODX wurde so entworfen, dass es die für die Parametrierung von Testsystemen notwendigen Anforderungen erfüllt (Bild 6 links). Die Parametrierung von Softwarekomponenten setzt jedoch voraus, dass die möglichen Freiheitsgrade auf das für eine Spezifikation geforderte Maß beschränkt werden (Bild 6 rechts). Dies kann durch Autorenrichtlinien erreicht werden. AUTOSAR mit ODX ODX und AUTOSAR sind etablierte Standards für die Entwicklung von Steuergerätesoftware bzw. für die Beschreibung der Diagnosedaten eines Fahrzeugs oder einzelner Steuergeräte. Es ist deshalb naheliegend zu untersuchen, wie verfügbare ODX-Daten gewinnbringend in die Entwik4/12

klung des Diagnoseanteils der Steuergerätesoftware (DCM/DEM) integrierbar sind. Die AUTOSAR-Entwicklung ist stark funktionsorientiert (siehe Teil 1 dieses Beitrags in Heft 10/2011, S. 20-23). In frühen Phasen der Entwicklung entstehen deshalb in erster Linie Funktionsbeschreibungen und -definitionen. ODX-FD schlägt die Brücke zwischen den Funktionen und den Diagnosemöglichkeiten eines Steuergerätes, ist aber in erster Linie für den Tester relevant. ODX-FD-Daten können deshalb aus AUTOSAR-Funktionen abgeleitet werden, auch wenn die konkrete Diagnosebeschreibung in Form von ODX-D-Daten noch nicht vorliegt (Bild 7, Schritt 1). Die so entstehende ODX-FD-Beschreibung gibt die Struktur und Gruppierung der AUTOSAR-Funktionen in ODX wieder. Die Verlinkung in den ODX-D-Container (d. h., das Mapping zwischen Funktionen und den konkreten Diagnosedaten) ist zu dem Zeitpunkt noch nicht möglich. Oben wurde gezeigt, dass die für die Konfiguration von Softwarekomponenten benötigte Informationen in ODX in erster Linie in ODX-D zu finden ist. In AUTOSAR wird die Steuergerätekonfiguration in der ECU Configuration Description beschrieben, aus der auch die Steuergerätesoftware generiert wird. Es liegt also nahe, ODX-D-Daten (sofern sie vorhanden sind) in die ECU Configuration Description zu übertragen und im AUTOSAR-Prozess weiter zu verwenden. Ob und in welchem Umfang ODX-D Daten vorhanden sind hängt vom Zusammenarbeitsmodell zwischen Fahrzeughersteller und Zulieferer ab. Ein Extremfall ist die Neuentwicklung eines Steuergerätes „auf der grünen Wiese“ (Bild 7, Schritt 2a). In diesem Fall wird ein Großteil der Diagnosemöglichkeiten vom OEM vorgegeben. Im anderen Extremfall wird ein bereits verfügbares Steuergerät in ein neues Fahrzeug integriert (Bild 4, Schritt 2b). Änderungen an der Diagnose sind dann nur mit großem Aufwand möglich. Die Diagnose ist somit stark vom Steuergerät und weniger von den Funktionen geprägt. In der Regel verfährt man nicht ausschließlich nach dem einen oder anderen Extrem, sondern kombiniert die Ansätze. Typischerweise werden zwischen Fahrzeughersteller und Zulieferer die Diagnose-Anforderungen aus Sicht der Funktion und aus Sicht des Steuergerätes (und seiner Peripherie) spezifiziert, sodass schließlich ODX-D-Daten für das Steuergerät entstehen. Im nächsten Schritt können ODX-FD-Daten mit ODX-D-

ENGINEERING-TOOLS

l

AUTOMOTIVE

7- 8. 2 0 0 9

l 19

Daten verknüpft werden (Bild 7, Schritt 3). Aus den ODX-D-Daten lässt sich die ECU Configuration Description generieren, die dann die Grundlage für die Erstellung der Softwarekomponenten bildet (Bild 7, Schritte 4 und 5). ODX-FD- und ODX-DDaten bilden außerdem auch die Grundlage für die Erstellung des Testerlaufzeitformats (Bild 7, Schritt 7). Die Verwendung von ODX als Grundlage für beide Seiten des Prozesses (Softwarekomponenten und Testerparametrierung) stellt sicher, dass Tester und Steuergerät auch in unterschiedlichen Entwicklungsversionen jeweils exakt zu einander passen. Es stellt sich die Frage, ob auch der umgekehrte Weg – Generieren von ODX-D aus der ECU Configuration Description – möglich ist. Die Antwort hängt unter anderem Bild 7: Kombination von ODX und AUTOSAR. © automotive von der verwendeten AUTOSAR-Version ab: Das AUTOSAR-Format für Versionen einschließlich 3.x ist nicht mächwww.odx-solutions.de. (oe) tig genug, um die für die Testerparametrierung wesentlichen Informationen zu beschreiben, z. B. fehlen die Hinweis: Teil 1 „Diagnose mit AUTOSAR“ ist im vorigen Umrechnungsinformationen für Datenobjekte. AUTOSAR Heft (Hanser Automotive 10/2011, S. 20-23) erschienen. 4 ist mächtiger und kann auch diese UmrechnungsinforDas Literaturverzeichnis zu diesem Beitrag finden Sie mationen enthalten. Allerdings ist gerade diese Informaebenfalls am Ende des Teil 1. tion üblicherweise nicht relevant für den Anwendungsfall Dr. Klaus Beiter leitet ein Entwicklungsteam der Steuergeräteparametrierung, sodass fraglich ist, ob in der Produktlinie Kfz-Diagnose bei der Firma diese Information in der Praxis tatsächlich hier beschrieben Vector Informatik GmbH in Stuttgart. Er ist Mitglied in der ASAM/ISO ODX-Arbeitswird. gruppe. Zudem steht der hier skizzierte funktionsgetriebene Ansatz der fahrzeugübergreifenden Harmonisierung der Diagnoseumfänge entgegen. Es bleibt also abzuwarten, in welche Richtung sich die künftigen Diagnose-Datenflüsse Dipl-Ing. (BA) Christoph Rätz leitet die bewegen werden. Erfahrungsgemäß setzen sich die diskuProduktlinie Kfz-Diagnose bei der Firma tierten Ansätze nicht in Reinform durchsetzen, sondern Vector Informatik GmbH in Stuttgart. werden der konkreten Entwicklungssituation angepasst und kommen kombiniert zum Einsatz. Integration Die Integration verschiedener Teilprozesse mit ihren unterschiedlichen Schnittstellen (Interfaces, Datenformate, …) ist eine der größten Herausforderungen bei der Einführung neuer Technologien wie AUTOSAR und ODX. Erfahrungsgemäß ist es am effizientesten, bei der Einführung auf praxisbewährte Lösungen zu setzen. Vector bietet umfassende AUTOSAR- und ODX-Werkzeugketten aus einem Guss. Mehr Informationen unter www.autosar-solutions.de und

Dipl Ing. (FH) Oliver Garnatz ist bei Vector als Produkt-Manager im Bereich EmbeddedSoftware-Komponenten tätig. Er ist Mitglied in der ISO im Bereich Kfz-Diagnose sowie in AUTOSAR.

@

Vector Informatik www.vector.com

4/13

Messen/Testen/Tools

Alle Bilder: Vector Informatik

Messen/Testen/Tools

Diagnosewerkzeuge für WWH-OBD Umsetzung der neuen Anforderungen für OEMs und Zulieferer Alle neu zugelassenen schweren Nutzfahrzeuge müssen ab dem Jahr 2014 die Vorgaben der Euro-VI-Norm verbindlich einhalten. Dabei sind die Fahrzeughersteller unter anderem verpflichtet, ein WWH-OBD-fähiges Diagnosesystem zu implementieren. Noch früher treten die Richtlinien für neu entwickelte Fahrzeuge in Kraft; hier ist der Stichtag bereits der 1.1.2013. Hilfe beim Testen der Implementierung durch WWH-OBD-fähige Diagnosewerkzeuge ist somit sehr willkommen. Autor: Helmut Frank

D

ie On-Board-Diagnose (OBD) im Fahrzeug ist eine kontinuierliche Selbstüberwachung des Systems. Dabei zeigen Kontrollleuchten unmittelbar die Ergebnisse dieser Selbstüberwachung an. Diese Ergebnisse werden zudem gespeichert und zu diskreten Zeitpunkten, beispielsweise während einer Wartung oder im Rahmen einer Reparatur, mit einem externen Testgerät ausgelesen. Nachdem einige Automobilhersteller bereits in den 1980er Jahren damit begonnen hatten, solche Konzepte proprietär in Ihren Fahrzeugen zu implementieren, damals noch fast ausschließlich in den elektronischen Motormanagementsystemen, hat zuerst die Umweltschutzbehörde CARB im US-Bundesstaat Kalifornien Zulassungsvoraussetzungen für neue Fahrzeugtypen formuliert, die neben der Einhaltung bestimmter Emissionsgrenzwerte auch einen definierten Umfang an Selbstüberwachungsfunktionen der abgasrelevanten Systeme eines Fahrzeuges vorsahen. Auf der ursprünglichen OBD-Version aus 1988 aufbauend wurden in den folgenden Jahren in den übrigen US-Bundesstaaten, aber auch in Europa und Japan, gesetzliche OBD-Umfänge definiert. Diese regional gültigen OBD-Versionen bauen zwar alle auf derselben Basis auf und sind teilweise sogar inhaltlich identisch, entstanden aber parallel zur herstellerspezifischen Diagnose und verwenden dazu gänzlich verschiedene Methoden, Services und Parameter.

Weltweite Harmonisierung der Fahrzeugdiagnose Bei der OEM-spezifischen Diagnose ist in den letzten Jahrzehnten eine fortschreitende Standardisierung bezüglich Transport- und Diagnoseprotokoll zu beobachten. Mittlerweile haben sich auch eine einheitliche Diagnoseschnittstelle zu externen Testgeräten (die 16-polige OBD-Steckdose) und der CAN-Bus als Übertragungsmedium weitgehend durchgesetzt. Diese Konvergenz hin zu UDSonCAN (Unified Diagnostic Services on CAN) legt es nahe, nun die Diagnoseprotokolle der gesetzlich geforderten und der herstellerspezifischen Diagnoseinhalte zusammen zu führen, was die World Wide Harmonized OnBoard-Diagnostics (WWH-OBD) leisten soll. Die Standardisierung findet auf Betreiben der Vereinten Nationen in Form einer Global Technical Regulation (GTR) statt und wird unter anderem in der ISO-Norm 27145 spezifiziert. Die neue Spezifikation sieht aber auch neue und erweiterte Funktionen vor. So erfolgt eine Einteilung der Fehlercodes nach Schweregrad eines Ausfalls in sogenannte Severity-Klassen A, B1, B2 und C – je nachdem, wie gravierend ihre Auswirkung auf die Abgasqualität ist. Auch wechseln die Fehler der zweithöchsten Klasse B1 in die höchste Klasse A, falls sie nicht in einem definierten und vom System überwachten Zeitrahmen, beispielsweise 200 Betriebsstunden, behoben wurden. Damit abgasrelevante Fehl-

Bild 1: Vorteil für den Anwender beim Diagnosezugriff: Intelligente Tools erkennen automatisch welcher Standard verwendet wird, stellen sich automatisch darauf ein und liefern das Ergebnis.

funktionen und auch deren Einfluss auf das Abgas für den Fahrer aber auch für Behörden oder Prüforganisationen unmittelbar erkennbar ist, wird die Kontrollleuchte „Malfunction Indicator Lamp (MIL)“ von den Fehlern der verschiedenen Severity-Klassen in unterschiedlicher Weise angesteuert. Um auch künftige Anforderungen zu berücksichtigen und dem technischen Fortschritt in der Fahrzeugvernetzung gerecht zu werden, wird neben CAN auch das Internet-Protokoll (IP) als Transportmedium bei der Normung berücksichtigt. Somit wird also künftig auch UDSonIP zur Implementierung der WWH-OBD zulässig sein. In einigen führenden Industrienationen wird die Implementierung der WWH-OBD bereits kurzfristig als Zulassungsvoraussetzung für neu entwickelte Typen schwerer Nutzfahrzeuge gefordert. Ab Anfang 2014 müssen beispielsweise in der EU alle neu zugelassenen schweren Nutzfahrzeuge die Euro-VI-Standards einhalten und damit über WWH-OBD diagnosefähig sein. Neu entwickelte Fahrzeugtypen müssen die Standards bereits zum 01.01.2013 erfüllen. Die Ausbreitung des Gültigkeitsbereiches der WWH-OBD auf Pkw, Transporter, selbstfahrende Arbeitsmaschinen etc. ist beabsichtigt. Ebenfalls diskutiert wird die Aufhebung der Beschränkung auf abgasrelevante Systeme. Beispielsweise könnten sicherheitsrelevante Systeme wie Bremse, Lenkung, Rückhaltesysteme und Licht ebenfalls damit überwacht und im Rahmen von periodischen Prüfungen examiniert werden.

Die Grafik in Bild 1 verdeutlicht den Unterschied der OBDKommunikation nach bisherigem Standard und neuem WWHOBD-Standard. Dargestellt ist jeweils das Auslesen aktuell vorliegender, aber noch nicht bestätigter Diagnostic Trouble Codes (DTC), also der „pending DTC“. Das Fahrzeug übermittelt in beiden Fällen denselben Fehler „Engine Oil Temperature Sensor High“, P0198, an das Scan-Tool. Im Falle der WWH-OBD lassen sich jedoch zusätzliche Informationen wie beispielsweise der Schweregrad des Fehlers auf das Abgasverhalten (Severity) sowie dessen vollständige Statusinformation übertragen und darstellen. Betrachtet man die Byte-Inhalte der Requests und Responses, dann wird deutlich, dass deren Aufbau im Falle der WWH-OBD anders aussieht als bei der OBD-II: Zunächst fällt auf, dass die Länge der Fehlercodes in der WWH-OBD gemäß der Spezifikation drei Byte umfasst; bei OBD-II sind es zwei Byte. Allerdings erfolgt eine Weiterverwendung der ersten beiden Byte aus der SAE J2012 beziehungsweise ISO 15031-5. Die ältere OBD-Version liest die DTCs getrennt nach ihrem Status in unterschiedlichen OBD-Modes aus: ■ Service $03 — Request Emission-Related Diagnostic Trouble Codes für confirmed DTC, ■ Service $07 — Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle für pending DTC und ■ Service $0A — Request Emission-Related Diagnostic Trouble Codes with Permanent Status für permanent DTC). WWH-OBD verwendet hingegen den Protokollservice ReadDTCInformation [0x19] mit der Subfunktion reportNumberOfDTCByStatusMask [0x42] und ein Bitfeld in Byte 4 des Requests zum Einstellen des Status, den die zurück zu meldenden Fehlercodes haben sollen. Ein intelligentes Testsystem, wie beispielsweise Indigo von Vector, ist in der Lage, den der Prüfung zugrunde zu legenden Standard selbsttätig zu erkennen, die für den jeweiligen OBD Standard relevante Funktionen zur Verfügung zu stellen und dabei aber die protokollspezifischen Unterschiede für den Anwender transparent zu machen. Dieser kann sich somit bei seiner Arbeit auf die Inhalte konzentrieren. Bei Bedarf kann er aber auch in die Tiefen des Protokolls absteigen und die Rohdaten analysieren. Dies ist beispielsweise bei der Ermittlung von Fehlerursachen nützlich, wenn das Steuergerät nicht die erwartete Antwort auf einen OBD-Request liefert. (av) ■ Der Autor: Dipl.-Ing. Helmut Frank ist als Business Development Manager bei Vector Informatik für die Produktlinie Diagnose zuständig.

Intelligente WWH-OBD-fähige Werkzeuge Die Richtigkeit und Vollständigkeit der OBD-Funktionalität ist den Zulassungsbehörden vom Fahrzeughersteller in geeigneter Form nachzuweisen. Dabei erfolgt die Überprüfung im Rahmen der Homologation und setzt geeignete Prüfmittel zur Verifizierung voraus. Sowohl der Fahrzeughersteller als auch der Systemlieferant benötigt somit bereits im Vorfeld der Homologation, also schon während der Entwicklung beziehungsweise der Systemintegration, geeignete Diagnosewerkzeuge, um die OBD-Funktionen zu testen. Die gute Nachricht dabei ist, dass die im Rahmen einer WWHOBD zwischen Fahrzeug und externem Testgerät ausgetauschten Informationen weitgehend identisch mit denen bleiben, die bereits bei einer Diagnose nach OBD-II oder EOBD ausgetauscht werden. Hier sieht der neue Standard lediglich überschaubare Erweiterungen der Funktionalität vor. Ändern wird sich im Wesentlichen nur die Art und Weise, wie diese Inhalte transportiert werden.

Auf einen Blick Umstieg auf WWH-OBD Moderne leistungsfähige Diagnosewerkzeuge müssen die vollständige Unterstützung des neuen WWH-OBD-Standards bieten – und das sofort. Mit ihnen lassen sich auch die zügig näher rückenden Termine Anfang 2013 und Anfang 2014 gut meistern. Sie reihen sich nahtlos in vorhandene Werkzeugketten ein und machen Fahrzeugherstellern und Zulieferern den Umstieg auf WWH-OBD besonders einfach. Erfahrungsgemäß ist es dabei am effizientesten, auf praxisbewährte Lösungen zu setzen. Vector bietet dafür das einfach zu bedienende Diagnosetest-Tool Indigo, das schon jetzt den WWH-ODB-Standard unterstützt. Dies erleichtert den Umstieg auf WWH-OBD. infoDIREKT www.all-electronics.de

311AEL0412

Erschienen in Automobil Elektronik, 4/2012 4/14

18

Automobil ElEktronik 04/2012

www.automobil-elektronik.de

www.automobil-elektronik.de

Automobil ElEktronik 04/2012

19

4/15

4/16

4/17

CANdelaStudio – Effiziente Spezifikation der Diagnose­ anforderungen bei KTM Case Study KTM

Der Kunde

Die Vorteile

Die KTM-Sportmotorcycle AG mit Sitz in Mattighofen,

Ein einheitliches Diagnosedatenformat und „Frontloading“

Österreich produziert und entwickelt rennsporttaugliche

verschaffen den KTM­Entwicklern Zeit für zusätzliche Tests

Offroad- und Street-Motorräder. KTM ist als größter Motor-

und damit eine höhere Produktqualität.

radhersteller Europas führend im Offroad-Competition-Be-

KTM verringert mit CANdelaStudio den Aufwand während

reich. Die Travel Enduro 1190 Adventure ist im Modelljahr

der Diagnosespezifikationsphase erheblich. Diagnosefähige

2014 das sicherste Motorrad der Welt.

Steuergeräte sind frühzeitig vorhanden. Diagnosespezifikationen können einerseits zur automatisierten Erzeugung

Die Herausforderung

der Steuergeräte-Software oder zur Parametrierung der

Konsistente Erstellung, Verwaltung und Verteilung der Diag­

Diagnosetester herangezogen werden, andererseits stehen

nosedaten im gesamten Diagnose­Entwicklungsprozess.

sie auch zur Wiederverwendung in Neu- oder Weiterent-

Bei der Entwicklung der neuen 1190 Adventure, und ihren

wicklungen der Steuergeräte zur Verfügung.

bis zu neun Steuergeräten, soll eine Optimierung des Diag-

Das Ergebnis: Die gesamte Diagnoseentwicklung wird bei

nose-Entwicklungsprozesses durchgeführt werden. In frü-

den Steuergeräten der KTM 1190 Adventure schneller durch-

heren Entwicklungsprojekten wurde bei KTM die Diagnose

laufen als bei früheren Motorradmodellen.

in Textform spezifiziert. Die automatisierte Weiterverar-

Weitere Vorteile: > Bei KTM vorhandene Diagnosetester wie CANoe können

beitung der Spezifikation war dadurch nicht möglich. Vielmehr musste die Steuergeräte-Spezifikation intern bei KTM, aber auch bei den Steuergerätezulieferern jeweils mit

bereits zu einem frühen Zeitpunkt parametriert werden. > ODX-Daten zur Parametrierung der KTM-Produktions-

hohem Aufwand interpretiert und in Eingabedaten für die

und Servicetester werden auf Knopfdruck direkt aus

eingesetzten Diagnosetester konvertiert werden. Dadurch

CANdelaStudio generiert. Die KTM-Entwickler müssen

standen Diagnosetester in Entwicklung, Produktion und Service erst spät zur Verfügung.

nicht speziell in ODX geschult werden. > Die einfache Erstellung von Diagnoseanforderungen als

Die Lösung

PDF-Daten für „kleinere“ KTM-Zulieferer ist möglich. > Die Abstimmung der Diagnosespezifikation zwischen den

Der CANdela Ansatz – ein einheitliches Diagnosedaten­

Prozessbeteiligten (KTM und Zulieferer) ist einfacher.

format und die darauf aufbauende Tool­Kette. In der Diagnoseentwicklung der neuen 1190 Adventure kommt CANdelaStudio als zentraler Baustein des CANdela-Ansatzes zum Einsatz. KTM spezifiziert damit Diagnosedaten in dem maschinen-verarbeitbaren cdd-Format (XML). Diese stehen somit frühzeitig als Eingangsdaten für viele Werkzeuge entlang des Diagnoseentwicklungsprozesses zur Verfügung. Gleichzeitig können auch nach wie vor textbasierte Spezifikationen aus der CANdela-Beschreibung erzeugt und bei Bedarf an die KTM-Zulieferer weiterge-

V2.0 | 2014-07

geben werden.

4/18

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

4/19

4/20

4/21

Automatische Validierung der Diagnose-Services beim Opel Insignia Case Study GM Europe

Der Kunde

Die Vorteile

General Motors ist ein global operierender Automobilkon-

Deutlicher Effizienzgewinn bei der Validierung der Diagnose

zern, zu dem auch Opel gehört. Das Internationale Ent-

Die Ingenieure bei Opel haben den Testaufwand beim

wicklungszentrum von Opel befindet sich in Rüsselsheim.

neuen Insignia mit denen beim Corsa (manueller bzw.

Dort wurde auch das neue Erfolgsmodell und „Auto des

teilautomatisierter Test) systematisch verglichen:

Jahres 2009“ Opel Insignia entwickelt.

In frühen Entwicklungsphasen, wenn noch Fehler gefunden werden, ergibt sich eine Reduzierung des Testaufwandes

Die Herausforderung

um den Faktor 4. In späten Entwicklungsphasen, wenn der

Effizienzsteigerung bei der Validierung der Diagnose-Services

Test als Regressionstest abläuft, ergibt sich sogar eine

Der Opel Insignia hat deutlich mehr Steuergeräte als sein

Einsparung um den Faktor 20.

Vorgängermodell, der Testaufwand ist im Vergleich eindeutig

Dabei ist die Lösung kostengünstig: Es werden lediglich

höher. Eine weitreichende Automatisierung von Test und

Lizenzen von CANoe.DiVa benötigt. Bereits vorhandene

Validierung der Diagnose-Services verspricht ein erhebliches

Vector CAN-Kommunikationshardware kann weiter ver-

Einsparungspotential. Dabei sollen auch die Zulieferer in die

wendet werden.

Lage versetzt werden, bereits bei sich vor Ort entwicklungs-

Das Ergebnis hat überzeugt: Die Diagnose-Validierung aller

begleitend zu testen.

neuen Steuergeräte von GM erfolgt mit CANoe.DiVa – auch beim Zulieferer.

Die Lösung Ein Werkzeug zur automatisierten Erzeugung und Ausführung von Diagnosetests Das Werkzeug CANoe.DiVa automatisiert die Validierung der Diagnose-Services. Dabei ist CANoe.DiVa nicht auf einen

bestimmten

Fahrzeughersteller

zugeschnitten,

ermöglicht aber herstellerspezifische Anpassungen und Erweiterungen durch Konfiguration und/oder Plug-Ins. Auf Basis einer Steuergeräte-spezifischen Diagnosebeschreibung werden Testfälle und Testspezifikation generiert. In CANoe werden diese Testfälle ausgeführt, ein umfassender Testreport wird erzeugt. Bei der Analyse des Testreports wird der Anwender durch unterschiedliche Sichten und Filter optimal unterstützt. In der GM-Diagnose-Spezifikation sind 350 Testabläufe definiert. Rund ein Drittel dieser Testabläufe sind „GutfallTests“, zwei Drittel sind „Schlechtfall“ Tests.

[Bild]: Vergleich Testaufwand pro Steuergerät mit manu-

In enger Zusammenarbeit mit Opel wurden diese GM-spe-

eller Validierung beim Opel Corsa, zu automatisierter

zifischen Tests in das Produkt CANoe.DiVa integriert. Rund

Validierung der Diagnoseservices beim Opel Insignia

80% der Testabläufe sind damit vollautomatisiert ausV2.0 | 2009-06

führbar, rund 15% erfordern eine Benutzerinteraktion.

4/22

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

4/23

ENT WICKLUNG DIAGNO SE

© Claas, Vector Informatik

AUFGABENSTELLUNG

AUTOREN

Datengetriebene automatisierte Diagnose-Applikations-Validierung

Seit vielen Jahren wird die Diagnoseprotokoll-Implementierung eines Steuergeräts über automatisch generierte Tests validiert. Diese basieren auf Diagnosebeschreibungs-Dateien des Fahr-

Dipl.-Ing. (FH) Nils Niedermark ist als Entwicklungsingenieur im Bereich Entwicklung Elektronik Integration bei der Claas Selbst fahrende Erntemaschinen GmbH in Harsewinkel.

Friedemann Löw, B. Sc. ist in der Produktlinie Kfz-Diagnose bei der Vector Informatik GmbH in Stuttgart als SoftwareEntwickler für CANoe.DiVa tätig.

zeugherstellers. Die entsprechende Schnittstelle eines Steuergeräts kann so nachweislich effizient getestet werden und führt zu einer Verbesserung der Produktqualität. Je nach Vollständigkeit der Diagnosebeschreibung ist darüber hinaus auch die automatisierte inhaltliche Validierung von Diagnoseparametern und Fehlercodes möglich, wie die Zusammenarbeit von Claas und Vector Informatik zeigt. 44

4/24

Dipl.-Inf. Simon Müller ist Produktmanager in der Produktlinie Kfz-Diagnose bei der Vector Informatik GmbH in Stuttgart.

Der Landmaschinenkonzern Claas beschreibt in seinen Diagnosedaten die Beziehung zwischen Diagnoseparametern und den Steuergeräte Ein- und Ausgängen. Auch die Beschreibung von Fehlersetzkriterien wird für Neuimplementierungen formal dokumentiert. In der Vergangenheit wurden diese Informationen zur Durchführung von manuellen Tests verwendet oder Testingenieure implementierten spezielle Testfälle. Eine breite Testabdeckung konnte jedoch nicht erreicht werden. In Zusammenarbeit mit der Vector Informatik werden diese Verbindungsinformationen automatisiert mit der vorhandenen Netzwerk-(K-Matrix) und Hardwarebeschreibung verknüpft. Basierend auf bereits verfügbaren Spezifikationsdaten wie CDD (CANdela Diagnostic Data) oder ODX (Open Diagnostic Data Exchange) werden vollautomatisiert Diagnoseapplikationstests generiert und in einer Testumgebung ausgeführt. Durch automatisierte Stimulation der Steuergeräteumgebung wird das inhaltlich korrekte Verhalten der Diagnose-Implementierung getestet. Dazu werden zum Beispiel Signale in der Bussimulation modifiziert oder gezielt Hardware-I/Os angesteuert. So ist es möglich, das korrekte Setzen von Diagnoseparametern zu prüfen oder Fehlerzustände zu erzeugen und die richtige Ablage zu testen. AUTOMATISIERTE TESTGENERIERUNG

Um eine automatisierte Testgenerierung und Testdurchführung von Applikationstests zu erreichen, müssen Diagnoseparameter und Steuergeräte-I/Os in Verbindung gebracht werden. Als Quelle dafür dienen neben den Diagnosedaten (ODX, CDD) auch Spezifikationsdaten mit nur mittelbarem Diagnosebezug. Das sind beispielsweise Netzwerkbeschreibungen (dbc, arxml) oder Umgebungskonfigurationen wie die Interface-Beschreibung einer HiL-Konfiguration. Mit diesen Systeminformationen können in einer Testumgebung die Ein- und Ausgänge des Steuergeräts stimuliert und gemessen werden. Üblicherweise sind die Abhängigkeiten zwischen Diagnose und Steuergeräteumgebung heute in den Diagnosedaten nicht formal sondern - falls überhaupt 06I2015

10. Jahrgang

vorhanden - nur natürlichsprachlich beschrieben. Dadurch ist die automatisierte Weiterverarbeitung im Allgemeinen nicht möglich. Heuristiken können hier Abhilfe schaffen und zumindest eine teilweise Nutzung zur Testautomatisierung ermöglichen. Liegen zusätzlich Fahrzeughersteller-spezifische Detailkenntnisse über Art und Umfang der Steuergeräte-I/O-Beschreibung vor, so lassen sich daraus Tests der Diagnoseapplikation ableiteten. Insbesondere sind dadurch automatisierte Diagnoseparameter- und Fehlerspeichertests möglich. FEHLERSPEICHERTESTS

Den Diagnosedaten entnimmt man die Struktur und die formalen Inhalte der Fehlerspeicherdaten: beispielsweise den Aufbau der Fehlerumgebungsdaten aus DIDs (Data Identifiers) oder die Setzbedingungen für DTCs (Diagnostic Trouble Codes). Letztere liegen jedoch meist in einer nicht-formalen Beschreibung vor. Wenn es gelingt, die Diagnosebeschreibung in Beziehung zur Steuergeräteperipherie zu bringen, kann geprüft werden, ob ein DTC unter den richtigen Bedingungen korrekt im Fehlerspeicher abgelegt wird. Darüber hinaus können die DTC-Statusübergänge und das korrekte Löschen von DTCs validiert werden. Für jeden DTC muss dafür die jeweilige Setzbedingung bekannt sein. Diese besteht mindestens aus: – I/O-Typ (Ein- oder Ausgang, Netzwerk oder Sensor/Aktor) – I/O-Bezeichnung (Botschaftsname, Kanalname) – Fehlerbild (zum Beispiel Kurzschluss nach Masse). Das Fehlerbild kann oft direkt aus dem standardisierten Failure Type Byte (FTB) des DTCs abgeleitet werden (SAE J2012). Je nach Fehlerbild werden zusätzlich Schwellwerte, Setzzeiten und Informationen zur Fehlerüberwachung benötigt (Monitor). DIAGNOSEPARAMETERTESTS

Analog zu den Fehlerspeichertests wird auch für Tests der Diagnoseparameter die Beziehung zwischen Diagnoseparametern und den Steuergeräte-Pins benötigt. Das Validieren eines Diagnosewertes kann durch Vergleich mit – einem Messwert eines Steuergeräte-Pins

– einem Bus-Signal – einem CCP/XCP-Signal. erfolgen. Neben I/O-Typ und Bezeichner sind auch Umrechnungen, wie zum Beispiel Widerstand am Sensor in Temperatur im Diagnoseparameter nötig, um vergleichen zu können. Auch die Aktualisierungsfrequenz am Diagnoseparameter oder am Steuergeräteausgang ist zu berücksichtigen. Weiterhin sind Testwerte für die I/O-Stimulation nötig, da diese selten in der Diagnosebeschreibung dokumentiert sind und geeignete Werte sich in der Regel nicht aus den Spezifikationsdaten ableiteten lassen. Sowohl für Fehlerspeicher- als auch für Parametertests kann es Vorbedingungen geben, damit eine zu testende Funktion verfügbar ist. So muss beispielsweise für das Schleifen der Messer eines Feldhäckslers der Hauptantrieb eingeschaltet sein. Diese Abhängigkeiten müssen bei der Testausführung bekannt sein und berücksichtigt werden. ZIEL UND UMSETZUNG BEI CLA AS

Bei Claas sind viele der für Applikationstests erforderlichen Daten formal beschrieben. Ziel ist es daher auf Basis dieser Informationen die Testerstellung und -ausführung zu automatisieren. Um dies zu erreichen setzt Claas das Tool CANoe.DiVa von Vector Informatik ein. Die in der Diagnosebeschreibung (CDD) und anderen Quellen vorhandenen I/OInformationen werden in CANoe.DiVa importiert um einen Testgenerator zu parametrisieren. Anschließend werden die generierten Applikationstests automatisiert in der bereits für das zu testende Steuergerät vorhandenen CANoeTestumgebung ausgeführt, BILD 1. Alle für die Applikationstests relevanten Daten pflegt Claas in einer Entwicklungsdatenbank. Da sie auch in die Diagnosebeschreibungsdatei importiert werden, reicht diese in der Regel zur Generierung der Parametertests aus. Nur für I/Os, die im Diagnoseparameter andere Einheiten verwenden als am Steuergeräte-Pin, werden für den Test zusätzliche Umrechnungsinformationen benötigt. Diese werden in Form eines CANoe Mappings beigesteuert, welches Signalwerte über eine Umrechnungsvorschrift auf CANoeSystemvariablen abbildet. Mit diesen Daten lassen sich drei verschiedene Parametertests automatisiert parametrisieren und generieren:

45

4/25

ENT WICKLUNG DIAGNO SE

Löschens des Fehlerspeichers in verschiedenen Sicherheitslevels rundet die Fehlerspeichertests ab. Zum Messen und Stimulieren von Spannungen und Strömen an den Steuergeräte-Pins ist bei Claas ein HiL-System von Vector Informatik im Einsatz – das VT-System, BILD 2. Um die Daten der Diagnosebeschreibung und der Entwicklungsdatenbank für das automatisierte Ansteuern des VT-Systems verwenden zu können, wurden Namenskonventionen für die VT-System-Konfiguration definiert. CLA AS ERHÖHT DIE TESTABDECKUNG BILD 1 Systemarchitektur: Automatisierte Diagnose­ Applikationstests bei Claas (© Vector Informatik)

– Eingangstests: Die Testumgebung stimuliert einen Sensor-Pin des Steuergeräts. Der zugehörige Diagnoseparameter wird ausgelesen und mit dem Wert am Pin verglichen.

BILD 2 Testaufbau bei Claas zum Messen und Stimulieren von Spannungen an Steuer­ geräte­Pins mit dem VT­System von Vector (© Claas)

46

– Ausgangstests: Ein Diagnosedienst (I/O Control) schreibt einen neuen Wert in das Steuergerät, der die Ansteuerung eines Aktors bewirkt. Anschließend wird der Wert am Ausgang gemessen und mit dem Wert des geschriebenen Diagnoseparameters verglichen. – Passive Tests: Einige Signale können per Diagnosedienst nicht angesteuert sondern nur ausgelesen werden. Die Ansteuerung erfolgt an der Diagnoseschicht vorbei alleine in der Steuergeräteapplikation. In diesem Fall kann ein Test generiert werden, der den anliegenden Wert per Diagnosedienst liest und mit dem Wert am Steuergeräteeingang oder -ausgang vergleicht. Im Gegensatz zu den Parameterdaten sind die für Fehlerspeichertests benötigten Daten bei Claas nicht vollständig in der Diagnosebeschreibung vorhanden. Sie werden daher aus der Entwicklungsdatenbank als Excel-Datei exportiert und zur Testparametrisierung eingelesen. Im daraus abgeleiteten Test wird ein Steuergeräte-I/O so stimuliert, dass es zu einer Fehlersituation kommt. Anschließend wird die richtige Ablage des DTCs im Fehlerspeicher verifiziert. Durch Beheben der Fehlersituation, Einbau von Wartezeiten und wiederholtes Setzen des Fehlerzustandes können zusätzlich die DTC-Statusübergänge und die zum Fehler abgelegten DTC-Umgebungsdaten verifiziert werden. Das Überprüfen des

Diagnosefähige Steuergeräte befinden sich bei Claas nicht nur in Mähdreschern und Traktoren, sondern zum Beispiel auch in Mähwerken und Ballenpressen. In den größten Claas-Maschinen sind dabei je nach Ausstattung bis zu 40 Steuergeräte verbaut. Für alle diese Baureihen müssen Applikationstests durchgeführt werden. So wird sichergestellt, dass die Steuergeräte per Claas Diagnose System (CDS) bedient werden können. Das größte von Claas verbaute Steuergerät besitzt mehr als 75 I/Os, mit denen je nach Maschinenausstattung bis zu 15 verschiedene erlebbare Maschinenfunktionen realisiert sind. Zu diesen I/Os gehören mehr als 200 DTCs, die im Test geprüft werden müssen. Durch den Ausbau der automatisierten Erstellung und Durchführung von Applikationstests reduziert sich der Aufwand zur Verifikation der Steuergeräte erheblich. Die herstellerspezifische Erweiterung des Test-Tools erlaubt bei Claas eine Erhöhung der Testabdeckung durch automatisierte Tests für Fehlerspeicher und Diagnoseparameter von vorher 55 auf nun 95 %. Claas hat sich zum Ziel gesetzt, mittelfristig alle Steuergeräte automatisierten Applikationstests mit CANoe.DiVa zu unterziehen. Der Aufwand für Diagnosetests an Hardware-I/Os ist trotz automatischer Testgenerierung und Testdurchführung hoch. Insbesondere der Aufbau der Testumgebung ist zeitaufwendig. Je nach Steuergerät kann die Ansteuerung einzelner I/Os durchaus komplex sein, sodass ein individueller Zugriff implementiert werden muss. Im Vergleich dazu ist das Validieren von Diagnoseparameter gegen Netzwerksignale nur mit geringem initialen Aufwand verbunden:

Die benötigte Infrastruktur kann über das Generieren einer Restbussimulation aus der K-Matrix automatisch erzeugt und vom Test verwendet werden. ZUSAMMENFASSUNG UND AUSBLICK

Das automatisierte Generieren und Ausführen von Tests, wie sie bei Claas mit dem Werkzeug CANoe.DiVa von Vector durchgeführt werden, bieten ein großes Potenzial die Testtiefe zu erhöhen und gleichzeitig den Testaufwand zu reduzieren. Für eine vollständige Testabdeckung durch CANoe.DiVa müssen manche Funktionalitäten auch bei Claas zurzeit noch manuell konfiguriert werden, da noch keine formale Beschreibung verfügbar ist, die für eine automatisierte Parametrisierung verwendet werden kann. So gibt es beispielsweise I/Os, deren Ansteuerung für Parametertests sehr komplex ist: Hier sind teilweise Vorbedingungen in der Steuergeräteumgebung notwendig, bevor es möglich ist, einen I/O wie beabsichtigt zu verwenden. Analog dazu gibt

es auch für einige Fehlerspeichertests Vorbedingungen, die hergestellt werden müssen, bevor ein Fehlermonitor aktiv ist und folglich ein DTC erkannt und im Fehlerspeicher abgelegt werden kann. Die aktuell umgesetzten Tests lassen sich noch um weitere Details ergänzen: zum Beispiel Prüfen von Selbstheilungsfunktionalität, Priorisieren der Fehlerspeicherablage oder auch das Testen unterschiedlicher Fehlersituationen, die zum selben DTC führen. An dieser Stelle wird sich die Testlösung kontinuierlich weiterentwickeln. Auch in der Automobilindustrie ist ein Trend zum Zusammenführen von Entwicklungsdaten für elektrische und elektronische Architekturen zu beobachten. Datenbanken und Werkzeuge verfügen damit direkt oder indirekt über Informationen, um Elektrik, Elektronik und (Diagnose-) Software im Verbund automatisiert zu testen. Die weitere Formalisierung der Daten ist zunächst mit höherem Aufwand verbunden. Vor allem für automatisierte Tests ergibt sich durch die formale

Beschreibung aber ein lohnenswert hohes Optimierungspotenzial. Sowohl die voranschreitende Standardisierung (etwa Autosar) als auch die Integration und Interoperabilität von Entwicklungswerkzeugen werden vielfältige neue Ansätze auf dem Feld der automatisierten Testbarkeit ermöglichen. CANoe.DiVa folgt dieser Entwicklung und wird von diesen neuen Möglichkeiten Gebrauch machen, um weitere automatisierte Tests der Diagnoseapplikation abzuleiten. Die Möglichkeiten für automatisierte, datengetriebene Tests sind noch lange nicht ausgeschöpft. Es bleibt spannend. LITERATURHINWEIS [1] Peti, P.; Timmerberg, A.; Pfeffer, T.; Müller, S.; Rätz, C.: Automatische Validierung der Diagnoseservices. In: ATZelektronik 3 (2008), Nr. 6, S. 58-64

DOWNLOAD DES BEITRAGS

www.springerprofessional.de/ATZelektronik

READ THE ENGLISH E-MAGAZINE

order your test issue now: [email protected]

Skalierbare Automotive-Netzwerk-Lösungen Kosteneffizient • Echtzeit • Flexibel

Microchip bietet seit über zehn Jahren robuste, automotive-qualifizierte CAN-, LIN-, Ethernet-, MOST®-Technik und USB-Lösungen für Hersteller im Bereich Automobilelektronik. Unsere MOST-Technologie und USB-Lösungen sind die De-facto-Standards für In-Vehicle Infotainment und Consumerelektronik-Datenanbindung weltweit. Falls Ihr Automotive-Design die Übertragung von Audio-, Video-, Steuerungs- oder Ethernet-Paketdaten erfordert, bieten wir Lösungen, die über UTP-, Koax- und Glasfaser-PHYs mit garantiert niedriger Latenz zuverlässig arbeiten. Software-Stacks stehen über Microchip bereit, genauso wie Support von Drittanbietern. Damit können Sie sich voll und ganz auf die Entwicklung Ihrer Anwendungssoftware konzentrieren.

Anwendungsbeispiele Karosseriesteuerung LTE/3G-Anbindung LED-Innenraumbeleuchtung

Rückfahrkamera HMI LED-Außenleuchten

Surround-View-Kameras Infotainment Head Unit Smart-Sensoren

www.microchip.com/automotive 47 Der Name Microchip und das Logo, das Microchip-Logo und MPLAB sind eingetragene Warenzeichen der Microchip Technology Incorporated in den USA und in anderen Ländern. Alle anderen hier erwähnten Marken sind im Besitz der 06I2015

10. Jahrgang

jeweiligen Eigentümer. © 2015 Microchip Technology Inc. Alle Rechte vorbehalten. MEC2023Ger/07.15

4/26

4/27

ENTWICKLUNGSWERKZEUGE

Bilder: Vector Informatik

ENTWICKLUNGSWERKZEUGE

Trends bei der Steuergeräte-Applikation Die Entwicklungen und Herausforderungen der nächsten fünf bis zehn Jahre im Bereich Messen und Kalibrieren von Steuergeräten sind bestimmt von globalen Trends und bringen einige Veränderungen mit sich. Vielfach stoßen etabumhin, neue Wege zu beschreiten. Datenbasierte Applikationsmethoden, „intelligente“ Datenverwaltungen mit nahezu transparentem Datenaustausch und die flexible Integration von Expertenwissen via Apps werden unter anderem die Arbeit des Applikationsingenieurs ergänzen.

Z

u den Schlüsseltrends, die die Automobilindustrie in den nächsten Jahren bewegen werden, gehören nach Ansicht zahlreicher Geschäftsführer der Branche [1] der Umgang mit neu-

5/0

HANSER automotive 11-12 / 2015

en Märkten, die Standardisierung von Fahrzeugplattformen und Modulen, Fahrerassistenzsysteme sowie eine weitere Optimierung der Verbrennungsmaschine – um nur die Wichtigsten zu

nennen. Daraus leiten sich für die Unternehmen und deren Entwicklungsabteilungen neuartige Anforderungen ab, sodass sich zahlreiche Arbeitsmethoden grundlegend ändern müssen. © Carl Hanser Verlag, München

© Fotolia.com/vege, Bearbeitung: Vector Informatik GmbH

lierte Arbeitsmethoden an ihre Grenzen, und die Unternehmen kommen nicht

Bild 1: Die Steuergeräte-Applikation verlagert sich immer mehr vom Fahrzeug hin zu Prüfständen und HiL-Systemen. Um Kosten für teure Prototypen und Versuchsfahrzeuge zu reduzieren, werden mehr Applikationsaufgaben und Optimierungen mit Simulationen und Modellen im Labor durchgeführt.

Während die neuen Märkte zum Beispiel eine viel engere Zusammenarbeit mit Kunden, Geschäftspartnern und Dienstleistern auf internationaler Ebene erfordern, dürfte mehr Standardisierung zu einer höheren Zahl von Varianten führen. Die Weiterentwicklung von Verbrennungsmaschinen wiederum erhöht die ohnehin hohe Komplexität im Antriebsstrang nochmals weiter. Schon heute erfordert ein moderner Dieselantrieb mit Abgasreinigung die Applikation von über 60.000 Parametern, bei 4, 8, 10 oder 20 Varianten. Auch in weiteren Elektronikdomänen, wie Chassis oder Body sowie bei Assistenzsystemen, nimmt die Komplexität und Konfigurierbarkeit der Steuergeräte weiter zu. Sind bei Chassis-Systemen vielleicht nur 5.000 Parameter zu verwalten, so haben es die Ingenieure dafür mit 80 bis 100 Produktvarianten zu tun. Betrachtet man Ultraschallsensoren als typische Komponenten von Assistenzsystemen, so gibt es dort www.hanser-automotive.de

nur wenige Applikationswerte; dafür werden die Sensoren jedoch in 1.000 Fahrzeugvarianten verbaut. Entwicklung, Test und Validierung von Fahrerassistenzsystemen ist effizient nur durch eine direkte Integration mit dem bestehenden Mess- und Applikationswerkzeug möglich. Neben den hohen Datenraten erfordert die Sensordatenfusion eine Erweiterung der bisherigen signalorientierten Konzepte hin zur objektorientierten Darstellung und Bearbeitung der Informationen.

Von der virtuellen Applikation bis zum automatisch generierten Bedatungssatz Zu den weiteren Trends zählen das Kalibrieren in virtuellen Umgebungen, das automatische Generieren von Wissen aus bestehenden Datenbeständen sowie die Migration von Web-Technologien hinein in industrielle Arbeitsabläufe.

Während in den letzten Jahren die Applikation weg vom Fahrzeug und hin zu Prüfständen und HiL-Systemen verlagert wurde, geht es zukünftig darum, mit Simulationen und Modellen mehr Applikationsaufgaben und Optimierungen im Labor durchzuführen (Bild 1). So sparen sich die Unternehmen teure Prototypen und Versuchsfahrzeuge. Es geht nicht mehr allein darum, Signale zu messen beziehungsweise Daten zu sammeln und zu verwalten, sondern auch darum, automatisch Ergebnisse zu generieren. Die bestehende Datenbasis dient als Grundlage zum Erstellen neuer Bedatungen und Varianten über entsprechende Rechenalgorithmen.

Cloud-Technologien wertschöpfend und sicher integrieren Social Media, Internet of Things und Web 3.0 zeigen uns, wie allumfassend und einfach sich Datenaustausch, KonHANSER automotive 9 / 2014

5/1

ENTWICKLUNGSWERKZEUGE

ENTWICKLUNGSWERKZEUGE

Bild 2: Im Rahmen der modellbasierten Software-Ent-

Bild 3: Ausgestattet mit

wicklung werden

einer einheitlichen Benut-

die Funktionen von

zeroberfläche unterstützt

Anwendungen in

die „Calibrators Work-

einem iterativen

bench“ Applikateure mit

Prozess überprüft.

einem modularen Ange-

Eine komfortable

bot von Werkzeugen zum

Mess-, Parametrier-

Bearbeiten, Analysieren

und Visualisie-

und Verwalten von steu-

rungsoberfläche für

ergeräte-internen Daten.

Modelle wie CANa-

Eigene Erweiterungen

pe beschleunigt

können durch Wiederver-

den Entwicklungs-

wendung von Standard-

prozess deutlich.

funktionen leicht entwickelt und integriert werden.

nektivität sowie Erweiterbarkeit über Apps heute realisieren lassen. Es geht darum, das Potenzial dieser Ansätze integriert und sicher in Unternehmenslösungen bereitzustellen, um es so für das Anwendungsgebiet Messen und Kalibrieren zu erschließen. So bieten beispielsweise Anwendungen für Messdatenauswertungen ein ausgezeichnetes Potenzial für Wertschöpfung durch Nutzung dieser Technologien. Während bisherige Lösungen den Einsatz teurer Spezialsoftware und deren aufwendige Konfiguration notwendig machen, kann eine Cloud-Lösung das einfache Teilen von Messdaten sowie zentrale Algorithmen für Data-Mining unkompliziert bereitstellen.

siv mit diesen Trends. Für das Unternehmen kristallisieren sich im Bereich Steuergeräte-Kalibrierung vier strategische Themenkreise heraus, auf die es seine Anstrengungen konzentriert. Dazu zählen Assistenzsysteme, Mehrwert im Antriebsstrang, flexible Schnittstellen, die es Tool-Abteilungen von Unternehmen oder externen Dienstleistern erlauben, Vector-Produkte einfach in ihre Lösungen zu integrieren, sowie die integrierte und sichere Bereitstellung von Internet-Techniken in den Mess- und Applikationslösungen.

Zukunftssichere Werkzeugkette bei der Steuergeräte-Kalibrierung

Die Kalibrieraufgaben im Antriebsstrang sind vielschichtig und reichen von der Messdatenerfassung bis zur OfflineKalibrierung. Bei Letzterem steht das Arbeiten mit Messdateien und Parameterwerten im Mittelpunkt. Der Applikationsingenieur erzeugt und verwaltet Varianten oder nutzt modellbasierte beziehungsweise virtuelle Techniken zur Optimierung und Datensatzgenerierung. Leistungsfähige Lösungen für die verschiedenen Offline-Aufgabenberei-

Alle diese Trends werden in den nächsten Jahren die Werkzeugketten zum Messen, Kalibrieren und Diagnostizieren nachhaltig verändern. Als ToolHersteller, der seinen Kunden auch zukünftig leistungsfähige Produkte für die Steuergeräte-Kalibrierung liefert, beschäftigt sich Vector Informatik inten-

5/2

HANSER automotive 11-12 / 2015

Aktuelle Lösungen ideal geeignet für Weiterentwicklungen

che stehen bereits heute zur Verfügung und bilden eine ideale Ausgangsbasis für Weiterentwicklungen. Die Palette reicht vom Messdatenauswerte-Werkzeug vSignalyzer über Produkte zum Handling und zur Verwaltung von Applikationsdaten mit dem Stand-Alone-Tool CDM Studio oder der Unternehmenslösung vCDM bis zu CANape, das in Verbindung mit Simulink eine leistungsfähige Plattform für das modellbasierte Applizieren darstellt (Bild 2). Die Bandbreitenanforderungen und Reaktionszeiten in der Messdatenerfassung und Online-Kalibrierung steigen schnell an. Chassis und Assistenzsysteme benötigen inzwischen Übertragungsraten von bis zu 100 Mbyte pro Sekunde. Mit der Mess- und KalibrierHardware VX1000 steht eine schnelle, direkte und zugleich kosteneffiziente Schnittstelle zum Steuergerät zur Verfügung, die über das ASAM-Standardprotokoll XCP on Ethernet mit dem Steuergerät kommuniziert und sich über einen POD (Plug-on-Device) einfach und platzsparend in das Gehäuse integrieren lässt. Für den Datenaustausch im Team sind Lösungen in Vorbereitung, die es erlauben, quasi auf Knopfdruck Arbeits© Carl Hanser Verlag, München

ergebnisse, Messwerte, Bedatungssätze, Reports und so weiter über eine Trusted Cloud zu teilen. Dazu kann sowohl das Unternehmensnetz dienen, als auch eine vom Werkzeughersteller gehostete Cloud. Egal ob man sich im Büro oder auf der Teststrecke befindet – Daten lassen sich problemlos lesen, verändern, zurückschreiben und synchronisieren.

Vision 2020: Calibrators Workbench Skalierbarkeit gepaart mit Investitionssicherheit wird auch in etlichen Jahren für Kunden weit oben auf der Prioritätenliste stehen. Erforderlich sind Werkzeuge und Implementierungen, die mit den Anforderungen wachsen – vom Einzelarbeitsplatz über die Teams bis zur unternehmensweiten Lösung. Die Spezialisten von Vector haben ihre

Vision von der Arbeitsumgebung der nächsten Generation überschrieben mit dem Begriff „Calibrators Workbench“ (Bild 3). Darunter ist ein integriertes Angebot von Werkzeugen zu verstehen, die alle mit einer einheitlichen Benutzeroberfläche und dem gleichen Look & Feel ausgestattet sind. Sie stellen ähnliche Methoden bereit und erlauben über verschiedene Tools ein Bearbeiten, Managen und Analysieren von Applikationsdaten. Zu den wesentlichen Merkmalen der Calibrators Workbench wird die Erweiterbarkeit über Apps beziehungsweise vApps (virtuelle Apps) gehören. Damit kann bestehende Funktionalität (Lesen/Schreiben von Messdateien, Parametersatzdateien, Kennfeldeditoren usw.) für eigene Anwendungen wiederverwendet werden, was die Entwicklungsaufwände reduziert. So wird es möglich, bei Bedarf zusätzliches Expertenwissen zuzu-

kaufen und einfach in die Calibrators Workbench zu integrieren. Die mit Server- oder Cloud-Infrastrukturen ausgestatteten Apps können von Vector stammen oder von externen Dienstleistern. Als zentraler Knoten für Wissensmanagement wird Calibrators Workbench schließlich ein einfaches cloudbasiertes Teilen von Arbeitsergebnissen zur Verfügung stellen. W (oe) » www.vector.com Literatur: [1] KPMG’s Global Automotive Executive Survey 2014 – Strategies for a fast-evolving market

Dipl.-Inf. Michael Vogel ist bei der Vector Informatik GmbH als Business Development Manager für vCDM verantwortlich. [email protected]

Impressum Verlag: Carl Hanser Verlag GmbH & Co. KG, Kolbergerstr. 22, 81679 München © Lizenzausgabe mit Genehmigung des Carl Hanser Verlags, München. Alle Rechte, auch die des Nachdrucks, der photomechanischen und der elektronischen Wiedergabe sowie der Übersetzung dieses Sonderdrucks behält sich der Verlag vor.

5/3

5/4

5/5

5/6

5/7

Ent wicklung FaHrEr a S SISTEnz

aUTOr

dipl.-ing. andrEas patzEr ist Teamleiter in der Produktlinie Measurement & Calibration für Customer relations and Services bei Vector Informatik in Stuttgart.

FahrErassistEnzsystEmE

Fahrerassistenzsysteme Verifikation im fahrzeug und Labor

Über die Sinnesorgane Augen und Ohren erfasst der Mensch hinter dem Steuer die Fahrsituation und Umgebung. Die Sig­ nalverarbeitung im Gehirn interpretiert die gesammelten Informationen, Ent­ scheidungen werden gefällt und Akti­ onen ausgelöst. Zum Beispiel, ob die Lücke am Straßenrand groß genug zum Einparken ist oder ob der Abstand zum Vordermann nachreguliert werden muss. Fahrerassistenzsysteme (Advanced dri­ ver assistance systems oder abgekürzt Adas) unterstützen hierbei den Fahrer, erhöhen die Sicherheit, verbessern den Komfort und auch die Ökonomie. Als eine Art „aufmerksamer Beifah­ rer“ müssen Fahrerassistenzsysteme ebenfalls in der Lage sein, die Umgebung zuverlässig zu erkennen. Dabei kommen sehr häufig Radar­, Ultraschall­ oder Videosensoren zum Einsatz, die Infor­ mationen zur Fahrsituation oder der

Fahrzeugumgebung an die Steuergeräte liefern. Komplexe Algorithmen detektie­ ren aus den Sensordaten Objekte wie Straßenschilder, parkende Fahrzeuge, weitere Verkehrsteilnehmer etc. und lösen Aktionen aus. Zur Überprüfung des Sensorsystems kann es genügen, nur Ergebnisse des Algorithmus zu messen und mit der Realität zu verifizieren. zugriFF auF diE sEnsor- und algorithmusdatEn

Als Beispiel soll hier der Abstandsradar eines Adaptive­Cruise­Control­Systems dienen: Der Sensor detektiert Objekte durch Reflektionen des Radarstrahls. Für jedes Objekt liefert das Steuergerät Abstandsinformationen in Form von X­ und Y­Koordinaten. Als Übertragungs­ medium dient der CAN­Bus. Das voll­ ständige Erfassen aller Radarreflektionen im Sensor ist in diesem Fall nicht not­ wendig. Sollen aber beispielweise die Daten für die spätere Stimulation im Labor aufgezeichnet werden, müssen alle Eingangsgrößen des Algorithmus gemessen werden – über 100.000 Signale mit mehreren MB/s sind dann nichts Ungewöhnliches. Für Systeme zur Verkehrszeichenerken­ nung oder für Spurhalteassistenten kom­ men bildverarbeitende Steuergeräte mit Videosensoren zum Einsatz. Ein Algorith­ mus analysiert das Videobild und detek­ tiert Schilder oder Fahrspuren. Die Verar­ beitung der Daten im Steuergerät setzt zumeist eine hohe Performance des Mikro­ controllers voraus. Ob die Sensordaten aus einem Video­ oder Radarsystem stam­ men, hat dagegen nur wenig Einfluss auf

die Anforderungen an die Messtechnik. Unabdingbar ist eine leistungsfähige Lösung zum Transport der Messdaten. Für die Bewertung und Optimierung der Algorithmen lautet also die Forderung an die Messtechnik: alle Ein­ und Ausgangs­ größen in den Algorithmus sowie alle notwendigen Zwischengrößen innerhalb des Algorithmus erfassen zu können, ohne eine zusätzliche Belastung des Kon­ trollers zu verursachen, ❶. Serielle Bussysteme wie CAN und Flexray stoßen bei den notwendigen Datendurchsätzen an ihre Grenzen. Deshalb werden kontrollerspezifische Schnittstellen wie Nexus, DAP (Device access port) oder Aurora eingesetzt, um die große Menge an Messdaten zu trans­ portieren. Damit nicht für jede messtech­ nische Aufgabe eine separate Lösung entwickelt werden muss, macht es Sinn, auf etablierte und bewährte Standards zu setzen. Dazu bietet sich die VX1000­ Mess­ und Kalibrier­Hardware von Vec­ tor an, die über eine kleine Platine (Plug on device, POD) die Daten aus dem Kont­ roller­Interface an ein Basismodul über­ trägt, dort in das standardisierte XCP on Ethernet (XCP, Universal measurement and calibration protocol) wandelt und den Datenstrom mit hohem Durchsatz zum PC transferiert [1]. ValidiErung dEr sEnsordatEn mit dEr rEalität

Die Ergebnisse der Objekterkennung des Steuergeräts müssen nun mit der Realität verifiziert werden. Ist der vom Radarsen­ sor ermittelte Abstand zum Vordermann auf der Straße wirklich 45,5 m? Um die

Fahrerassistenzsysteme erfassen über verschiedenste Sensoren die Umgebung des Fahrzeugs. Warnungen an den Fahrer oder (teil-) autonome Eingriffe in die Fahrsituation erfolgen immer auf Basis von korrekten Ergebnissen der Objekterkennungsalgorithmen. Der Beitrag von Vector Informatik stellt typische Herausforderungen bei der Verifikation der Objektdaten sowie beim Test der Bildverarbeitungsalgorithmen vor. Mit dem XCP-Standard lässt sich der notwendige hohe Datendurchsatz beim Messen und Kalibrieren realisieren. ❶ Erfassung der Ein- und Ausgänge, der Umgebung und aller für die Bewertung des Algorithmus relevanter Daten; Darstellung aller Daten, Abstimmung der Parameter

40

5/8

Sonderheft Electronica 2014

41

5/9

Ent wicklung FaHrEr a S SISTEnz

❷ Videobild der Umgebung mit erkannten Objekten des Abstandradarsystems und Objektanzeige aus der Vogelperspektive

Sensordaten mit der Realität abzuglei­ chen, muss die Realität erst einmal mit­ erfasst werden. Eine Kamera, die unab­ hängig vom Sensorsystem betrieben wird, zeichnet deshalb die Fahrsituation auf. Über den Abgleich der vom Steuer­ gerät erkannten Objekte mit dem Video­ bild verifiziert der Entwickler nun schnell und zuverlässig die Algorithmen der Objekterkennung seines Steuergeräts. Das Überlagern der Objekte mit dem Videobild erfolgt über die Mess­ und Kalibrier­Software CANape Option Dri­ ver Assistance. So kann direkt ermittelt werden, an welcher Stelle etwas detek­ tiert wurde und ob die Erkennung sinn­ voll ist. In ❷ sind Kreuze an den Stellen im Bild zu sehen, die den vom Sensor ermittelten Daten entsprechen. Dazu wird eine Umrechnung der vom Sensor detektierten Koordinaten, wie Abstand nach vorne und zur Seite, auf Pixel­Koor­ dinaten des Videobildes im PC genutzt.

algorithmEn abstimmEn und optimiErEn

Treten Abweichungen beim Vergleich der detektierten Objekte mit der Realität auf, sind Optimierungen des Algorithmus notwendig, die durch Anpassung der Parameter erfolgen. Dazu müssen die Parameter im Programmcode so definiert sein, dass sie zur Laufzeit im RAM lie­ gen und über einen Schreibzugriff verän­ dert werden können. Zur Abstimmung der Parameter stehen die Mechanismen des Mess­ und Kalibrierprotokolls XCP [2] zur Verfügung. Während der Laufzeit verändert der Entwickler die Parameter und erfasst direkt die Auswirkungen. Dabei ist XCP nicht auf den Einsatz im Steuergerät beschränkt. Der Algorithmus läuft beispielweise auch als virtuelles Steuergerät in Form einer DLL (Dynamic link library, dynamische Programmbibli­ othek) auf dem PC ab. Parametrierungen

❸ Unterschiedliche Eingangsquellen zur Stimulation eines virtuellen videobasierten Steuergerätes in CANape; reale Onlinedaten aus dem Steuergerät über die VX1000-Lösung, aus einer Kamera oder einer aufgezeichneten Videosequenz

42

5/10

und Messungen erfolgen ebenfalls über XCP – der PC wird also zur Rapid­Proto­ typing­Plattform. Wie kann nun möglichst komfortabel ein XCP­Treiber in eine DLL eingebunden werden? Wie erfolgt die Kopplung der Eingangsdaten in die DLL? Im Falle einer Simulink­basierten Entwicklung wird über den „Simulink Coder“ von MathWorks der Code für unterschiedli­ che Zielplattformen aus dem Modell generiert. Unter anderem kann das Vec­ tor­Tool CANape als Zielplattform ange­ geben werden. Im Code­Generierungs­ prozess für CANape wird automatisch ein XCP­Treiber integriert. Am Ende des Prozesses steht eine DLL mit XCP­Treiber und die Beschreibungsdatei für Steuer­ geräte im A2L­Format. Beides wird in CANape integriert und die Ein­ und Aus­ gangsports der DLL mit realen Daten ver­ knüpft. Bei Messungsstart überträgt CANape die gemessenen Sensordaten als Eingangsvektor an den Algorithmus und das virtuelle Steuergerät berechnet die Ergebnisse. Die Optimierung der Para­ meter erfolgt dabei in der gleichen Art und Weise, wie in einem realen Steuer­ gerät. Ein mit CANape ausgeliefertes C++­Projekt führt bei handgeschriebe­ nem Programmcode zum gleichen Ergebnis. stimulation mit sEnsordatEn

Entwickler von Sensorsystemen werden mit zwei Problemen konfrontiert: : Sinnvolle, realitätsnahe Daten aus einem Sensor stehen oft nur im Fahr­ zeug zur Verfügung, im Labor fehlt dafür die notwendige Umgebung. : Die Reproduzierbarkeit von Sensor­ daten ist mit hohem Aufwand verbunden. Aus diesen Gründen ist die Stimulation der Steuergeräte – egal ob es sich um ein reales oder ein virtuelles Steuergerät handelt – mit vorher aufgezeichneten Sensordaten ein wesentlicher Bestandteil der Entwicklung. Die Daten können ent­ weder unter Umgehung der Eingänge per XCP direkt in den Speicher des Steuer­ gerätes geschrieben werden. Die notwen­ dige Bandbreite stellt wiederum das VX1000­System zur Verfügung. Eine weitere Möglichkeit ist, die Daten über die Sensoreingänge in das Steuergerät zu transportieren, ❸. Bei einem virtuellen Steuergerät er­ folgt die Stimulation, indem einem Ein­

gangskanal in CANape ein aufgezeichne­ tes Video oder Signale aus Messdateien zugeordnet wird. Bei realen Steuergerä­ ten sind die physikalischen Schnittstel­ len zu berücksichtigen. Bei Videosyste­ men kann beispielsweise der Videosen­ sor auf einen Monitor gerichtet werden, auf dem eine aufgezeichnete Verkehrssi­ tuation abläuft. Durch das Verwenden der gleichen Videos beziehungsweise Signale wird auch das Steuergerät immer auf die gleiche Art und Weise stimuliert – die Reproduzierbarkeit der Daten ist sichergestellt. Eine Verhaltensänderung des Algorithmus hängt dann nur von der Parametrierung und nicht von veränder­ ten Eingangsvektoren ab. Sowohl bei vir­ tuellen als auch bei realen Steuergeräten können nicht nur Eingänge mit Daten stimuliert werden. Notwendige Zustände und Vorbedingungen lassen sich eben­ falls über XCP setzen.

zusammEnFassung

Die optimale Abstimmung von Steuerge­ räten erfordert einen hohen Aufwand: Mess­ und Kalibrierwerkzeuge kommu­ nizieren mit den Steuergeräten, Code­ Instrumentierungen sind notwendig, Prozesse zur Generierung von A2L­ Beschreibungsdateien werden definiert und vieles mehr. All diese Dinge sind aber unabhängig von der Aufgabenstel­ lung des Steuergerätes. XCP ist dabei eine standardisierte Lösung, die für alle Arten von Steuergeräten geeignet ist. Fahrerassistenzsysteme stellen zwar besondere Anforderungen an Daten­ mengen und Performance, aber die Ver­ wendung existierender Werkzeuge auf der Basis von XCP, wie sie CANape und die VX1000­Familie darstellen, bilden eine komfortable Lösung auch für Adas­ Steuergeräte. Die Unterstützung von

Videodaten bis hin zur Nutzung einer Rapid­Prototyping­Plattform für die Ent­ wicklung bildverarbeitender Algorith­ men stellen eine natürliche Weiterent­ wicklung bestehender Lösungen dar, die sich nahtlos in bereits bestehende Entwicklungsprozesse integriert. litEraturhinwEisE [1] Kless, a.: neue Messkonzepte für steuergeräteinterne Signale mit hohen Datenraten und kurzen Messrastern In: Hanser automotive (2012), nr. 5-6, S. 30-33 [2] Patzer, a; zaiser, r.: XCP – Das Standardprotokoll für die Steuergeräte-Entwicklung. Stuttgart: Vector Informatik, 2014

download dEs bEitrags

www.springerprofessional.de/aTzelektronik

WEBINAR “GEOMETRY SIMPLIFICATION” FÜR DEN ELEKTRONISCHEN BEREICH AM 04.12.2014 MEHR INFOS UNTER WWW.CD-ADAPCO.COM/BROWSE/LIVE_WEBINAR

SIMULATING SYSTEMS

STRÖMUNG − WÄRMETRANSFER − STRUKTUR − EMAG − ELEKTROCHEMISCHE REAKTIONEN − CASTING OPTIMIERUNG − CHEMISCHE REAKTIONEN − VIBRO-AKUSTIK − MULTIDISZIPLINÄRE CO-SIMULATIONEN

Strömungs-, Wäremetransfer- und elektromagnetische Analyse einer E-Maschine

Strömungs-, Wäremetransfer- und elektromagnetisCHe Analyse eines Batteriemoduls, Eigentum der ASCS, Stuttgart

[email protected] www.cd-adapco.com

5/11

Testen + Tools CDM

Testen + Tools CDM

Bilder: Vector Informatik

Bild 1: Durch einen klar definierten Prozess trägt das CDM-System zu einer wesentlichen Qualitätsverbesserung beim Kalibrieren der Steuergeräte bei.

Kalibrierdatenverwaltung: Ein Puzzlespiel? Effizienzsteigerung bei der Steuergeräte-Kalibrierung Die kurzen Innovationszyklen und der hohe Kostendruck bei der Steuergeräte-Entwicklung führen zu einer Arbeitsteilung, bei der die Entwicklung der Software von ihrer Anpassung an das gewünschte Verhalten im Fahrzeug getrennt ist. Für aktuelle Fahrzeuge sind zehntausende solcher Kalibrierdaten zu ermitteln und zu verwalten – und zwar für jede einzelne Fahrzeugvariante. Um Fehler zu vermeiden, bedarf es derselben QualitätsstanAutoren: Stephan Herzog, Andreas Patzer, Michael Vogel dards wie für die Entwicklung der eigentlichen Software.

B

ei der Funktionsentwicklung von Steuergerätesoftware gilt es, hohe Qualitätsstandards (SPICE, CMMI) einzuhalten. Dabei ist die korrekte Parametrierung der Steuergeräte genauso entscheidend wie die grundsätzlich korrekte Funktionalität der Software im Steuergerät. Beim Anpassen der Parameter muss deshalb der Qualitätsanspruch identisch sein. Diesen Anpassungsvorgang bezeichnet man als „Applikation“ oder „Kalibration“. Essenziell für die Prozesssicherheit und die Qualität des Gesamtsystems sind genau nachvollziehbare Kalibrierungen und konsistente Bedatungen in jeder denkbaren Variante. Immer kürzere Innovationszyklen sowie höchste Anforderungen an Qualität und Effizienz machen bei der Entwicklung von elektronischen Systemen eine hohe Wiederverwendung der Software in vielen Typen und Fahrzeugvarianten unabdingbar. Jede Variante in einem Steuergerät führt zu einem eigenen Parametersatz; als Folge steigt die Anzahl an Parametersätzen stark an. Für Steuergeräte eines Dieselmotors mit Euro-6-Abgasnorm sind heute ungefähr 60.000 Parameter zu kalibrieren. Steuergeräte aus

5/12

62

Automobil ElEktronik 05-06/2015

den Bereichen Fahrwerk und Innenraum kommen zwar mit weniger Parametern aus, aber dennoch erfordert die höhere Anzahl der Varianten auch hier eine dedizierte Lösung zum Datenmanagement. In Summe muss der Hersteller für ein aktuelles Fahrzeug viele tausend Parametersatzdateien ermitteln und verwalten.

Qualitätsverbesserung durch einen klaren Prozess Wesentliche Hilfe beim komplexen Verwalten der Kalibrierdaten bietet der Einsatz einer speziellen Datenmanagement-Lösung. Sie gewährleitet, dass tausende von Parametern in genau definierten Kombinationen für hunderte von Fahrzeugabstimmungen in die korrekten Varianten gelangen. Gleichzeitig muss jede Änderung im Sinne der Qualitätssicherung exakt nachvollziehbar sein. Eine derart klar definierte Vorgehensweise schafft Prozesssicherheit und erhöht die Datenqualität. Die Originaldateien der Ingenieure, die ihre Arbeitsergebnisse in ein CDM-System (Calibration Data Management) einpflegen, unterstehen einer Versionsverwaltung. Somit ist auf einen Blick ersichtlich, welche Parawww.automobil-elektronik.de

metersätze in eine bestimmte Variante eingeflossen sind und wo sie wiederverwendet werden. Dies stellt die automatische Aktualisierung einer neuen Bedatungsversion in allen betreffenden Varianten sicher. Ein Qualitäts- und Reifegradmodell hilft innerhalb des Projekts, die Änderungen für die Datenintegration zu dokumentieren und den Projektfortschritt zu überwachen. Das CDM-System stellt ein mehrstufiges Konzept für die Datenintegration bereit. Nachdem sämtliche Ergebnisse der Applikationsingenieure in das System eingegeben sind, ist dieses in der Lage, Konflikte durch Fehl- oder Doppelbedatungen über zugeordnete Verantwortlichkeiten und Regeln zu lösen. Die Ergebnisse lassen sich anschließend nach dem Vier-Augen-Prinzip validieren und auf Vollständigkeit prüfen. Erst dann sind die Daten bereit zur Konsolidierung für den nächsten Datenstand und die Freigabe für die nächste Phase. Das ermöglicht auch in der Zusammenarbeit mit Entwicklungspartnern und bei unterschiedlichen Verantwortungsbereichen immer einen Zugriff auf die korrekten Daten.

Effizienz durch intelligentes Variantenmanagement Neben der Unterstützung von Kalibrieraufgaben durch einen klar strukturierten Prozess ist der produktive Umgang mit der Vielzahl der Varianten eine Kernaufgabe des Datenmanagements. Eine „Variante“ repräsentiert einen Satz von Fahrzeugattributen wie Hubraum, Getriebetyp oder Abgasnorm. Die unterschiedlichen Ausprägungen bedingen Änderungen in der Parametrierung der Steuergerätesoftware, wobei man hier von „Derivat-Applikationen“ spricht. Das Variantenmanagement stellt Mechanismen bereit, die beispielsweise sicherstellen, dass

Eck-DATEN Bei der Steuergerätekalibrierung sind zehntausende Daten für jede einzelne Fahrzeugvariante zu ermitteln und zu verwalten. Für die geforderte Qualität ist ein sicherer Prozess sowie eine durchgängige Tool-Unterstützung notwendig.

www.automobil-elektronik.de

alle Varianten automatisch eine konsistente Bedatung erhalten und vermeidet so unnötige Doppelarbeit. Bei Parametern, die von Systemattributen abhängen, kommen Regeln zur Beschreibung der Abhängigkeiten zum Einsatz. Das gewährleistet ohne Mehrarbeit eine gleiche Bedatung aller Varianten mit identischen Systemattributen.

Think big, start small Unternehmen setzen das Datenmanagement in unterschiedlichem Umfang ein. Häufig entstehen Lösungen aus den konkreten Herausforderungen für bestimmte Aufgaben. So benötigt ein Applikationsingenieur beispielsweise Unterstützung beim Verteilen der Arbeitsergebnisse auf alle Applikationsderivate. Dagegen gehört es zur Aufgabe eines Projektleiters, Konflikte zu lösen oder zu vermeiden, die durch die Abgabe der Kalibrierdaten seiner Teammitglieder in das System entstehen. Mit zunehmender Verbreitung solcher Einzellösungen gewinnt eine einheitliche Datenmanagement-Lösung für das gesamte Unternehmen immer mehr an Bedeutung. Sie bildet den gesamten Prozess ab und unterstützt auch angrenzende Bereiche wie Software-Entwicklung und Validierung. Aus diesem Grund ist es hilfreich, wenn die DatenmanagementLösung sowohl den spezifischen Anforderungen eines Applikationsingenieurs als auch eines Teams sowie des kompletten Unternehmens gerecht wird. Eine derart skalierbare Lösung lässt sich schrittweise einführen und ausbauen.

Datenmanagement beim Applikationsingenieur Bei der Steuergeräteapplikation bewertet der Ingenieur mithilfe von Softwarewerkzeugen (MCD-Tools) am Prüfstand oder im Fahrzeug zunächst das aktuelle Verhalten einer Systemkomponente, um die Parameter anschließend in Richtung des Sollverhaltens zu verstellen. Dieser Online-Kalibrierung genannte Vorgang umfasst jedoch nur einen Teil der notwendigen Arbeiten. Häufig ist es darüber hinaus erforderlich, die Parameter für die unterschiedlichen Fahrzeugvarianten ohne direkte Verbindung Automobil ElEktronik 05-06/2015

63

5/13

Testen + Tools CDM

Eine skalierbare Lösung für alle Anwendungsfälle

Bild 2 (oben): Eine skalierbare Lösung deckt die Anforderungen an Prozesssicherheit, Datenqualität und das Variantenmanagement ab. Bild 3 (rechts): CDM Studio zeigt unter anderem den Status der Steuergerätekalibrierung.

zum Steuergerät zu vergleichen und zu bearbeiten (OfflineKalibrierung). Dies ist zum Beispiel der Fall, wenn man Parameter nach den Vorgaben der Softwareentwicklung vorbedatet, bei der Übernahme von Ergebnissen aus ähnlichen Vorgänger-Projekten, beim Kopieren von Werten aus der Online-Kalibrierung in verschiedene Varianten oder beim Optimieren mit numerischen Methoden anhand von Modellen. Der Applikationsingenieur benötigt für diese Aufgaben ein Werkzeug mit einer Benutzeroberfläche ähnlich wie Microsoft Excel, in der sich beliebige Parameter (Zeilen) gleichzeitig mit beliebigen Spalten (Varianten) darstellen und bearbeiten lassen. Zusätzlich muss es die besonderen Erfordernisse der Kalibrierung (ASAM-Standard-Formate wie CDF2.0, Kennfelder, Diagnoseinformationen) unterstützen.

Zusammenarbeit im Team Steuergeräteapplikation ist zu großen Teilen Teamarbeit. Diese Teams setzen sich häufig aus Mitgliedern unterschiedlicher Unternehmen zusammen (Fahrzeughersteller, Steuergerätelieferant und Ingenieursdienstleister). Bei der zunehmenden Globalisierung und Spezialisierung gewinnt die effiziente Zusammenarbeit von Applikationsteams daher immer größere Bedeutung. So müssen die Arbeitsergebnisse schnell verteilbar sein, wobei die Vernetzung über E-Mail und Internet hilfreich ist. Um die Daten jedoch zwischen unterschiedlichen Systemen auszutauschen, sind häufig viele manuelle Arbeitsschritte erforderlich – eine zeitraubende und fehleranfällige Angelegenheit. Die Datenverwaltung versetzt die Teams nun in die Lage, die Informationen automatisch zu verteilen. Eine Integration des E-Mail-Systems informiert alle Beteiligten über Datenänderungen, neue Freigaben und Softwareänderungen. Dadurch ist gewährleistet, dass die Teams zeitnah auf einem identischen Datenstand arbeiten. 5/14

64

Automobil ElEktronik 05-06/2015

Ebenso wichtig wie eine automatisierte Verteilung ist die Verfügbarkeit der Daten an Orten mit schwieriger Netzwerkanbindung. Idealerweise lässt sich ein Applikationsprojekt aus der zentralen Datenbank auf den Laptop eines Ingenieurs auschecken, sodass es im lokalen Netzwerk für den gemeinsamen Zugriff verfügbar ist.

Datenmanagement im Unternehmen Eine Lösung für das Datenmanagement ist naturgemäß eng in die Werkzeugkette für die Entwicklung elektronischer Systeme eingebunden. Die Änderungen in den Applikationsdaten haben einen direkten Bezug zu Anforderungs-Management-Systemen, ChangeManagement-Systemen und vielen anderen ALM-Anwendungen (Application Lifecycle Management). Leistungsfähige CDMSysteme zeichnen sich durch hohe Flexibilität aus und lassen sich über Automatisierungsschnittstellen, APIs (Application Programming Interfaces) oder Webservices in bestehende Systeme einbetten. Über eine Integration mit OSLC (Open Services für Lifecycle Collaboration) ist es beispielsweise möglich, eine durchgängige Nachvollziehbarkeit von Änderungen zu realisieren.

Anpassung an Besonderheiten Insbesondere beim Einsatz über Bereichsgrenzen hinweg stellen sich an ein CDM-System besondere Anforderungen. Denn die Arbeitsweise bei der Kalibrierung eines Chassis-Controllers unterscheidet sich spürbar von der eines Motorsteuergeräts. Durch die jeweils unterschiedlichen Anforderungen aus Steuergerät und Organisation haben sich verschiedene Arbeitsweisen etabliert und bewährt. Daher ist es bei der Einführung des Datenmanagements wichtig, die verschiedenen Arbeitsmodalitäten der Fachbereiche bestmöglich abzubilden, anstatt einen Standardprozess vorzugeben. www.automobil-elektronik.de

Prozesssicherheit, hohe und konsistente Datenqualität sowie effizientes Variantenmanagement sind die Grundvoraussetzungen für erfolgreiche Kalibrierprojekte. Vector Informatik bietet hierfür weitreichende Unterstützung – vom Einzelarbeitsplatz bis zur Unternehmenslösung. Das CDM Studio genannte Tool dient dem Applikationsingenieur als Werkzeug zum Bearbeiten von Parametersatzdateien (Bild 3). Die bei der Steuergerätekalibrierung entstandenen Parameter lassen sich komfortabel anzeigen, gegenüberstellen und bearbeiten. Aufgrund der vielfältigen Import-Möglichkeiten spielt die Herkunft der Parameter nahezu keine Rolle. CDM Studio unterstützt alle gängigen Mess- und Kalibrierwerkzeuge wie CANape, INCA, MARC und andere. Arbeiten mehrere Applikateure im Team, sind Lösungen zur sicheren Datenablage und Datenverwaltung gefragt. Bei vCDM handelt es sich um eine datenbankgestützte Plattform für Applikationsteams und ganze Unternehmen. Mithilfe von Arbeitspaketen und Berechtigungen vermeidet das System Datenkonflikte; es erkennt und löst Überschneidungen und erlaubt das lückenlose Verfolgen von Datenänderungen. Durch die Verwaltung von Abhängigkeiten, die automatische Berechnung von Parameterwerten und die Wiederverwendung von Arbeitspaketen bleibt auch eine große Anzahl von Varianten sicher beherrschbar. Das Ergebnis sind konsistente Datenstände mit einer hohen Datenqualität, die sich mit Data-Mining und Report-Funktionen für weitere Qualitäts- und Effizienzsteigerungen nutzen lassen. Zur grafischen Darstellung und Verarbeitung von Applikationsdaten schließlich dient das integrierte CDM Studio. Somit stehen verschiedene Lösungen mit demselben Look&Feel zur Verfügung, sodass die Anwender direkt zwischen unterschiedlichen Anwendungsfällen wechseln können. Auch die Berücksichtigung der Arbeitsweisen unterschiedlicher Fachbereiche oder Unternehmen ist unabdingbar, wie Wolfgang Löwl (Gruppenleiter Tool-Entwicklung bei Bosch im Bereich Powertrain) bestätigt: „Gemeinsam mit Vector hat Bosch ein leistungsfähiges CDM-System entwickelt, das unsere speziellen Anforderungen voll erfüllt. Es ist seit zehn Jahren erfolgreich im Einsatz.“

Ausblick In der Zukunft wird es immer wichtiger, die enormen Datenmengen nicht nur qualitätssteigernd sondern auch wertsteigernd einzusetzen. So ist es möglich, mit Datamining-Algorithmen aus der Historie bestehender Applikationsdaten automatisch neue Bedatungen zu generieren. Diese Bedatungen können dann mit speziellen Modellen validiert werden. Auf diese Weise lassen sich zukünftig immer mehr Aufgaben aus dem Fahrzeug ins Büro verlagern. (av) ■

Autoren Dipl.-Ing. Stephan Herzog Business Development Manager für den Bereich Messen und Kalibrieren bei Vector Informatik. Dipl.-Ing. Andreas Patzer Teamleiter in der Produktlinie Measurement & Calibration für Customer Relations and Services bei Vector Informatik. Dipl.-Inf. Michael Vogel Business Development Manager für vCDM bei Vector Informatik.

infoDIREKT www.automobil-elektronik.de

341ael0615 Automobil ElEktronik 05-06/2015 hue_image_Woerter_blau_56x257mm.indd 1

65

5/15

23.02.2016 17:06:07

llll Motorsteuerung

Motorsteuerung llll

(Bild: (Bild: maf-map-engineering) maf-map-engineering)

Entwicklung + Test

Ein Ritt auf der Rasierklinge Optimale Parametrierung eines Motorsteuergerätes für Rennsportanwendungen Bei der Abstimmung von Motorsteuergeräten für Serienfahrzeuge arbeiten Elektronikentwickler gewöhnlich mit Prüfständen und zahlreichen Testfahrten mit verschiedenen Streckenprofilen. Bei Spezial-Motorsteuergeräten für Dragster-Rennen stehen diese Hilfsmittel nicht zur Verfügung. Mit Hilfe des Vector-Mess- und Kalibrierwerkzeugs CANape wird ein Motorsteuergerät mit knappem Budget, ohne Prüfstand, ohne ständige Gefahr der Zerstörung des Motors und innerhalb weniger Testläufe auf Höchstleistungen getrimmt. Von Andreas Patzer

W

er an einem Wochenende Mittelklassefahrzeuge mit Serienmotoren und vielen hundert PS unter ohrenbetäubendem Lärm und mit unglaublichen Beschleunigungen Distanzen von einer viertel Elektronik automotive 4.2011 5/16

Meile (402,34 m) fahren sieht, ist mit großer Wahrscheinlichkeit Zuschauer eines Dragster-Rennens (Bild 1). Da bei solchen Beschleunigungsrennen kurzfristig höchste Motorleistungen gefragt sind, konzentriert sich ein gro-

ßer Teil des Entwicklungsaufwands auf die Abstimmung der Motorsteuerung. Die Kunst für die Renn-Teams besteht unter anderem darin, mit minimalem Budget optimale Ergebnisse zu erzielen. Man muss sich der Belastungsgrenze des Motors soweit nähern, dass er maximale Leistung liefert, ohne ihn zu zerstören. Nicht nur die Fahrt selbst, sondern bereits die Abstimmung gleicht daher einem „Ritt auf der Rasierklinge“.

derungen des Rennens präpariert wird. Neben diesem Umbau ist vor allem das Abstimmen der Motorsteuerung eine der größten technischen Problemstellungen. Da die Bedatung des Seriensteuergeräts in keiner Weise mehr mit dem modifizierten Motor harmoniert, sind hier etliche Herausforderungen zu meistern. In der Serienentwicklung ist das Messen und Kalibrieren von Steuergeräten für den Fahrzeughersteller oder -zulieferer eine anspruchsvolle, aber tägliche Routine-Arbeit. Während die Applikationsingenieure mit dem Motor auf dem Prüfstand und im Fahrzeug die verschiedenen Streckenprofile abfahren, greifen sie über eine A2LBeschreibungsdatei auf die internen Parameter und Messgrößen des Steuergerätes zu und legen die optimalen Parameter fest. Die Komplexität dieser Aufgabe erhöht sich durch eine Reihe von Randbedingungen nochmals deutlich: Einerseits sind zahlreiche Motor- und Fahrzeugvarianten zu berücksichtigen und unterschiedliche Abgasnormen einzuhalten, andererseits muss man gleichzeitig dem Steuergerät das jeweils herstellertypische Fahrverhalten aufprägen. Alle Optimierungen stehen zudem unter der Prämisse, bestimmte Verbrauchsgrenzwerte einzuhalten. Erleichternd auf die Ab-

stimmung des Motors wirkt sich der Umstand aus, dass die Applikationsingenieure und Software-Entwickler gemeinsam den kompletten SoftwareProzess beherrschen. Dieser reicht von der Code-Erstellung und -Entwicklung über den Compiler/Linker-Lauf bis zur A2L-Generierung und dem FlashVorgang.

ˆ Mit wenigen Messfahrten zum optimalen Ergebnis Das Abstimmen von Motoren für Dragster-Rennen unterscheidet sich davon grundlegend. Weder die Einhaltung von Verbrauchswerten noch die Unterstützung verschiedener Motoroder Fahrzeugvarianten spielen eine Rolle, sondern alle Anstrengungen müssen sich dem einen Ziel unterordnen, die rund 400 Meter Distanz möglichst schnell hinter sich zu bringen. Des Weiteren sind die Renn-Teams keine finanzstarken Unternehmen, sondern Privatpersonen, die sich ein teures Hobby leisten. Sollte aufgrund einer Fehlbedatung der Motor zerstört werden, muss für viel Geld ein neuer beschafft werden. Es stehen auch keine Prüfstände für Motorentestläufe zur Verfügung. Zum einen gibt es mangels Nachfrage für diese Nischenanwendung praktisch

ˆ Höchstleistung durch optimal abgestimmtes Motorsteuergerät Ein Fahrzeug für Dragster-Rennen aufzubauen und zu unterhalten, erfordert neben dem zeitlichen und wirtschaftlichen Aufwand ein großes Maß an Leidenschaft und Begeisterung. Dreh- und Angelpunkt dieser Rennsport-Unternehmung ist der Motor, der als Serienprodukt gekauft und durch mechanische Umbauten für die Anforwww.elektroniknet.de

l Bild 1. Für die optimale Abstimmung des Motorsteuergeräts werden die Kennwerte während des Testlaufs in Echtzeit auf Basis der anfallenden Messergebnisse verstellt. (Bild: maf-map-engineering) www.elektroniknet.de

Entwicklung + Test

keine geeigneten Prüfstände, zum anderen ist es nicht möglich, die Motoren bei ihren Maximaldrehzahlen von bis zu 10 000 Umdrehungen pro Minute und bei Ladedrücken bis zu 3,5 bar in einem quasi statischen Betrieb zu optimieren. Die Belastungen sind so groß, dass die Motoren die Drehzahlen nur kurze Zeit, d.h. etwa zwei bis drei Sekunden pro Gang, aushalten würden, bevor sie aufgrund der thermischen Belastung zerstört würden. Der einzig gangbare Weg für die Renn-Teams besteht darin, während der Fahrt möglichst viele Messgrößen zu sammeln und anhand dieser Informationen die Parameter zu optimieren. Aber auch dabei bestehen etliche Einschränkungen. Einerseits sind die Motoren nur für wenige Fahrten verwendbar, bevor ein Austausch notwendig ist, andererseits dauern die Fahrten meistens weniger als zehn Sekunden. Für den Optimierungsprozess wird daher eine außergewöhnlich rationelle Vorgehensweise zum entscheidenden Faktor über Erfolg oder Misserfolg.

ˆ Spezielle Motorsteuerung ersetzt Seriensteuergerät Eine hocheffiziente Motorsteuerung im Bereich der Dragster-Rennen kommt aus dem in Berlin ansässigen Unternehmen maf-map-engineering. Das aus Leidenschaft zum Motorsport gegründete Unternehmen stellt eine komplette Lösung zur Verfügung, um aus den Motoren die maximale Leistung herauszuholen. Seine Leistungsfähigkeit stellt das Konzept zum Beispiel bei einem VW Polo unter Beweis, der über eine Leistung von 1047 PS verfügt. Als Grundlage dient das Motorsteuergerät ECU481, dessen Hard- und Software das Unternehmen komplett selbst entwickelt hat, um alle Komponenten bestmöglich zu kontrollieren. Die Software entsteht auf der Basis physikalischer Modelle, wobei man die Modellierungsumgebung Scilab mit entsprechendem Code-Generator für die Funktionsschicht einsetzt. Die Basis-Software entsteht handcodiert in C. Da kein Prüfstandbetrieb und nur wenige kurze Messfahrten möglich sind, liegt ein Hauptaugenmerk in der sicheren Erfassung aller relevanten Elektronik automotive 4.2011 5/17

llll Motorsteuerung

Größen aus dem Steuergerät über eine kostengünstige Schnittstelle. Die Wahl fiel daher auf das standardisierte Messund Kalibrierprotokoll XCP on Ethernet. Außerdem entschied man sich auf der Suche nach einem entsprechenden Werkzeug schon sehr früh für das Mess- und Kalibrierwerkzeug CANape der Vector Informatik.

Modellbasierte Entwicklung und Steuergeräte-Kalibrierung mit XCP und CANape Case Study HOERBIGER

ˆ Automatisierte EchtzeitParameteroptimierung Die wichtigen Kennwerte des Steuergeräts verstellen die Berliner Spezialisten beziehungsweise die jeweiligen Renn-Teams während des Testlaufs in Echtzeit auf Basis der anfallenden Messergebnisse. Denn aufgrund der extrem kurzen Fahrzeiten ist es dem Fahrer während einer Messfahrt nicht möglich, alle bei der Fahrt anfallenden Daten mental zu erfassen, daraus sinnvolle Entscheidungen abzuleiten und auch noch die richtigen Werte an das Steuergerät zu schicken. So profitiert man hier in besonderer Weise von CANape-Spezialfunktionen, die eine Automatisierung dieses Vorgangs erlauben: Aus Simulink-Modellen wird über den Real-Time Workshop Code generiert, der nach dem Compilieren und Linken als DLL in CANape läuft. Zur Laufzeit der Messfahrt erhält der

Bild: HOERBIGER

l Bild 3. CANape visualisiert die verschiedenen Parameter und bietet komfortable Verstellmöglichkeiten.

optimierte Parameter

Algorithmus in der DLL die Messdaten aus dem Motorsteuergerät, ermittelt daraus die optimalen Parameter und verstellt über XCP-Mechanismen und CANape selbstständig die Parameter im Steuergerät (Bild 2). Da der Aufwand zu hoch ist, für alle Parameter eigene Applikationsmodelle zu entwickeln, stellt man viele Parameter nach wie vor manuell ein. Eine genaue Analyse der aufgezeichneten Messdaten nach einer Fahrt mit CANape offenbart die kritischen Stellen und erlaubt zügig entsprechende Korrekturen (Bild 3). Außerdem Matlab/Simulink hilft das Werkzeug, die Anzahl der notReal-Time Workshop wendigen Testfahrten so gering wie möglich CANape Target zu halten. Aus den Ergebnissen leiten sich Quelldie neuen ParameCode terwerte ab, die die Entwickler entweder Compiler Modell online im RAM des MAP Linker A2L Steuergeräts verstellen oder als neue Werte im Modell vor Modell I/O einer erneuten CodeDLL XCP Generierung berückCANape sichtigen. Dass das Konzept funktioniert und l Bild 2. Neben der Entwicklung eines Regelalgorithmus, der mit aufgeht, zeigte sich konkreten Daten aus Steuergeräten, Bus- und Analogdaten etc. beispielsweise auch versorgt wird, deckt CANape noch andere Anwendungen ab, bei der Veranstaltung wie z.B. Online-Berechnungen während einer Messung. „King of Germany Elektronik automotive 4.2011 5/18

2010“, bei der ein Fahrzeug mit der Motorsteuerung der maf-map-engineering den ersten Platz in der Klasse der frontangetriebenen Fahrzeuge erreichte. Der Erfolg der Gesamtlösung hat inzwischen auch in anderen Branchen für Aufmerksamkeit gesorgt. So gibt es bereits Kontakte zu Wassersportlern, die sich für ihre schnellen Rennboote eine vergleichbare Lösung wünschen: eine optimal auf den Einsatzbereich zugeschnittene Motorsteuerung mit effizienten Mess- und Kalibriermöglichkeiten. sj

Der Kunde

Die Vorteile

HDM (HOERBIGER Drivetrain Mechatronics), ein Geschäfts-

Simulink-Modelle komfortabel und effizient visualisieren und

bereich des HOERBIGER Konzern, gilt in der Automobil-

parametrieren

industrie weltweit als Experte für Kupplungen, speziell bei

Die CANape Option Simulink XCP Server eignet sich ideal

der Entwicklung von Doppelkupplungssystemen für Sport-

für die Analyse des Modellverhaltens: > Durch die Verwendung des Standardprotokolls XCP kann

wagen, hochwertige Limousinen und Nutzfahrzeug-Applikationen.

Entwicklungsprozess verwendet werden. Unabhängig Die Herausforderung Komfortabler Test des Verhaltens von Simulink-Modellen Bei der Software-Entwicklung für die zweite Generation eines Doppelkupplungsgetriebes überführen die Ingenieure

gezeichnete Messdaten zur Laufzeit in das Modell als

den vorhandenen, manuell erzeugten C-Code in MATLAB/

Eingangsgrößen einspeisen. > Die Visualisierung der Messdaten und die Verstellung

Simulink-Modelle (Re-Engineering). Der Code wird automatisch aus den Modellen generiert und direkt in eine

von Parametern erfolgt leicht in den unterschiedlichen

AUTOSAR RTE integriert. Jedes Softwaremodul kann

CANape Fenstern. Eine objektspezifische Modell-

dabei in Simulink simuliert werden. Die vorhandenen Mög-

Instrumentierung ist nicht erforderlich. > Kalibrierdaten-Management mit dem CDM Studio

lichkeiten der Visualisierung mit Hilfe von MATLAB Scopes sind allerdings nicht ausreichend, um eine detaillierte

erlaubt das bequeme Bearbeiten und Verwalten von

Analyse der Daten vorzunehmen. Auch die Optimierung von

Parametersatzdateien im Modell: Kopieren und Zusam-

Parametern erfolgt zeitaufwändig und relativ unkomforta-

menführen von unterschiedlichen Parametersätzen,

bel über das Verändern von Werten im MATLAB Workspace

Herunterladen in das Simulink-Modell und Abspeichern

oder über das Erzeugen von spezifischen GUI-Elementen.

der Parameter in unterschiedlichen Formaten, wie z. B. im MATLAB-Format als M-Skript. > Simulationsergebnisse stehen im MDF-Format zur

CANape als Parametrier- und Visualisierungsoberfläche für

Verfügung. Dies erlaubt den direkten Vergleich mit

Simulink-Modelle und steuergeräte-interne Daten

Messdaten aus dem Fahrzeug und die manuelle bzw.

Mit Hilfe des Simulink XCP Servers lässt sich CANape auf

Dipl.-Ing. Andreas Patzer

davon, ob das Modell, eine Rapid-Prototyping-Plattform oder das Steuergerät angeschlossen ist. > Um das Modell realitätsnah zu testen, lassen sich auf-

Die Lösung

studierte an der Technischen Universität zu Karlsruhe Elektrotechnik. Schwerpunkte waren dabei Mess- und Regelungstechnik sowie Informations- und Automatisierungstechnik. 2003 wechselte er zur Vector Informatik GmbH nach Stuttgart, wo er sich als Business Development Manager in der Produktlinie Measurement & Calibration um die Schnittstelle zwischen Kunden, Entwicklung und Vertrieb kümmert. [email protected]

die gleiche CANape Konfiguration über den gesamten

einfachste Weise mit dem Modell in Simulink verbinden.

automatisierte Auswertung in CANape. > Die Lösung ist skalierbar: bei sehr rechenintensiven

Dabei stehen dem Anwender die gleichen Möglichkeiten zu

Simulationen lässt sich die Prozessorbelastung auf

Verfügung wie beim Anschluss an ein Steuergerät: Auswahl

2 Rechner verteilen.

per Drag & Drop von Mess- und Verstellgrößen aus der Beschreibungsdatei und Visualisierung in Anzeige- und Verstellfenstern. Die notwendige A2L-Beschreibungsdatei wird per Knopfdruck aus dem Simulink-Modell erzeugt und erlaubt den Lese- und Schreibzugriff auf die Größen im Modell, ohne dass eine zusätzliche Instrumentierung des Modells V2.0 | 2011-03

Entwicklung + Test

notwendig ist.

www.elektroniknet.de Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

5/19

TOOLS

TOOLS

Bild 1: Über einen in das Simulink-Modell integrierten XCP-Server und eine automatisch generierte A2L-Datei können Modellobjekte komfortabel und performant gemessen und verstellt werden.

Kommunikation via XCP on Ethernet

Analyse des Modellverhaltens bei der ECU-Funktionsentwicklung Bei der Funktionsentwicklung von Steuergeräten liegt der Schwerpunkt stets auf dem Finden der bestmöglichen Regelalgorithmen und Parameterkombinationen. Eine neue Lösung erlaubt jetzt den durchgängigen EINSATZ EINES MESS- UND KALIBRIERWERKZEUGS vom Modellentwurf bis zum Seriensteuergerät.

I

m Rahmen der modellbasierten Software-Entwicklung werden die Funktionen von Anwendungen in einem iterativen Prozess überprüft. Dazu läuft das Modell immer wieder in Simulink von The Mathworks ab. In Abhängigkeit von den Ergebnissen ergänzt der Entwickler die Anwendung durch Drag&Drop von Funktionsblöcken aus Bibliotheken heraus. Die Parametrierung der Blöcke erfolgt dabei entweder direkt im Funktionsblock als Zahlenwert

42 5/20

AUTOMOBIL-ELEKTRONIK � August 2009

oder über die Definition des Parameters und dessen Werts in der MATLAB-Konsole. Für die Änderung einer bestehenden Parametrierung müssen die gleichen Schritte durchlaufen werden: Aufsuchen eines Blocks im Modell und ändern des Wertes, Eingabe des Parameters und des neuen Wertes in der MATLAB-Konsole oder anpassen eines M-Skripts und anschließender Skriptablauf. Zur Visualisierung von Signalverläufen, die beim Ablauf des Mo-

dells in Simulink entstehen, instrumentiert der Anwender das verwendete Modell durch Grafikfenster-Blöcke, die er an das jeweils von im gewünschte Signal hängt. Durch den Einsatz des standardisierten Mess- und Kalibrierprotokolls XCP erhält der Entwickler eine wesentlich komfortablere Möglichkeit, die Parameter zu verwalten und die Signale aus dem Simulink-Modell heraus effizient und ohne Instrumentierung zu messen.

Das ASAM-Protokoll XCP (Universal Measurement and Calibration Protocol) hat sich als Lösung zum Messen und Verstellen von Anwendungen in Steuergeräten durchgesetzt. Dieser Ansatz ermöglicht Applikations-Ingenieuren über Standard-Bussysteme den komfortablen Zugriff auf Messdaten und Parameter im Steuergerät zur Laufzeit. Um auf steuergeräteinterne Größen zugreifen zu können, ist eine A2L-Steuergeräte-Beschreibungsdatei notwendig. Diese enthält alle Informationen über die relevanten Datenobjekte im Steuergerät wie Kenngrößen (Parameter, Kennlinien, Kennfelder) und Messgrößen. Auch die Zuordnung von Objektname und der Adresse im Speicher ist in der A2L hinterlegt. Die Mess- und Kalibriersoftware liest die A2L-Datei ein und verfügt damit über alle notwendigen Informationen, z. B. auf welchem Speicherplatz welche Größe zu finden ist. Im Steuergerät ist nur noch ein Protokolltreiber notwendig, der den Zugriff auf den Speicher zur Laufzeit des Steuergerätes erlaubt. Mit der Option „Simulink XCP Server“ für das Mess- und Kalibrierwerkzeug CANape von Vector wird ein XCP-Treiber in das Simulink-Modell integriert. Das Modell wird damit wie ein virtuelles Steuergerät behandelt. Der Aufwand zur Integration des XCP-Treibers ist minimal: per Drag&Drop wird ein einziger Block aus der Simulink-CANape-Bibliothek in das Modell eingefügt. Über den Konfigurationsdialog des Blocks erfolgen die Einstellungen der XCP-Transportschicht wie Hostname und Server-Port, die notwendig sind, weil zur Verbindung zwischen Mess- und Kalibrierwerkzeug und Simulink-Modell das „XCP on Ethernet“-Protokoll zum Einsatz kommt (Bild1).

Mit dieser Bedatung steht der XCP-Server grundlegend zur Verfügung. Die Generierung der A2L-Beschreibungsdatei des Modells erfolgt über den Blockdialog, wobei jedes Simulink-Objekt eine virtuelle Adresse erhält. Dadurch setzt der Simulink-XCP-Server die adressorientierte Arbeitsweise von XCP explizit auf die Simulink-Objekte um. Der Anwender wählt dann in CANape – wie gewohnt – die Objekte über den Namen aus. Die Adresse des Objektes wird aus der A2L-Datei herausgelesen und als Information an den XCP-Server im Modell gesendet. Damit hat die Adresse in der A2L-Datei weniger den Charakter einer echten Speicheradresse als vielmehr einer Identifikationsnummer. Um die Nutzung in CANape möglichst einfach und effizient zu gestalten, kann aus der Konfiguration des XCP-Simulink-Blocks in Simulink auch direkt ein CANape-Projekt generiert und CANape mit dem Projekt gestartet werden.

Beschleunigte Modelloptimierung

Der Anwender visualisiert unabhängig von der hierarchischen Gliederung und ohne eine weitere Instrumentierung des Modells die gewünschten Messgrößen im Mess- und Kalibrierwerkzeug CANape. Dabei lassen sich beliebige Ein- und Ausgangsgrößen von Modellblöcken anzeigen und deren zeitliche Verläufe in grafischer Form darstellen. Direkt aus der Visualisierung des Modells können die Parameter und Signale ebenfalls komfortabel angezeigt und verstellt werden (Bild2). Simulink-Anwender finden sich in der für sie gewohnten Modelldarstellung somit ohne Umstellung zurecht. Ein veränderter Parameter wird direkt über XCP an den XCP-Server im Modell weitergegeben. Dieser verstellt die Werte in

den Simulink-Blöcken und im Base- bzw. Modell-Workspace, was der manuellen Eingabe der Änderung über die MATLAB-Konsole entspricht. Parameter eines gesamten Simulink-Modells oder auch nur eines oder mehrerer Subsysteme verändert der Funktionsentwickler in CANape einfach und komfortabel. Damit lässt sich ein Simulink-Modell mit unterschiedlichen Parametersätzen testen und optimieren. CANape unterstützt dabei verschiedene Dateiformate. Hat das Modell den angestrebten Reifegrad erhalten, werden die dazugehörenden Parameter in einer Parametersatzdatei gespeichert. Um für das Gesamtmodell die optimale Einstellung zu erhalten, vergleicht der Anwender mit der Parametersatzverwaltung im CDM Studio (Calibration Data Management) von CANape die während der Modelloptimierung entstandenen einzelnen Versionen und führt die Teilparametersätze bzw. Arbeitpakete zusammen. Diese können in Form eines MATLABM-Skripts exportiert und somit als neuer Versionsstand in der MATLAB/SimulinkEntwicklungsumgebung direkt genutzt werden (Bild3).

MATLAB/Simulink als Zeitmaster

Simulink-Modelle laufen abhängig von ihrer Komplexität und der Rechnerleistung langsamer bzw. schneller als Echtzeit ab. Dies erfordert zwangsläufig eine Zeitstempelvorgabe von Simulink, das bei jedem Simulationsschritt den dazugehörenden Zeitstempel über XCP sendet, so dass auch die Varianz der für die Simulationsschritte benötigten Zeit keine Rolle mehr spielt. Jeder Simulationsschritt entspricht einer Zeiteinheit – unabhängig davon, wie viel reale Zeit dazu benötigt wird. AUTOMOBIL-ELEKTRONIK � August 2009

43 5/21

TOOLS

CANape über eine der vorhandenen Automatisierungsschnittstellen steuert. Zur Stimulation des Modells mit realen Daten lassen sich aufgezeichnete Testfahrten als Eingangsvektor zur Laufzeit in das Modell einspeisen. Der Funktionsentwickler analysiert und optimiert dabei das Systemverhalten unter vergleichbaren Randbedingungen. Eine reale, kostenintensive Testhardware ist dadurch vollkommen verzichtbar.

Rapid Control Prototyping bei der Fahrdynamik-Funktionsentwicklung Case Study

Fazit

Alle Bilder: Vector Informatik

Bild 2: Effiziente Analyse des Modellverhaltens durch komfortable Navi-gation und schneller Zugriff auf Objekte des Simulink-Modells in CANape.

In einem zweistündigen Live-Webinar erhalten die Leser der AUTOMOBILELEKTRONIK detaillierte Informationen über das Messen und Kalibrieren von Modellen in Simulink mit CANape. Im Rahmen der Präsentation zeigt Andreas Patzer – einer der Autoren – mit Expertentipps und Tool-Demonstrationen, wie sich Modellobjekte komfortabel und performant messen beziehungsweise verstellen lassen. Weitere Infos erhalten Sie per InfoDIRECT. Bild 3: Übersicht der Aktionen in CANape und deren Auswirkungen auf das Modell in Simulink

Somit fungiert Simulink als Zeitmaster und die vom Modell versendeten Messdaten können in CANape mit Simulationsgeschwindigkeit visualisiert werden. Je nach Komplexität des Modells können Sensordaten einer ein- oder zweistündigen realen Testfahrt in wenigen Sekunden oder Minuten durchgerechnet werden. Möchte man besonders große und komplexe Modelle simulieren, erlaubt die standardisierte Kommunikation mit

44 5/22

AUTOMOBIL-ELEKTRONIK � August 2009

XCP on Ethernet auch eine höhere Rechenleistung durch die Verwendung zweier getrennter Rechner. Die Analyse der Simulationsergebnisse kann nicht nur manuell durch einen Anwender erfolgen, sondern auch automatisiert. Eine Instanz überprüft dabei die erhaltenen Ergebnisse und trifft eine Parametrierentscheidung. Als Instanz dient entweder die CANape-Skriptsprache oder eine externe Software, die

Dipl.-Ing. (FH) André Ebner ist bei Vector Informatik Technical Team Leader in der Produktlinie „Measurement and Calibration“. Dipl.-Ing. Andreas Patzer arbeitet als Business Development Manager in der Produktlinie „Measurement and Calibration“ bei Vector Informatik. Dipl.-Inf. Wojciech Przystas ist bei Vector Informatik als Software Development Engineer in der Produktlinie „Measurement and Calibration“tätig.

infoDIRECT

www.all-electronics.de

Link zu Vector Informatik

337AEL0409

Erschienen in Automobil Elektronik, 8/2009

Die Herausforderung

> Sehr schnelles Generieren, Kompilieren und Linken des

Regelschleifen und Funktionen auf einer Echtzeit-Platt-

Codes aus den Funktionsalgorithmen. Als Ergebnis

form am realen System schnell validieren

stehen A2L-, DLL- und MAP-Dateien zur Verfügung, die

Aufgrund der zunehmenden Anzahl an Fahrwerksregelund

Fahrerassistenzsystemen sowie deren funktionaler

Wechselwirkungen erhöht sich die Komplexität im Systemverbund sowie der Abstimmungsbedarf. Das Validieren des

CANape direkt einliest. > Datensätze können von CANape in die MATLAB/ Simulink-Entwicklungsumgebung zurückgespeist werden. > Einfache Datenerfassung, -aufbereitung und -visualisie-

neuen Funktionsmodells soll bei der BMW Group deshalb

rung der relevanten Reglerparameter mit CANape.

bereits früh im Entwicklungsprozess am realen System

Komfortables Navigieren durch das Modell sowie direk-

erfolgen – ohne aufwändige Änderungen am Steuergerät. Die Lösung

ter Zugriff auf Parameter und Messwerte. > Kurze Reaktionszeit bei Anpassungen – ohne Programmieraufwand; Designfehler werden schnell gefunden.

Rapid Control Prototyping mit „Bypass/Fullpass“-Lösungen und einer echtzeitfähigen Hardware Um in frühen Entwicklungsphasen ohne vorhandene Steuergeräte-Hardware die Erprobung der Regelstrategie durchzuführen, benötigen die Ingenieure eine Rapid-Control-Prototyping-Plattform. Hier nutzt die BMW Group das VN8910 Netzwerk-Interface mit integriertem Echtzeitrechner anstelle eines Prototyping-Steuergeräts. Die Eingangsgrößen des Bypassmodells werden über die Mess- und Kalibrierhardware VX1131 aus dem Steuergerät gelesen, im VN8910 berechnet und ins Steuergerät zurückgesendet. Das „Bypass/Fullpass“-Modell wird hierbei aus MATLAB/Simulink heraus erstellt. Auch modellinterne Größen können dabei mit CANape gemessen und verstellt werden. Die Vorteile Schnelle, einfache und kostengünstige Erprobung unterschiedlicher Regelungs- und Steuerungsverfahren Die BMW Entwickler profitieren durch verbesserte und dynamische Testmöglichkeiten von einer höheren Funktionsqualität: > Mit CANape, dem VX1131 System und dem VN8910 verfügt BMW über eine durchgängige Werkzeugkette für den kompletten Entwicklungszyklus > Geringer Integrations-/Migrationsaufwand, da die selben Reglermodelle während der gesamten Entwicklung zum Einsatz kommen. > Mit dem CANape MATLAB Integration Package werden

V2.0 | 2014

Der realisierte Zugriff auf MATLAB/Simulink-Modelle in einem Mess- und Verstellwerkzeug über XCP bringt wesentliche Erleichterungen für Funktionsentwickler mit sich. So erfolgt die Instrumentierung des Modells automatisch über XCP und muss nicht mit hohem Aufwand manuell durchgeführt werden. Als universelles Front-End für Mess- und Verstellaufgaben erhöht CANape den Komfort in der Testphase der Modelle in Simulink. Durch die Nutzung von XCP als universelles Protokoll über den gesamten Entwicklungsprozess hinweg reduziert sich die Komplexität des gesamten Prozesses. Mit einem Protokoll, einer Beschreibungsdatei und einem Tool für alle Mess-, Verstell- und Stimulationsaufgaben vereinfacht und beschleunigt sich der Prozess der Funktionsentwicklung.

die Ein- und Ausgänge des Modells sehr leicht mit den realen Größen verknüpft. Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

5/23

30

l

eMOBILITY 1. 2 0 12

eMOBILITY 1. 2 0 12

Neue Messkonzepte für hohe Datenraten und kurze Messraster

Hochgeschwindigkeitsmessungen für Elektro-und Hybridfahrzeuge Speziell bei der Entwicklung von Elektro- und Hybridfahrzeugen sind die Anforderungen an die Messtechnik für steuergeräteinterne Signale sehr hoch.Mit der von Vector angebotenen Mess- und Kalibrier-Hardware VX1000 lassen sich für bestehende und zukünftige Mikrocontroller auch die für Elektroantriebe notwendigen Abtastraten von bis zu 100 kHz realisieren.

A

ntriebe von Elektro- oder Hybridfahrzeugen werden in der Regel mit PWM-Signalen angesteuert. Die PWM-Technologie hat den Vorteil, dass an den Leistungsschaltern sehr wenig Verluste entstehen, da diese in nur zwei Kennpunkten betrieben werden: voll durchgeschaltet oder voll sperrend. Die Frequenz der PMW-Signale liegt typischerweise bei 10 bis 20 kHz, in Ausnahmefällen bei bis zu 100 kHz. Mit dem in der Fahrzeugentwicklung weit verbreiteten, standardisierten Mess- und Kalibrierprotokoll XCP und der Kommunikation über die Bussysteme CAN oder FlexRay sind nur maximale Abtastraten von 1 kHz für interne Steuergerätesignale erreichbar. PWM-Signale lassen sich damit nicht erfassen. Daher kommen für den schnellen Zugriff auf Steuergerätegrößen die Debug- und Datentrace-Schnittstellen zum Einsatz, die sich je nach Typ des eingesetzten Mikrocontrollers wesentlich voneinander unterscheiden können.

5/24

Die Anbindung der Mess-Hardware ans Steuergerät erfolgt über einen „Plug-On Device“ (POD). Der Abstand zwischen den Debug-Pins des Mikrocontrollers und dem POD darf dabei maximal 10 cm betragen. Die Kommunikation zwischen Messtechnikmodul und dem Mess-PC erfolgt über XCP on Ethernet gemäß ASAM-Standard MCD-1 XCP. Für die physische Verbindung kommt ein standardmäßiges CAT-5-Ethernetkabel zum Einsatz. Grundsätzlich unterscheidet man zwei Messverfahren: das „RAM-Copy-Verfahren“ und das „Datentrace-Verfahren“. Diese werden mitsamt ihren Vor- und Nachteilen anhand der aktuellen sowie der in Kürze verfügbaren, neuen Mikrocontroller vorgestellt. Die verschiedenen Datentrace-Verfahren beziehen sich auf die beiden hauptsächlich in Antriebsstrang-Steuergeräten eingesetzten 32bit-Mikrocontroller und deren Nachfolger Freescale PowerPC (Schwerpunktmarkt USA) und Infineon TriCore (Schwerpunktmarkt Europa).

l 31

RAM-Copy-Verfahren Das RAM-Copy-Verfahren ist ein generisches Verfahren und kann für aktuelle und zukünftige 32-bit-MikrocontrollerGenerationen von verschiedenen Herstellern eingesetzt werden. Der Zugriff erfolgt beim Infineon TriCore oder XC2000 über das DAP-Interface (Device Access Port) und bei der PowerPCFamilie von Freescale oder den V850E2-Prozessoren von Renesas über die Schnittstelle Nexus Class 2+. Die ECUSoftware initiiert dazu eine RAMKopierfunktion entsprechend der Zykluszeit verschiedener ECU-Tasks. Bild 1: Datenflusskonzept für Messsignale über das RAM-Copy-Verfahren Die Messsignale müssen im Vorfeld und Nexus Class 2+ Schnittstelle. über XCP on Ethernet konfiguriert wer© automotive den. Das Mapping der Signalnamen und RAM-Adressen wird in einer A2LDatei (nach ASAM standardisierte Steuergeräte-BeschreiAbtastrate von 10 bis 20 kHz erfasst werden. Der Kopierbungsdatei für signalorientierte RAM-Zugriffe) beschrievorgang belastet die CPU dabei mit etwa 4% bei 1 ben. Ist das Kopieren aller Messsignale abgeschlossen, MByte/s. werden die Signale entsprechend den vorhandenen Debug-Schnittstellen an das Messdaten-Basismodul überDatentrace-Konzept für Nexus Class 3 tragen (Bild 1). Dieses Konzept wird als „Online Data Die meisten Derivate der aktuellen Freescale PowerPCAcquisition“ (OLDA, Online-Messdatenerfassung) Reihe unterstützen das Datentrace-Verfahren nach Nexus bezeichnet. Damit verbessert sich die Messdatenrate und Class 3. Dazu konfiguriert der Entwickler ein oder zwei die Abtastrate im Vergleich zu CAN um den Faktor 20, das Überwachungsfenster mit einer Gesamtgröße von maxiheißt es können 0,5 bis 1 MByte/s Messdaten mit einer mal 512 kByte im ECU-RAM. Jegliche Änderungen innerhalb dieser Überwachungsfenster werden ohne zusätzliche CPU-Last über Nexus Class 3 an den POD übertragen. Die Übertragungsrate für Rohdaten über das High-Speed -Serial-LinkKabel kann bis zu 100 MByte/s betragen. Der Vorteil dieses Konzepts liegt darin, dass es im Messdaten-Basismodul stets ein konsistentes, gespiegeltes RAM des Steuergeräte-RAMs gibt. Ein ECU-Software-Trigger Bild 2: Datenflusskonzept der Messsignale über das Datentrace-Konzept und Nexus-Class-3unterbricht den Datenfluss Schnittstelle. innerhalb des Messdaten© automotive Basismoduls, wobei neue Änderungen im RAM in einem FIFO-Puffer gespeichert werden. Durch einen von bis zu 256 verschiedenen Software-Triggern wird die Messung ausgelöst und der Inhalt des gespiegelten RAM „eingefroren“. Entsprechend der Messkonfiguration werden die Signale aus dem gespiegelten RAM im Messdaten-Basismodul ausgeBild 3: Fine Grain Filter reduzieren beim Datentrace-Konzept über die DAP2-Schnittstelle den lesen und über XCP on Ethernet Rohdatenstrom auf 15 MByte/s. (Alle Bilder: Vector Informatik GmbH) © automotive an das Messwerkzeug gesendet (Bild 2). Die Vorteile der 5/25

l

eMOBILITY 1. 2 0 12

Nexus-Class-3-Lösung sind: ■ Die maximale Messdatenrate ist mit 30 MByte/s nochmals um den Faktor 30 größer als bei Nexus Class 2+ und 600-mal größer als bei XCP on CAN. ■ Die CPU wird typischerweise durch die Messung nicht belastet. ■ Alle PWM-Ansteuersignale lassen sich problemlos mit 10 kHz Abtastrate messen. Der Nachteil dieser Lösung liegt in der Tatsache, dass der POD mit 25 Pins aufwendig an den Mikrocontroller angebunden ist und er einen sehr großen Rohdatenstrom von 100 MByte/s verarbeiten muss. Datentrace-Konzept für Mikrocontroller der nächsten Generation Der Hauptnachteil der Nexus-Class-3-Lösung entfällt bei Mikrocontrollern der nächsten Generation, in dem die PinAnzahl von 25 auf fünf reduziert wurde. Die Messdatenrate und die Abtastrate bleiben aber unverändert hoch. Diese Datentrace-Lösung wird von zukünftigen Prozessoren von Infineon und Freescale in gleicher Weise unterstützt. Der Rohdatenstrom von 100 MByte/s muss dabei weiterhin verarbeitet werden. Infineon TriCore Ein mit Nexus Class 3 vergleichbares Konzept kann auch für DAP eingesetzt werden. Dazu ist ein 256 kByte großer Bereich des ED-RAM (Emulation Device RAM) für die Messdatenerfassung zu reservieren. Die Trace-Übertragungsrate für Rohdaten muss im Gegensatz zu den 100 MByte/s des Nexus-Class-3-Konzepts auf 5 MByte/s Mit den neuesten Mikrocon- begrenzt werden, dafür sind nur vier Pins ansteltroller-Generationen sowie le 25 Pins ausreichend. einer intelligenten MessEs können maximal vier RAM-Überwachungstechniklösung lassen sich fenster konfiguriert Messdatenraten von bis zu werden. Diese sind so zu konfigurieren, dass 30 MByte/s und die notes zu keinem Überlauf wendigen Abtastraten von der Trace-Daten kommt. Dadurch lassen 100 kHz erzielen. sich in der Regel nur 10 bis 20 kByte Speicher anstelle 512 kByte überwachen und darin liegende Signale ohne Prozessorbelastung messen. Signale außerhalb dieser trace-überwachten Speicherbereiche können mit dem RAMCopy-Verfahren gemessen werden. Die Vorteile der Infineon DAP Datentrace-Lösung sind: ■ Die maximale Messdatenrate ist mit 3 Mbyte/s um den Faktor 3 größer als beim RAM-Copy-Verfahren. ■ Der Mikrocontroller wird durch die Messung nicht belastet. ■ Alle bekannten PWM-Ansteuersignale können problemlos mit 100 kHz Abtastrate gemessen werden.

“

“

5/26

Datentrace-Konzept für zukünftige Infineon-Controller Mit der nächsten Mikrocontroller-Generation stellt Infineon auch einen Device Access Port (DAP) der neuesten Generation bereit. Ein Vorteil liegt in der höheren Rohdatenübertragungsrate von nun 20 MByte/s gegenüber den bisherigen 5 MByte/s. Erreicht wird dies durch die höhere Frequenz auf der DAP-Verbindung von 160 MHz anstatt der bisherigen 80 MHz sowie durch ein neuartiges Dreileitungs-Konzept, das eine parallele Übertragung auf zwei Leitungen ermöglicht. Die größte Verbesserung der DAP2-Schnittstelle liegt in der Möglichkeit, hardware-basierte Daten-Trace-Filter mit äußerst feiner Granularität einzurichten. Dadurch wird die Übertragung von unnötigen Datentrace-Informationen vom Mikrocontroller zum POD deutlich reduziert. Trotz der maximalen Messdatenrate von 10 MByte/s müssen nur 15 statt 100 MByte/s Rohdaten verarbeitet werden (Bild 3). Aufgrund der deutlich gesunkenen Anforderungen an die Verarbeitung der Messdaten kann eine entsprechend kostenoptimierte Messtechnik für DAP2 zum Einsatz kommen. Zusammenfassung In modernen Antriebskonzepten für Fahrzeuge mit reinen beziehungsweise hybriden Elektromotoren sind oftmals neue Strategien für die Messdatenerfassung erforderlich. Bestehende Messtechnikkonzepte für steuergeräteinterne Signale kommen oftmals hinsichtlich Datenrate oder Abtastrate an ihre Grenzen. Mit der von Vector angebotenen VX1000 Mess- und Kalibrier-Hardware lassen sich für bestehende und zukünftige Mikrocontroller auch die für Elektroantriebe notwendigen Abtastraten von bis zu 100 kHz realisieren. Im Laufe diesen Jahres stehen von Freescale und Infineon neue Controller-Generationen mit DatentraceSchnittstelle zur Verfügung, die mit deutlich weniger Anschlusspins auskommen und in Kombination mit dem von Vector im zweiten Halbjahr 2012 angebotenen Hochgeschwindigkeitsmessmodul VX1131 Messdatenraten von 30 MByte/s ohne CPU-Belastung ermöglichen. Aufgrund der PC-Anbindung über den ASAM-Standard XCP on Ethernet eignet sich die Mess- und Kalibrier-Hardware ebenfalls als flexible und leistungsstarke Bypass-Lösung mit kurzen Latenzzeiten. (oe)

Quantensprung in der Mikrocontroller-Messtechnik Case Study

Der Kunde

Die Vorteile

Die Bosch-Gruppe ist ein international führendes Techno-

Höchste Messdatenrate von 5 MB/s bei einer minimalen

logie- und Dienstleistungsunternehmen. Innovationen von

CPU-Belastung von Höchste Leistungsfähigkeit bei Mess- und Kalibrier-

entwickeln und prüfen Ingenieure in Forschungszentren Produktinnovationen für die Automobilbranche.

aufgaben mit einer Messdatenrate von bis zu 5MB/s und

Die Herausforderung

einer Schreibrate von 1 MB/s > Minimale CPU-Belastung bei der Messung

Höchste Übertragungsraten bei gleichzeitig geringen Latenz-

> Sehr kurze Messraster von 50 Mikrosekunden sind

zeiten

konfigurierbar. > Die Genauigkeit der Zeitstempel liegt bei 1 Mikrosekunde,

Die bisherigen Methoden zum Messen, Kalibrieren, Flashen und Bypassing stießen bei der Entwicklung eines neuen Fernbereichsradarsensors hinsichtlich des benötigten Datendurchsatzes an ihre Grenzen. Bei der Robert Bosch GmbH machte man sich auf die Suche nach einem leistungsfähi-

während Bypass-Turnaround-Zeiten von 300 Mikrosekunden erreicht werden. > Der POD und das HSSL-Kabel erfüllen die mechanischen und elektronischen Umweltanforderungen für den

für die nächsten Steuergerätegenerationen. Zum fehler-

Verbau im Motorraum. > Durch den modularen Aufbau des Systems ist die Wieder-

freien Erfassen von bis zu 100.000 Messsignalen war eine

verwendung bei Nachfolgeprojekten, auch beim Einsatz

geren und insbesondere auch zukunftsfähigen Messkonzept

Datenrate von mindestens 4 MB/s bei möglichst geringer Prozessorbeeinflussung erforderlich.

anderer Mikrocontroller, kostengünstig gewährleistet. > Flexibilität und Investitionssicherheit ergibt sich durch den Einsatz des standardisierten XCP on Ethernet-

Die Lösung

Protokolls. Damit können neben CANape auch andere

Hochperformantes Mess- und Kalibriersystem mit einem

MCD-Tools eingesetzt werden.

Data Trace Interface als Messschnittstelle Der Grundgedanke der VX1000 Lösung basiert darauf, die Daten vom Steuergerät über die Debug-Schnittstelle des Mikrocontrollers zu erfassen und an einen externen Messadapter mit Hilfe eines speziellen Hochgeschwindigkeitskabels weiterzuleiten. Von dem externen Messadapter lassen

Dipl.-Ing. (FH) Alfred Kless arbeitet bei Vector Informatik in Stuttgart als Business Development Manager für die Produktlinien „Measurement & Calibration“ sowie „Network Interfaces“.

sich die eigentlichen Messdaten unabhängig vom Steuergerät über das standardisierte Protokoll XCP on Ethernet zur Anwendung auf den PC übertragen. Der direkt an das Steuergerät angeschlossene Plug-on-Device (POD) ist besonders kompakt und widerstandsfähig.

@

V2.0 | 2009-11

32

Vector Informatik www.vector.com

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

5/27

der Applikation die gemessenen Zustände eingenommen

blen und der komfortablen Konfiguration über eine A2L-­

wurden. Weiterhin ist es nötig, Wirkketten über Modulgren-

Datei ist XCP ein leistungsstarkes Protokoll für die Fehler-

zen hinweg zu beobachten, um z. B. einen Signalpfad vom

suche.

Empfang eines Bussignals bis hin zur Applikation zu verfol-

Die Umsetzung des XCP-Protokolls erfolgt in einem eige-

gen. Außerdem sind Zeitstempel notwendig, um bei der

nen BSW-Modul, das aber nicht im AUTOSAR 3.x-Standard

Analyse die Fehlerhistorie zu rekonstruieren.

definiert ist. Dieses wird – je nach verwendetem Bussystem (CAN, FlexRay, Ethernet, etc.) – an den entsprechenden

Einsatz von XCP in AUTOSAR 3.x-Projekten

AUTOSAR-Kommunikations-Treiber angebunden (Bild 1).

Im AUTOSAR 3.x-Standard sind für das Echtzeit-Debug-

Um eine komfortable Konfiguration von XCP und der übri-

ging keine Mechanismen spezifiziert. Seit Jahren ist jedoch

gen Module zu erhalten, wird der XCP-Treiber nahtlos in die

das „Universal Measurement and Calibration Protocol“ (XCP)

bestehende BSW-Konfigurationskette eingefügt.

in der Fahrzeug­entwicklung erfolgreich für das Messen und

AUTOSAR-Steuergeräte-Software mit XCP analysieren Komfortable Fehlersuche durch Erweiterung der AUTOSAR-Basissoftware Bei der Fehlersuche im Steuer­geräte­verbund ist der Einsatz von Debuggern oft nur eingeschränkt möglich, vor allem wenn Fehler nur sporadisch oder im Testfahrzeug auftreten. Das bewährte Mess- und Kalibrierprotokoll XCP leistet in diesen Fällen nützliche Dienste. Nachfolgend wird beschrieben, wie mit XCP Abläufe in der AUTOSAR-Basissoftware (BSW) und den Softwarekomponenten (SWCs) verfolgt werden können. Die Basissoftware muss für diese Messzwecke um bestimmte Eigen­schaften ergänzt werden. Für eine effiziente Fehlersuche und einfache Auswertung benötigt der

Kalibrie­ ren von Steuergeräten im Einsatz und deckt die

Erstellen einer A2L-Datei

oben genannten Anforderungen sehr gut ab. XCP stellt

Das Erstellen der A2L-Datei mit den oben genannten hilf-

­Mechanismen zum Lesen und Schreiben von Variablen über

reichen Zusatzinformationen ist eine Herausforderung. Da-

Bussysteme zur Verfügung. Anhand von DAQ-Listen (Data

für benötigt der Testingenieur einen definierten Prozess

Acquisition) können mehrere Variablen konsistent und mit

und geeignete Werkzeuge. Aufgrund der vielfältigen Konfi-

einem gemeinsamen Zeitstempel gemessen werden. Dyna-

gurationsmöglichkeiten der AUTOSAR BSW ist es von Vor-

mische DAQ-Listen ermöglichen das Umkonfigurieren der

teil die A2L-Datei zu generieren. Bei der Erzeugung werden

auszulesenden Datensätze während der Messung. Somit

Änderungen der BSW-Konfiguration in die A2L-Datei um-

wird die zur Verfügung stehende Bandbreite des Kommuni-

gesetzt.

kationsbusses optimal aus­genutzt.

Die für das Messen der Datenflüsse zwischen Software­

Für das Messen über XCP wurde das A2L-Datenformat

komponenten (SWC) benötigte A2L-Datei erzeugt der

spezifiziert. Eine A2L-Datei beinhaltet Informationen über

RTE-Generator von Vector (Bild 2). Damit ist es möglich die

die relevanten Messobjekte im Steuergerät. Für jedes die-

Intra- und Inter-ECU-Kommunikation zu verfolgen sowie

ser Objekte wer­den Informationen, wie Speicheradresse,

nicht verbundene Sender/Receiver-Ports zu messen und zu

Datentyp, symbolische Interpretation und Umrechnungsvor-

stimulieren. Basierend auf der mit dem DaVinci Developer

schriften benötigt. Darüber hinaus be­inhaltet eine A2L-Datei

erstellten RTE-Konfiguration erfolgt das Generieren der

neben der Beschreibung der Parameter für die Kommuni-

A2L-Datei. Zusätzlich fügt der RTE-Generator auch not-

kation zwischen dem XCP-Master (z. B. Analyse-Werkzeug)

wendige Änderungen für die Messung in den RTE-Code ein.

und dem XCP-Slave (Steuergerät) auch eine hierarchisch

Um auch den Datenfluss in den Modulen unterhalb der RTE

strukturierte Darstellung der Messobjekte. Mit den vielfäl-

zu verfolgen, stellt Vector ebenso einen A2L-Generator für

tigen Zugriffsmöglichkeiten auf steuergeräteinterne Varia-

die Messgrößen in der Basissoftware zur Verfügung (Bild 2).

Testingenieur auch spezielle Erweiterungen der Analyse­werkzeuge.

Eine große Anzahl der heute verfügbaren Testwerkzeuge

Neben den eingeschränkten physikalischen Gegebenheiten

unterstützt das Testen einzelner Steuergeräte mithilfe

für eine Fehlersuche im Fahrzeug, kommt noch ein weiterer

einer Restbus­ ­ simulation. Damit werden die geforderten

Faktor hinzu: Einige Fehler treten nur sporadisch auf. Die

Funktionen unabhängig vom Steuergeräteverbund frühzei-

Ursachenforschung bei sporadischen Fehlern ist auch im

tig verifiziert. Die Software er­reicht so bereits eine sehr

Labor nicht immer einfach.

hohe Qualitätsstufe. Sobald ein Steuergerät im Brettaufbau oder im Testfahrzeug verbaut wird, bzw. die Funktion

Anforderungen an die Fehlersuche

sich über einen Verbund mehrerer Steuergeräte erstreckt,

Um die Ursache eines Fehlers zu finden, werden typischer-

reduzieren sich die Testmöglichkeiten erheblich. Auftreten-

weise die Werte verschiedener Variablen der Software ge-

de Fehler können nun nicht mehr so leicht eingegrenzt wer-

prüft. Ebenso ist es wichtig, auch die Variablen mehrerer

den. Die Ursachen dafür sind: >>Ein Steuergerät ist schwer zugänglich verbaut.

Softwaremodule zeitgleich zu einem Triggerpunkt zu prü-

>>Es sind keine Anschlüsse für das Debugging mehr verfügbar.

bedingungen überwachen. Beispiele dafür sind vor allem

>>Die Debugger für die verschiedenen Steuergeräte

„Managermodule“, deren Zustandsmaschinen voneinander

bereiten die Daten nicht einheitlich auf. >>Die Testwerkzeuge können nicht im Fahrzeug unterge-

abhängen, z. B. die AUTOSAR „Bus State Manager“ und der

bracht werden.

6/0 2

fen. Dadurch lassen sich modulüber­greifende Konsistenz-

„Communication Manager“ (ComM). Ebenso muss der Testingenieur prüfen, aufgrund welcher Anforderungen aus

Bild 1: MICROSAR – die ­AUTOSAR-Basissoftware von Vector – enthält Module für das Messen von ­steuergeräteinternen Daten mittels XCP

6/1

AUTOSAR-Steuergeräte-Software mit XCP analysieren

Bild 2: Generierung der A2L-Dateien, ­basierend auf der Steuergeräte­ konfiguration

Debugging in AUTOSAR 4.x-Projekten

und Datenfenster auch für die über XCP gemessenen

Der AUTOSAR 4.x-Standard wird der Anforderung an Debug-­

­Variablen zur Verfügung. Ebenso kann der Zugriff auf die

Möglichkeiten in der Software durch die Module DBG

XCP-Variablen aus der integrierten Programmiersprache

­(Debug) und DLT (Diagnostic Log and Trace) gerecht. Die-

CAPL oder der Testautomatisierung erfolgen und ermög-

se zwei Module nutzen ähnliche Mechanismen, wie sie XCP

licht so eine automatisierte Analyse.

zur Verfügung stellt. Die Haupt­aufgabe des DBG-Moduls

Die Analyse der aufgenommenen Messwerte aus dem

ist das Lesen von Daten im Steuergerät, die zwischenge-

Steuer­gerät kann direkt während der Messung erfolgen.

puffert und an einen PC zum weiteren Auswerten durch

Hierzu muss der XCP-Master entsprechende Mechanismen

den Entwickler geschickt werden. Die Kommunikation zum

bieten. Im Fall von CANoe sind das zum einen definierbare

PC erfolgt über ein eigenes Kommunikationsprotokoll. Ähn-

Triggerbedingungen im State Tracker-Fenster, wie z. B. das

lich zur A2L-Datei bei XCP wird beim DBG-Ansatz eine Be-

Einfrieren des Fensterinhalts beim Erreichen eines be-

schreibung der zu messenden Daten erzeugt. Dies ge-

stimmten Messwertes für eine schnelle Analyse. Zum ande-

schieht auf Basis der Modul­beschreibung aller zu messen-

ren ermöglicht CANoe komplexe Auswertungen der Mess-

den BSW-Module.

werte über ein CAPL-Programm.

Das DLT-Modul hat die Aufgabe, Fehlermeldungen und

Das Generieren der A2L-Datei erfolgt ebenfalls auf Basis

ten-Logger mit integrierter XCP-Funktionalität oder Soft-

Sollen gespeicherte Messwerte detailliert untersucht wer-

Warnungen, die zur Laufzeit erzeugt werden, an einen PC

der Konfiguration. Die Messobjekte werden in der A2L-Datei

warewerkzeuge mit einem XCP-Master über längere Zeit-

den, ist eine symbolische Darstellung der Werte für den

weiterzuleiten. Diese Meldungen werden von den BSW-Mo-

in einer Ordnerstruktur hierarchisch abgelegt, um das Auf-

räume Messwerte im Fahrzeug. Bei der anschließenden

Entwickler einfacher zu handhaben, als mit den Rohwerten

dulen DET (Development Error Trace), DEM (Development

finden zu erleichtern.

Analyse der Daten kommen wieder XCP-Master-Werkzeu-

zu arbeiten. Hierzu muss die A2L-Datei eine Zuordnung der

Event Manager) und von den Softwarekomponenten der

ge wie z. B. das weit verbreitete Simulations-, Analyse- und

Rohwerte zu symbolischen Bezeichnern enthalten – ähnlich

Applikation erzeugt. DLT hat ebenfalls ein eigenes Kommu-

Testwerkzeug CANoe von Vector zum Einsatz.

zu den aus der Programmier­sprache C bekannten Enums.

nikationsprotokoll, das nicht XCP-kompatibel ist. Die Funk-

Die Anzeige der symbolischen Werte übernimmt CANoe.

tionen der beiden Module DBG und DLT können aber auch

Messdaten erfassen Oft kann der Testingenieur anhand des Fehlerbildes bereits die für den Fehler verantwortlichen Module einschränken

Messdaten analysieren

Diese Art der Darstellung eignet sich hervorragend zum

mit XCP umgesetzt werden. Vector bietet dies bereits in

und die zur Analyse auszulesenden Daten definieren. Zu-

Um Steuergeräte unabhängig vom verwendeten Kommu-

Beobachten von Zustandsautomaten, deren Zustände oft

seiner AUTOSAR 3.x-Lösung an (Bild 1).

nächst wird mit dem XCP-Master eine Verbindung zum

nikationsbus zu testen, muss der XCP-Master unterschied-

über Enums im Code dargestellt werden. Das Verfahren

XCP-Slave aufgebaut. Direkt im Anschluss an den Verbin-

liche Bussysteme wie CAN, FlexRay oder Ethernet unter-

lässt sich auf jede beliebige Variable übertragen, z. B. um

Hochperformanter Zugriff auf Messdaten

dungsaufbau können erste Daten aus dem Steuergerät

stützen. Darüber hinaus kann es bei der Fehlersuche not-

symbolisch darzustellen, ob sie gerade mit einem Ersatz-

Mit den beschriebenen Mechanismen steht für jedes

ausgelesen werden. Das sind in der Regel Informationen

wendig sein, Daten mehrerer Steuer­ geräte parallel zu

oder Initialisierungswert geladen ist.

Steuer­gerät – unabhängig von der AUTOSAR-Version – ein

wie Versionsnummern, Variantenkennungen, usw. Anhand

messen und auszuwerten. Daher ist es vorteilhaft, wenn

dieser Information wählt der Testingenieur die zum Versions­

das Analysewerkzeug auch multi-master-fähig ist.

stand des Steuergerätes passende A2L-Datei aus und star-

CANoe wird mit der Option AMD (AUTOSAR Monitoring

tet die Messung der Daten.

and Debugging) um die Funktionalität eines XCP-Masters

Bei schwer zu reproduzierenden Fehlern ist eine schnelle

erweitert, um dynamisch mehrere Slaves anzusprechen.

Analyse der Daten während der laufenden Messung unter

Damit kann der Anwender die XCP-Konfiguration während

Umständen nicht möglich. In diesen Fällen speichern Da-

einer laufenden Messung ändern. Mit der Option AMD ste-

Bild 3: Das CANoe State Tracker Fenster bietet eine komfor­ table Visualisierung von steuergeräte-­ internen Daten, die mit XCP erfasst wurden.

6/2

hen die Analysefenster State Tracker (Bild 3), Grafikfenster

Bild 4: Mit der VX1000 Mess- und Kalibrierhardware von Vector lassen sich große Datenmengen erfassen, bei ­minimaler Beeinflussung der Steuergeräte-Laufzeit.

6/3

mächtiges Debug-Werkzeug zur Verfügung. Der Entwickler

XCP-Slave allerdings einen Puffer zur Verfügung stellen,

verfolgt und analysiert mit den bewährten XCP-Werkzeu-

der die Messdaten aufnimmt, bis die Kommunikation

gen wie z. B. CANoe und CANape von Vector komfortabel

zum XCP-Master wiederhergestellt wurde. Aufgrund der

Abläufe im Steuergerät. Für das Messen großer Daten-

im Steuergerät knappen Ressourcen ist ein dauerhaftes

mengen mit bis zu 5 MByte/s bei minimaler Laufzeit­

Puffern verständlicherweise nicht möglich. Hier sind

beeinflussung des Steuergeräts, bietet sich der Einsatz der

zwei Pufferstrategien denkbar. Zum einen ein linearer

VX1000 Mess- und Kalibrierhardware (Bild 4) an. Der Zu-

Puffer, der Messwerte nur aufnimmt, bis er voll ist. Die

gang zum Steuergerät erfolgt hierbei über die Debug-­

andere Variante ist ein Ringpuffer, bei dem die ältesten

Schnittstellen JTAG oder NEXUS.

Einträge mit neuen Werten überschrieben werden.

Entwicklung einer Treiberbibliothek für Motorsteuerungen mit AUTOSAR Complex Device Driver (CDD) Case Study FAW

Bevor eine Messung über XCP-Events erfolgen kann, Wie funktioniert XCP?

muss der XCP-Master den Slave-Treiber entsprechend

Bereits seit Jahren ist das Universal Measurement and

konfigurieren. Dies geschieht durch eine Reihe von Kom-

Calibration Protocol (XCP) in der Fahrzeugentwicklung

mandos. Dazu verbindet sich der XCP-Master mit dem

erfolgreich für das Messen und Kalibrieren von Steuer-

XCP-Slave und überträgt die notwendige Konfigura­

geräten im Einsatz. XCP ist ein weltweiter Standard

tion. Soll die Messung jedoch unmittelbar nach der Ini­

und wurde von der Association for Standardization of

tia­lisierung des Steuergerätes starten, muss die Mess­

Automation and Measuring Systems (ASAM) im Jahr

kon­fi­gura­tion im nicht-flüchtigen Speicher des Steuer-

2003 standardisiert. Während das CAN Calibration

geräts abgelegt sein. Dieser sogenannte Resume Mode

Protocol (CCP) auf den CAN-Bus beschränkt ist, er-

erlaubt Messungen unmittelbar nach dem Start des

laubt XCP den Austausch der Transportschicht. Es

Steuergerätes.

­unterstützt z. B. CAN, FlexRay, Ethernet, USB, etc. und basiert auf einem Master/Slave-Prinzip. Der XCP-­

Die englische Originalversion wurde veröffentlicht in der

Master sendet über ein Command Transfer Object

Sonderausgabe der Hanser automotive im November 2011.

(CTO) Kommandos über den Bus an den XCP-Slave, Alle Bilder:

(DTO) antwortet. Mit XCP lassen sich Werte im Spei-

Vector Informatik GmbH

cher des Steuergerätes lesen und schreiben. Slave an (Polling) oder lässt sich die Daten beim Auftre-

Dipl.-Ing. (FH) Patrick Markl ist Teamleiter für die Konzeptentwicklung in der Produktlinie „Embedded Software“ bei Vector.

ten bestimmter Ereignisse zuschicken (XCP-Events). mehreren Faktoren ab: Beim Messen mit XCP-Events Allerdings ist es notwendig den Steuergerätecode entsprechend anzupassen, um die XCP-Events auszulösen, was beim Polling nicht notwendig ist. Ebenso können XCP-Events bereits während der Entwicklung im Code der Applikation an bestimmten Stellen vorgesehen werden. Abgesehen von einem geringen Laufzeit-Overhead verhält sich der XCP-Code passiv. Werden die XCPEvents für das Messen benötigt, aktiviert der XCP-Master sie während der Messung. Ein weiterer Vorteil der XCP-Events ist die ereignisgesteuerte Ausgabe mehrerer Daten mit einem gemeinsamen Zeitstempel. Dadurch vollzieht der Entwickler bestimmte Vorgänge in der Software exakt nach und prüft, ob Variablen zueinander konsistent sind. Mit XCP-Events kann der Testingenieur Messungen unabhängig vom Zustand des Kommunikationsbusses durchführen. Während beim Polling die Messkom-

Eine durch FAW erweiterbare domänenspezifische Treiber-

mit Sitz in Changchun ist der größte chinesische Hersteller

bibliothek. > Konfiguration und Generierung der gesamten Basissoft-

von Dieselmotoren, PKWs, sowie mittleren bis schweren Bussen und LKWs. FAW produziert mehr als 2,5 Millionen

ware mit einem Werkzeug: Sowohl die AUTOSAR-

Fahrzeuge pro Jahr und gehört zu den ersten chinesischen

Standardmodule als auch die speziellen Treiber für die

OEMs, die AUTOSAR einsetzen.

Motorsteuerung werden mit dem DaVinci Configurator

Die Herausforderung

Dipl.-Ing. (FH) Stefan Albrecht ist Senior Product Management Engineer für die ­­ CANoe/CANalyzer Option AMD.

Pro konfiguriert. > Die Treiberbibliothek kann mit dem DaVinci Configurator

Entwicklung einer Treiberbibliothek für Motorsteuerungen

Kit erweitert oder angepasst werden, z. B. wenn neue

mit AUTOSAR Complex Device Driver (CDD).

Sensoren oder Aktuatoren eingeführt werden. > Reduzierter Verwaltungsaufwand durch Pflege und

gen und setzt dabei konsequent AUTOSAR-Basissoftware

Erweiterung der Bibliothek in einer zentralen Abteilung.

ein. Die Software wird als eine einzige Plattform realisiert,

Die verschiedenen Fahrzeugprojekte haben Zugriff auf

mit der sich sowohl Benzin- als auch Dieselmotoren steuern

die zentrale Bibliothek und konfigurieren sie mit dem

lassen. Da in AUTOSAR keine entsprechenden Treiber für

DaVinci Configurator Pro entsprechend ihrer spezifischen

Motorsteuerungen definiert sind, möchte FAW die benö-

Motorsteuerung.

tigten Sensoren und Aktuatoren aus einer erweiterten

Welcher Mechanismus zum Einsatz kommt, hängt von wird die Busbandbreite besser genutzt als beim Polling.

Die Vorteile

Die FAW Group Cooperation, die „First Automotive Works“,

FAW entwickelt eine neue Generation ihrer Motorsteuerun-

worauf der XCP-Slave über ein Data Transfer Object

Der XCP-Master fordert Messdaten zyklisch beim XCP-­

Der Kunde

> Der in AUTOSAR vorgegebene Prozess und die Schnitt-

AUTOSAR-Treiberbibliotek auswählen und in der gewünsch-

stellen werden eingehalten: Die Regelalgorithmen für die

ten Anzahl und Ausprägung mit Hilfe einer durchgängigen

Motorsteuerung werden weiterhin mit Matlab und

Werkzeugkette konfigurieren.

Simulink entwickelt und als AUTOSAR-Softwarekomponenten (SWC) realisiert. Diese sind über die RTE mit der

Die Lösung

AUTOSAR-Basissoftware und den motorspezifischen

Konfiguration und Code-Generierung der motorspezifischen

Treibern verbunden.

Treiber mit der vorhandenen AUTOSAR-Werkzeugkette von Vector. Die Treiber zur Ansteuerung der motorspezifischen Sensorik und Aktuatorik wurden von Vector als sogenannte Complex Device Driver (CDD) realisiert. Für die Konfiguration der Treiber wurden entsprechende Basissoftware Module Description (BSWMD) Dateien mit Hilfe des DaVinci Configurator Kit erzeugt. Ebenso wurden die Code-Generatoren mit dem DaVinci Configurator Kit erstellt. Der DaVinci Configurator Pro liest die BSWMD-Dateien und bindet die zugehörigen Code Generatoren ein. Damit kann er die Treiber für die Motorsteuerung und die AUTOSARBasissoftware konfigurieren.

mandos vom Master empfangen werden und somit die V2.0 | 2011-05

Buskommunikation zwingend erforderlich ist, kann dies bei einer Event-Messung entfallen. Dafür muss der

6/4

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

6/5

E n tw i c kl u n g S o F t wA r E

Autor Autor

alExandEr ZEEb, m.Sc. alExandEr ZEEb, m.Sc. ist Software-Entwicklungsingenieur ist Software-Entwicklungsingenieur im Bereich Konzeptentwicklung für im Bereich für Embedded SoftwareKonzeptentwicklung bei der Vector Embedded Software bei der Vector Informatik GmbH in Stuttgart. Informatik GmbH in Stuttgart.

StEuErgErätE-SoftwarE StEuErgErätE-SoftwarE

Die Autosar-Steuergeräte-Software ist in drei Bereiche unterteilt: Die Autosar-Steuergeräte-Software ist in drei Bereiche ❶.unterteilt: Basis-Software, Runtime Environment und Applikation, Die ❶. Die Basis-Software, Runtime Environment und Applikation, Basis-Software (BSW) ist das Grundgerüst, das der Applikation Basis-Software (BSW) ist das Grundgerüst, das der Applikation mittels Treibern und Abstraktionsschichten die Ressourcen des mittels Treibern und Abstraktionsschichten die Environment Ressourcen des Mikrocontrollers zur Verfügung stellt. Das Runtime Mikrocontrollers zur Verfügung stellt. Das Runtime Environment (RTE) dient als Verbindungsschicht zwischen der Applikation (RTE) dient als Verbindungsschicht zwischen der Applikation und der Basis-Software. Die RTE abstrahiert die Kommunikation und Applikationsteilen der Basis-Software. und Die RTE abstrahiert die Kommunikation zwischen ermöglicht so transparenten zwischen Applikationsteilen und ermöglicht so transparenten Datenaustausch auch über Steuergerätegrenzen hinaus. Zu dieDatenaustausch auch über Steuergerätegrenzen hinaus.und Zu diesem Zweck stellt die RTE-Schnittstellen für die Applikation sem Zweck stellt die RTE-Schnittstellen für die Applikation und die Basis-Software bereit. Im Gegensatz zur BSW, deren statische die Basis-Software bereit. Im Gegensatz zur BSW, deren statische Module unverändert in unterschiedlichen Steuergeräten eingeModule unverändert in unterschiedlichen Steuergeräten eingesetzt werden können, ist die RTE für jedes Steuergerät individuell setzt werden können, ist die RTE für jedes Steuergerät individuell generiert und bietet nur die tatsächlich benötigten Schnittstellen generiert und bietet nur die tatsächlich benötigten Schnittstellen an. Die Applikation besteht aus Software-Komponenten (SWC), an. Die Applikation besteht aus Software-Komponenten (SWC), welche die Steuergerätefunktion in Form von sogenannten welche die Steuergerätefunktion in Form von sogenannten Runnables umsetzt. Runnables umsetzt. VErtEiltE SoftwarE-Entwicklung VErtEiltE SoftwarE-Entwicklung

Die modulare Autosar-Architektur vereinfacht Software-ZuliefeDie modulare Autosar-Architektur vereinfacht Software-Zulieferern das Spezialisieren auf bestimmte Applikationen und und Komporern das Spezialisieren auf bestimmte Applikationen Komponenten, wie Basis-Software, Fahrdynamik-Regelung, Motormanenten, wie Basis-Software, Fahrdynamik-Regelung, Motormanagement etc. Esetc. istEs dadurch nichtnicht ungewöhnlich, dassdass die Softnagement ist dadurch ungewöhnlich, die Software eines Steuergeräts aus den Modulen und Komponenten ware eines Steuergeräts aus den Modulen und Komponenten mehrerer unterschiedlicher Zulieferer besteht. Die einzelnen TeileTeile mehrerer unterschiedlicher Zulieferer besteht. Die einzelnen werden entweder als Quellcode oder bereits kompiliert als Binärwerden entweder als Quellcode oder bereits kompiliert als Binärdateien geliefert und im Rahmen einereiner Gesamtintegration beimbeim dateien geliefert und im Rahmen Gesamtintegration verantwortlichen Steuergerätehersteller zur kompletten, lauffähiverantwortlichen Steuergerätehersteller zur kompletten, lauffähigen Steuergeräte-Software zusammengefügt. Dieses Speicherabgen Steuergeräte-Software zusammengefügt. Dieses Speicherabbild der erhalten wiederum alle SWCbildSteuergeräte-Software der Steuergeräte-Software erhalten wiederum alle SWCZulieferer für die Entwicklungsschritte. Zulieferer fürweiteren die weiteren Entwicklungsschritte. DiesesDieses Vorgehen ist jedoch sehr sehr aufwendig und und bremst die die Vorgehen ist jedoch aufwendig bremst Software-Entwicklung. Einerseits der Steuergerätehersteller Software-Entwicklung. Einerseits mussmuss der Steuergerätehersteller fürneue jede neue Version aufwendige Gesamtintegrafür jede Version einereiner SWCSWC eine eine aufwendige Gesamtintegration durchführen. Andererseits der SWC-Zulieferer auf das tion durchführen. Andererseits mussmuss der SWC-Zulieferer auf das Ergebnis der Integration warten, um damit Applikation Ergebnis der Integration warten, um damit seineseine Applikation im im Zusammenspiel mitweiteren der weiteren Steuergeräte-Software zu testen. Zusammenspiel mit der Steuergeräte-Software zu testen. Gerade in frühen Entwicklungsphasen führen die häufigen Gerade in frühen Entwicklungsphasen führen die häufigen War-Wartezeiten zu einem erheblichen Mehraufwand. tezeiten zu einem erheblichen Mehraufwand.

Plug-and-Play-lösung für autosar-software-KomPonenten Durch die im Autosar-Standard spezifizierten Schnittstellen kann die Steuergeräteapplikation

SoftwarE-anpaSSungEn nach linkEn SoftwarE-anpaSSungEn nach dEmdEm linkEn

leichter als bisher aus Komponenten unterschiedlicher Zulieferer zusammengefügt werden. Die

Für die Basis-Software in Autosar das Postbuild-Verfahren Für die Basis-Software ist inist Autosar das Postbuild-Verfahren definiert, damit das Verhalten einiger BSW-Module definiert, damit das Verhalten einiger BSW-Module nachnach demdem Übersetzen und dem Linken angepasst werden kann. Dazu werÜbersetzen und dem Linken angepasst werden kann. Dazu werden für diese Module die Konfigurationsdaten getrennt vom statiden für diese Module die Konfigurationsdaten getrennt vom statischen Code im Flash-Speicher abgelegt. So können diese wähschen Code im Flash-Speicher abgelegt. So können diese während der Laufzeit ersetzt werden, ohne die Steuergeräte-Software rend der Laufzeit ersetzt werden, ohne die Steuergeräte-Software erneut übersetzen und linken zu müssen. erneut übersetzen und linken zu müssen. Für die SWCs der Applikations-Software definiert der AutosarFür die SWCs der Applikations-Software definiert der AutosarStandard kein mit Postbuild vergleichbares Verfahren. Jede ModiStandard kein mit Postbuild vergleichbares Verfahren. Jede Modifikation auch nur einer SWC hat das Übersetzen und das Linken fikation auch nur einer SWC hat das Übersetzen und das Linken der kompletten Steuergeräte-Software zur Folge. Es gibt aber eine der kompletten Steuergeräte-Software zur Folge. Es gibt aber eine Möglichkeit, die Anzahl der Gesamtintegrationen zu reduzieren. Möglichkeit, die Anzahl Gesamtintegrationen zu reduzieren. Im Folgenden wird der vorgestellt, wie der SWC-Zulieferer einzelne Im Folgenden wird vorgestellt, wie der SWC-Zulieferer einzelne

Software-Entwicklung wird jedoch dadurch verzögert, dass die einzelnen Komponenten in einem zusätzlichen Schritt zur vollständigen Software zusammengefügt werden müssen. Durch nachladbare Software-Komponenten reduziert sich die Anzahl dieser Gesamtintegrationen, weil man ohne Linken des gesamten Projekts einzelne Software-Komponenten im Flash-Speicher austauschen kann. Vector beschreibt, wie sich dadurch die Software-Entwicklung bei jedem einzelnen Zulieferer beschleunigt.

28

e-011-0494-1_Virtuelle_Navigation_Vector.indd 28 6/6

01I2012 7. Jahrgang 01I2012 7. Jahrgang

1/24/2013 1:35:15 PM

atze-011-0494-1_Virtuelle_Navigation_Vector.indd 29

atze-011-0494-1_Virtuelle_Navigation_Vector.indd 29

29

29

1/24/2013 1:35:17

1/24/2013 1:35:17 PM 6/7

E n t w i c kl u n g S o Ft wA r E

SWCs der Applikations-Software direkt im Flash-Speicher austauschen kann und damit den Integrationsaufwand reduziert. wiE iSt dEr ablauf bEim nachladEn Von Swc?

Bei dem Nachladen einer SWC wird die bestehende SWC durch eine aktualisierte Version direkt im Steuergerätespeicher ersetzt, ohne die übrige Steuergeräte-Software durch diesen Vorgang zu beeinträchtigen. Dies erfolgt entweder online auf dem Steuergerät mittels eines Flash-Bootloaders oder offline durch einen entsprechenden HEX-Editor mit anschließender Übertragung ins Steuergerät, ❷. Das Nachladen erfolgt normalerweise durch den SWC-Zulieferer, kann aber auch vom Gesamtintegrator durchgeführt werden. Durch das Einsparen der Gesamtintegration ergeben sich für den Zulieferer kürzere Entwicklungszyklen: Kodieren – Nachladen – Testen – Optimieren, ❸. Der Gesamtintegrator erzeugt initial ein Speicherabbild der kompletten SteuergeräteSoftware und stellt es den SWC-Zulieferern zur Verfügung. Die Zulieferer erstellen anschließend lediglich eine neue Version ihrer SWC, laden diese in das Speicherabbild und können direkt mit dem Test ihrer SWC beginnen. Um ein zu starkes Auseinanderdriften der SWC-Versionen zu vermeiden, erzeugt der Gesamtintegrator in regelmäßigen Abständen neue Speicherabbilder mit den jeweils aktuellen Versionen aller SWCs. Einschränkungen, welche SWCs nachgeladen werden können, gibt es nicht. Die Entscheidung darüber muss aber bereits während der Planungsphase des Steuergeräts getroffen werden, da Besonderheiten bei der Implementierung und Speicheraufteilung beachtet werden müssen.

❶ Autosar-Schichtenmodell

dies zu gewährleisten, wird der Steuergerätespeicher in mehrere Partitionen unterteilt, die exklusiv den einzelnen SWCs zur Verfügung stehen. Zum Festlegen der Par-

titionsgrößen wird abgeschätzt wie viel Speicher die einzelnen Runnables der SWC voraussichtlich benötigen. Im ersten Moment vergrößert sich damit der Speicherbedarf

❷ Die nachladbare SwC wird im Speicherabbild freigestellt (oben) und in den Flash-Speicher des Steuergeräts übertragen

SpEichErrESErViErung für nachladbarE SwcS

Bei der heutigen Software-Entwicklung wird in der Gesamtintegration der SWCProgrammcode typischerweise ohne konkrete Vorgaben gelinkt. Bei nachladbaren SWCs muss bereits der SWC-Zulieferer das Linken anhand konkreter Vorgaben durchführen. Sowohl die RTE als auch die SWC erwarten die Schnittstellen des jeweils Anderen an den beim Linken hinterlegten Adressen im Steuergerätespeicher. Um

30 6/8 atze-011-0494-1_Virtuelle_Navigation_Vector.indd 30

für die Applikation. Dieses gilt aber nur für die Entwicklungszeit. Um den Speicherbedarf zu reduzieren, kann die Partitionierung in der finalen Software für den Serieneinsatz entfallen. Da in der Regel nur komplette FlashPages gelöscht werden können, werden im einfachsten Fall für jede SWC eine oder mehrere komplette Flash-Pages reserviert. Falls die SWC jedoch deutlich kleiner als eine Flash-Page ist und die dadurch entstehende Fragmentierung nicht akzeptabel ist, können auch mehrere SWC einer Flash-Page zugeordnet werden. In diesem Fall muss jedoch sicher gestellt sein, dass beim Nachladen der SWC mittels Flash Bootloader oder HEX-Editor der übrige Inhalt der Flash-Page nicht verändert wird. SoftwarE-umgEbung Zum kompiliErEn und linkEn EinEr Swc

Zum Kompilieren und zum Linken ihrer SWC benötigen die Zulieferer eine Software-Umgebung, die alle Abhängigkeiten der SWC zu den aufgerufenen Schnittstellen auflöst. Bei dieser Umgebung handelt es sich im Idealfall um die komplette lauffähige Steuergeräte-Software inklusive BSW und Applikation, die auch bei der Gesamtintegration verwendet wird. Vom prinzipiellen Vorgehen entspricht diese Variante einer Gesamtintegration, die aber beim SWC-Zulieferer stattfindet. Das Aufsetzen einer solchen SoftwareUmgebung ist meist mit großem Aufwand verbunden und nicht immer möglich. Daher kann der SWC-Zulieferer alternativ auch eine minimale Umgebung selber erstellen. Diese muss lediglich die von der SWC aufgerufenen Schnittstellen bedienen, ❹. Mit beiden Varianten erhält der SWCZulieferer nach dem Kompilieren und dem Linken eine Binärdatei, die neben der SWC den Code der Software-Umgebung enthält. Für das spätere Nachladen einer SWC ist dieser zusätzliche Code irrelevant und wird entfernt. Das Ergebnis ist eine Binärdatei der zu testenden SWC, in der die Sprungziele bereits an den korrekten Speicheradressen abgelegt sind. wiE funktioniErt daS nachladEn Von SwcS?

❸ Durch das Nachladen von SwCs beschleunigt der SwC-Zulieferer seine Software-Entwicklung

Nach dem Update einer SWC im FlashSpeicher müssen die in der SWC enthal01I2012

1/24/2013 1:35:24 atze-011-0494-1_Virtuelle_Navigation_Vector.indd PM 31

7. Jahrgang

❹ Statt der kompletten Software-umgebung wird bei nachladbaren SwCs eine minimale Software-umgebung zum Linken verwendet

tenen Runnables weiterhin von der RTE oder anderen Runnables aufgerufen werden können. Bei einer Gesamtintegration ersetzt der Linker die beim Kompilieren in der RTE hinterlegten symbolischen Sprungziele durch die korrekten (realen) Adressen der Runnables innerhalb der nachladbaren SWC. Diese Adressen bleiben beim Nachladen der SWC innerhalb der RTE unverändert. Daher muss garantiert sein, dass die Runnables einer nachladbaren SWC bei jedem Übersetzen und Linken immer an diesen Adressen im Speicher abgelegt werden. Diese Bedingung kann unter anderem durch entsprechende Compiler- und Linker-Anweisungen erfüllt werden, die den einzelnen Runnables feste manuell zu vergebende Adressen zuweisen. Es ist jedoch sehr wahrscheinlich, dass der Speicherbedarf der Runnables im Laufe der Steuergeräteentwicklung anwächst. Aus diesem Grund wird ein Reservebereich innerhalb der SWC reserviert. Um diese Reserve einzurichten unterteilt der SWC-Zulieferer die SWC mittels Compileranweisungen in einen statischen und einen veränderlichen Bereich. Der statische Bereich beinhaltet den Einsprungbereich in die SWC. Dieser bleibt immer gleich, auch wenn sich die Implementierung der Funktion ändert. Um dies zu erreichen werden die Runnables der SWC modifiziert. Sie enthalten nun nicht mehr den spezifischen Applikations-Code, sondern lediglich einen Funktionsaufruf. Die dabei aufgerufenen sogenannten Runnable-Funktionen befinden sich im veränderlichen Bereich der SWC und beinhalten den eigentlichen, funktionalen Code der Runnables, ❺. Dieser Code darf sich

dadurch beliebig ändern, ohne eine Adressverschiebung der Runnables im statischen Bereich zur Folge zu haben. Bei jedem Übersetzen und Linken einer SWC werden die symbolischen Sprungziele der Runnables durch die aktuellen Adressen beziehungsweise Offsets ersetzt. Die tatsächlichen Adressen der Runnable-Funktionen müssen also für die RTE nicht bekannt sein. aufruf Von port-intErfacES auS EinEr Swc

Analog zum Aufruf der Runnables durch die RTE müssen in der anderen Richtung die Runnable-Funktionen die von der RTE bereitgestellten Port-Interfaces aufrufen können. Wenn der SWC-Zulieferer eine vollständige Software-Umgebung aus der

❺ Durch die Aufteilung der SwC in einen statischen und einen veränderlichen Bereich liegen die runnables an festen Adressen und können ohne neues Linken von der rtE aufgerufen werden

31 6/9 1/24/2013 1:35:26 PM

E n t w i c kl u n g S o Ft wA r E

❻ Den runnables wird beim Aufruf ein Instance Handle übergeben; damit haben die runnable-Funktionen Zugriff auf die Port Interfaces der rtE

che Port-Interfaces zugewiesen werden, die erst später verwendet werden. : Die Anzahl der Runnables dürfen sich innerhalb einer SWC nicht ändern, da die RTE alle Runnables aufrufen kann die zum Zeitpunkt der RTE-Generierung bekannt sind. Entfallen Runnables während der Entwicklung oder kommen neue hinzu, muss auch die RTE entsprechend angepasst und eine Gesamtintegration durchgeführt werden. : Bereits während der Planungsphase muss festgelegt werden, welche Anforderungen die einzelnen SWCs an das Steuergerät stellen. Dies betrifft einerseits Hardware-Ressourcen aber auch zusätzlich benötigte mathematische Bibliotheken sowie das Scheduling der einzelnen Runnables. : Die Toolchain der einzelnen Zulieferer muss abgestimmt werden, um Inkompatibilitäten aufgrund von unterschiedlichen Compiler-Versionen und -Optionen zu verhindern. auSblick

Gesamtintegration mit BSW und RTE einsetzt (vgl. Kapitel „Software-Umgebung zum Kompilieren und Linken einer SWC“), sind keine weiteren Maßnahmen erforderlich, weil alle Sprungziele zum Link-Zeitpunkt bekannt sind. Wird jedoch eine minimale SoftwareUmgebung eingesetzt, befinden sich die Port-Interfaces der RTE beim Erstellen der SWC an anderen Adressen als bei der Gesamtintegration. Als Folge davon werden beim Linken der SWC falsche Adressen hinterlegt. Damit der Aufruf von Port-Interfaces aus SWCs korrekt funktioniert, werden bei nachladbaren SWCs zwei Autosar-Features genutzt: Object Code und Multiple Instantiation. Bei dieser Kombination übergibt die RTE jedem Runnable zur Laufzeit das sogenannte Instance Handle als Übergabeparameter. Dieses Handle zeigt auf eine

Indirektionsstruktur der RTE, die sogenannte Component Data Structure, ❻. In dieser Struktur sind die Adressen aller Port Interfaces der SWC hinterlegt. Die SWC muss also die Adressen der RTE Port Interfaces nicht kennen. Die Component Data Structure ist in der Contract Phase Header Datei jeder SWC beschrieben. randbEdingungEn für daS nachladEn EinEr Swc

Damit SWCs wie hier beschrieben ausgetauscht werden können, müssen einige Randbedingungen eingehalten werden: : Durch den Austausch einer SWC können keine Port Interfaces hinzugefügt oder entfernt werden. Allerdings können bei der RTE-Generierung für zukünftige Erweiterungen schon zusätzli-

Das hier vorgestellte Anwendungsbeispiel mit mehreren SWC-Zulieferern und einem Gesamtintegrator ist nicht der einzig denkbare Anwendungsfall. Nachladbare SWCs können auch das Bypassing von SWCs vereinfachen, indem die für das Bypassing nötige Instrumentierung komfortabel durch eine nachladbare SWC auf das Steuergerät gebracht werden kann. Soll die SWC dann tatsächlich auf dem Steuergerät getestet werden, kann die Instrumentierung wieder durch die nicht-instrumentierte SWC ersetzt werden. Nachladbare SWCs stellen somit ein mächtiges Werkzeug dar, dass die Entwicklung von Steuergeräte-Software unterstützen und beschleunigen kann. Bisher muss die Vorbereitung einer SWC und das Speicher-Mapping noch manuell durchgeführt werden. Es ist aber geplant diese Verfahren weitgehend durch Konfiguration zu automatisieren.

Beschleunigen Sie Ihre Embedded-Entwicklung!

Standardisierte Basissoftware für CAN, LIN, FlexRay, Ethernet, J1939

Nutzen Sie skalierbare Softwaremodule, die weltweit erfolgreich im Einsatz sind. > Profitieren Sie von der Vector AUTOSAR-Lösung

> Aktualisieren Sie mit dem Flash Bootloader Ihre

mit intelligenten Erweiterungen > Kombinieren Sie die Softwarekomponenten

Steuergeräte prozesssicher und optimal geschützt > Steigern Sie Ihre Effizienz durch maßgeschneiderte

individuell und passend für Ihre Projekte > Sparen Sie Entwicklungszeit durch eine perfekt aufeinander abgestimmte Werkzeugkette

Beratungs- und Entwicklungs-Dienstleistungen Erfahren Sie mehr: www.vector.de/ecu-software

Vector unterstützt Ihre Entwicklung mit Steuergeräte-Software, Konfigurationstools und Serviceangeboten.

32 6/10 atze-011-0494-1_Virtuelle_Navigation_Vector.indd 32

Erschienen in ATZ elektronik, 1/2012

1/24/2013 1:35:27 PM

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Figure 1: Division of ECU

evaluation and the EV-ECU were then connected using a

ECU Development Process Testing

CAN communication network. (Figure 2, “Local CAN”).

Here is a summary of the tests we carried out with a focus

To evaluate software reusability, the software assigned to

on the ECU development process with AUTOSAR. > Differences from legacy ECU development processes > Division of roles between automobile OEMs and

one of the two AUTOSAR ECUs was divided again and ap-

AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector

plied to another AUTOSAR ECU (Figure 7). This implementation process was compared to the implementation process of commonly reused software, to evaluate software

suppliers > Tool chains

reusability with AUTOSAR.

> Data definition file format

English Translation of a Japanese Technical Article from Mitsubishi Motors Corporation AUTOSAR is a group paving the way for the standardization of software platforms across Electronic Control Units (ECU). Its activities have gained momentum in recent years. In order to find out how AUTOSAR could best be applied to ECUs, we – Mitsubishi Motors – joined forces with our supplier, Mitsubishi Electric, to test the development process and evaluate the tool chains relevant to the implementation of AUTOSAR software components on ECUs. For evaluation we used the EV-ECU of the i-MiEV electric car. Here is an overview of the project.

AUTOSAR

confusion and disruption. This is why we joined forces with

As the number of on-board computers (ECUs) in automo-

Mitsubishi Electric, our ECU supplier, and Vector Japan Co.,

biles increase along with their functionality, there has been

Ltd. to test the AUTOSAR ECU development process and

an increase in software implementation. As a result, the

verify the development environment (tools) as a prepara-

Europe-based AUTOSAR has been gaining attention as the

tion for implementing AUTOSAR software components.

leading platform for the standardization of basic software

This project also covers evaluation of software reusability

specifications. This standardization covers basic software

with AUTOSAR.

modules e.g. for I/O access, CAN communication and the operating system. Furthermore, the standardization in-

AUTOSAR Evaluation Overview

cludes XML formats for exchanging configuration data.

For this project, we evaluated the EV-ECU, the main control ECU for the i-MiEV electric car. We decided to extract

6/12

Preparing for AUTOSAR

and use a part of Mitsubishi Motor’s model-based soft-

As it is not yet clear how AUTOSAR will affect the existing

ware from the EV-ECU. To carry out the evaluation, the ex-

ECU development processes and development environ-

tracted software was divided and assigned optimally to

ments of automobile OEMs and suppliers in Japan, imple-

two ECUs using microcontroller evaluation boards (Figure

menting AUTOSAR without careful thought may cause

1). The AUTOSAR ECUs designed for the purpose of this

Figure 2: Overview of vehicle network

6/13

AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector

This project evaluated the processes listed below. We have

Vehicle Network Design

summarized the details of the workflow and testing crite-

On the vehicle network of an i-MiEV, a gateway ECU was

ria, as well as the results for each process. The development

set up where the EV-ECU was located, and a local CAN

and implementation environment can be seen in table 1. > Vehicle system design

communication network was constructed using the modi-

> Vehicle network design

We used Network Designer for the CAN communication

> ECU application software design

network design (Figure 3). The CAN communication data

> ECU software system design

was exported as a system description file in ARXML for-

> ECU software detailed design

mat. As far as the communication network design is con-

> Coding/ Implementation

cerned, the design method remains unchanged except for

fied EV-ECU and the AUTOSAR ECUs (Figure 2).

the tool and data transfer file format. In addition to the Vehicle System Design

ARXML format, Network Designer also offers various other

A certain system requirement specification was created for

formats such as DBC and FIBEX which could be used in-

the evaluation project. We designed a system focusing on

stead of the AUTOSAR format. As network design also

coordination between the EV-ECU and the extracted soft-

takes the entire vehicle into consideration, the process is

ware. The evaluation included the allocation of functions to

carried out by the OEM.

each ECU, the network configuration and choosing suitable AUTOSAR BSW. The system requirement specification has

ECU Application Software Design

been revised according to the evaluation results. The allo-

We edited the software extracted from EV-ECU using

cation of functions to each ECU was realized by assigning

Simulink®. According to the software model’s inputs and

software components (SWC) using the AUTOSAR method.

outputs, we defined the AUTOSAR compliant ports/inter-

It depends on the OEM and the project whether to define

faces and runnable entities.

the SWC and BSW configuration during the vehicle system

In terms of software reusability, the SWC input/output

design, or during ECU design. Since we were dealing with a

port and data configuration require caution, especially with

The model’s software source code and the SWC Descrip-

allocated to each ECU. Next, the System Description file

small-scale system and with BSW provided by the specific

regard to the collection of data and configuration of the

tion file were automatically generated using Real-Time

generated from the network design was imported and the

port. If the data does not match other SWC port configu-

Workshop® Embedded Coder™. In this evaluation project,

CAN communication data and SWC input/output data

rations when reusing SWC, the port configuration will have

the ECU application design was carried out by Mitsubishi

were mapped. DaVinci Developer features an automatic

to be changed (Figure 4). On the other hand, creating a

Motors. For series projects the division of roles should be

data mapping function, which is extremely useful when

port for each data makes the SWC configuration too com-

discussed before design.

dealing with large amount of data. The data configured by

software vendor, we chose the former option.

Figure 4: Points to note in terms of SW-C reusability

DaVinci Developer for each ECU is exported as an “ECU

plicated and is therefore not recommended. For SWC ports in line to be reused, it is important to review the port con-

ECU Software System Design

Extract of System Configuration” file in ARXML format.

figuration beforehand.1

The ECU software system design involves the allocation of

As the network design is frequently being updated with re-

Regarding the interaction of tools, it should be taken into

SWC to ECU and designing the ECU input/output data.

gard to the ECU development process, it is important for

consideration that several tools might change the Soft-

We used DaVinci Developer™ (Figure 5) for this purpose.

the Runtime Environment (RTE) design tool that the Sys-

ware Component Description file (SWC Description).2

First, the SWC Description file generated from Simulink®

tem Description can be simply updated and that the con-

was imported into DaVinci Developer and the SWCs were

tent of such updates can be easily verified.

1 In the latest AUTOSAR release 4.0, these problems are reduced since it is possible to explicitly define the mapping between port data. 2 Therefore, the tools need to support a roundtrip and must not overwrite the data created by another tool.

The ECU software system design was carried out by Mitsubishi Motors. For small-scale development projects (such as closed projects with ECU units), it may be efficient for the supplier to carry out the design. However when designing software partially or designing a cooperative control with multiple ECUs, it is better for the OEM to do the design. By mapping the communication and SWC data, the OEM can verify the consistency of the data in advance. This is useful, as inconsistency of data can lead to unnecessary work between the OEM and supplier. ECU Software Detailed Design ECU software detailed design involves the configuration of ECU device drivers and design of OS and ECU basic func-

Table 1: Development and implementation environment used for evaluation

6/14

tions (CAN communication, error diagnostic functions, Figure 3: Network Designer™

Figure 5: DaVinci Developer™

etc). The design uses the ARXML-format “ECU Extract of System Configuration” files gene-rated above.

6/15

AUTOSAR ECU Development Process Using DaVinci and MICROSAR from Vector

written to ROM. We used an IAR compiler for compiling. In the past, the codes were generated manually by hand coding. In contrast, AUTOSAR enables the usage of configuration tools and automatic code generators for coding. As is the case with legacy methods, coding/ implementation is carried out by the supplier. Functional Testing We equipped an i-MiEV with the AUTOSAR ECUs we designed and ran vehicle tests (Figure 6). As the functions formerly processed by one ECU are now distributed to several ECUs, there was some delay in communication between the ECUs. Nevertheless, we were able to onfirm that the Figure 6: Vehicle testing

car was controlled correctly by the AUTOSAR ECUs. Testing Reusability We then tested the reusability of SWCs. By assigning the

Specific design details include the allocation of Runnable

SWCs to an additional ECU (they were assigned to two

Entity to OS tasks and the configuration of the relevant BSW

ECUs during ECU development process testing) and chang-

parameters. We carried out the configuration in this case

ing the assignment pattern (Figure 7), we estimated the

using DaVinci Developer, GENy and DaVinci Configurator Pro.

process and man-hours needed in porting the SWCs. We

The ARXML-format “ECU Configuration Description” file

were then able to compare the legacy design and the de-

describes the specific configuration of the basic software

sign according to the AUTOSAR method.

ECUs and data mapping with CAN communication data

Evaluating Tool Chains

modules and is shared between the involved tools. As ECU

are both easy to do by using the tools. This has not been the

As tool chains influence the quality of the software greatly,

software detailed design is dependent on the hardware

Here are the tasks involved in porting the SWC: > Redesigning the network

case until now: adapting application software interfaces

it is important to discuss issues thoroughly with the sup-

configuration, it is carried out by the supplier.

> Assigning SWCs to ECUs

usually took much time and effort.

plier. Considering the tool dependence, it makes sense to

> ECU software detailed design

Regarding the detailed design of ECU software, it is possi-

use tools from the same vendor throughout the entire de-

ble to reduce the configuration settings when carrying over

velopment process. The tool chains evaluated in this project

Redesigning the network is necessary for both legacy and

parts of the existing configurations. As a result, there is a

can be seen in figures 8 and 9. The pink areas show the work

automatically generated by DaVinci Configurator Pro and

AUTOSAR methods and the processes do not differ by

great potential for reducing the time and effort that usual-

carried out by the OEM and the light blue areas indicate

GENy. This code is compiled along with the static code of

much. The application software and SWC interface require

ly goes into adapting interfaces and designing middleware.

the work carried out by the supplier.

the basic software into the executable code, which is then

no modification in porting the SWCs. Assigning SWCs to

Coding/Implementation The configuration code for the basic software modules is

Figure 7: Evaluating reusability and ease of porting

6/16

Figure 8: ECU development process with AUTOSAR (Part 1)

Figure 9: ECU development process with AUTOSAR (Part 2)

6/17

Translation of a publication in the Japanese Vector Journal

design and code generation, Vector offers tools encompassing the entire process. As the tool chain is pre-estab-

Image rights:

lished, there is consistency and uniformity in the data through-

All figures: Mitsubishi Motors Corporation

out the process, increasing reliability in development. The tools could be improved by expanding the compatibility

Literature:

of data exchanged with the most commonly used tools

www.autosar.org

from other companies. As model-based development with AUTOSAR has proven to be a valid development method

Links:

for the future, we hope this issue will be prioritized.

Homepage Vector: www.vector.com

Also, GUI-based software design is efficient in the design

Information on Vector’s AUTOSAR products:

phase, but it is not suitable for comparing and verifying the

www.vector.com/autosar

design data. An additional function to export the data designed by each tool in table format would be desirable. The process of testing the communication signal’s configuration parameters and the transmission and reception of the signal was very complicated. This process would be

Author: Yuichi Kamei Mitsubishi Motors Corporation Electronic Control System Development Electronics Engineering Dept. Development Engineering Office

much more efficient if the data could be exported in table

Der Kunde Ein erfolgreicher europäischer Nutzfahrzeughersteller, der

Beispiele der umgesetzten AUTOSAR-Funktionen: > Wakeup & Sleep Handling

eine führende Rolle bei der Einführung von AUTOSAR ein-

> Verschiedene Transmission Modes, Update Bits, Routings

nimmt. Seine ausgereiften E/E-Prozesse ermöglichen eine

> Diagnostic Services, Security Level und DTC Handling

effiziente Entwicklung von AUTOSAR-Steuergeräten.

> J1939 dynamic DLC und BAM

Die Herausforderung

> Parameter Handling (“Power lost safe”)

Entwicklung eines Referenzsystems mit mehreren vernetz-

Summary By testing the ECU development process using AUTOSAR, we were able to gain an understanding of the workflow and division of roles. We were also able to clarify the neces-

ten Steuergeräten anhand eines vorgegebenen Entwick-

Die Vorteile

lungsprozesses. Das System muss CAN, J1939 und LIN

Kompaktes Referenzsystem für die Steuergeräte- und

unterstützen und auf der Vector AUTOSAR-Basissoftware

Systementwicklung mit AUTOSAR. > „Sandbox“ um funktionale Erweiterungen der AUTOSAR-

MICROSAR basieren.

sary mutual consultation between OEMs and suppliers for

Das Referenzsystem soll wesentliche Teile des OEM

each process. With AUTOSAR, the OEM can take over the

AUTOSAR-Funktionsumfangs und die folgenden Aufgaben

designing process usually associated with the supplier side.

unterstützen: > Validieren der korrekten Umsetzung der Spezifikationen

Furthermore, there is room for optimization in overlapping areas such as ECU software system design, where both

sowie des vom OEM vordefinierten Entwicklungs-

OEM and supplier should be more flexible in the future.

prozesses

Regarding reusability, we found that this goal can be easier

> Verifizieren des Systemverhaltens

reached with AUTOSAR than with legacy methods. How-

> Durchführen von Performance-Messungen

ever, we focused solely on the sender-receiver port format

> Validieren von neuen Softwareständen

for the SWC input/output, therefore the reusability for server-client port formats still needs to be evaluated. Through the evaluation project, we were able to establish the technical details to some extent. In the future, we will

Basissoftware oder der Applikation zu entwickeln > Einfacher Vergleich der Performance in unterschiedlichen Systemzuständen > Übersichtliche Benutzeroberfläche zur manuellen Stimulation von Systemzuständen > Einfache Erweiterung des Referenzsystems mit realen Steuergeräte > Wenig Aufwand zur Durchführung von Regressions-Tests nach funktionalen Änderungen oder Aktualisierung der

> Fehlerzustände reproduzieren

AUTOSAR-Basissoftware > Gute Erweiterbarkeit durch modularen Aufbau der

Die Lösung

Software sowie der Hardware > Validierter und optimierter Entwicklungsprozess

Die Systemumgebung besteht aus vier exemplarischen

actively exchange information and opinions with suppliers

Steuergeräten, der Testsoftware CANoe und der Testhard-

and tool software vendors to put in place a framework for

ware VT System mit verschiedenen Einschubkarten.

the introduction of AUTOSAR at Mitsubishi Motors, from

Es wurden vier typische Steuergeräteklassen definiert und

the introduction process to implementation.

durch jeweils ein Steuergerät abgebildet. Dadurch ergibt sich ein sinnvolles und überschaubares Abbild des späteren

Afterword

Gesamtsystems.

We received great support for this evaluation project.

Um die Systemfunktionen darstellen zu können, wurden

Compilers were kindly provided by IAR Systems, and micro-

mehrere Demo-Applikationen implementiert. Diese werden

controllers by Renesas Electronics Corporation. Though we

von CANoe über ein neu entwickeltes, CAN-basiertes

were not able to realize their offer for this evaluation, an

Remote-Protokoll gesteuert. Damit stimuliert CANoe eine

offer from Fujitsu Semiconductor Limited for collaboration

Funktion bzw. einen speziellen Systemzustand und prüft

was greatly appreciated. And of course, Mitsubishi Electric’s

die Reaktion.

cooperation and Vector Japan’s tool software were invalu-

Alle Diagnoseanfragen laufen wie im realen Fahrzeug über

able. We’d like to take this opportunity to thank everyone

6/18

Case Study

> Diagnostic Session Control und Software-Download

format.3

for their support.

Entwicklung eines Referenzsystems für AUTOSAR-Steuergeräte und Systemuntersuchungen

einen Diagnosetester des OEMs, der von CANoe fernge3 In the latest generation of the tool chain, Vector provides according functions to compare the design data.

V2.0 | 2012-11

From network design to AUTOSAR RTE/BSW/OS detailed

steuert wird.

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

6/19

>>Die Applikations-Software wird durch ihre Software-­

Einen klaren Vorteil beim Integrieren von Applikations-Soft-

Komponenten (SWCs) beschrieben, >>die Beziehung der SWCs zu den Netzwerken ist definiert

ware und Konfigurieren der Basissoftware sieht Hella in den

(Data Mapping) und >>die Nutzung der Service-Funktionen der Basissoftware

zum Tragen, wenn das Aktualisieren der System-Description

ist festgelegt (Service Mapping).

genaueren Vorgaben. Dieser Vorteil kommt allerdings nur gerade in den frühen Entwicklungsphasen häufig genug erfolgt. Nur so ist die Konsistenz der Daten auf OEM- und Tier1-Seite sichergestellt. Im Laufe der Entwicklung hat

AUTOSAR-Methodik in der Praxis Die Partner Daimler, Hella und Vector berichten über Erfahrungen aus der

sich gezeigt, dass eine klare Release-Planung für den Daten­

teile in der Applikations-Software formalisiert zu beschrei-

austausch in beide Richtungen notwendig ist. Dazu gehört

ben und prozess-sicher an den Steuergeräte-Lieferanten

neben dem ECU-Extract of System Description (Subset

(Tier1) zu übergeben. Daimler sah und sieht hierin einen we-

der System Description für ein Steuergerät) auch der dazu

sentlichen Schritt zur konsequenten Umsetzung der Sys-

konsistente Austausch der Diagnosebedatung.

tem- und Funktionsorientierung.

Die Kompatibilität der Architektur-Ebenen verbleibt der-

Früher wurde die Schnittstellenbeschreibung der Applika-

zeit noch als vielfach ungelöstes Problem: Um seine Sys-

tions-Software erst im Laufe der Entwicklung vervollstän-

temkompetenz OEM-übergreifend effizient darzustellen,

digt und lag in der Verantwortung des Zulieferers. Jetzt

entwickelt der Tier1 seine eigene Software-Architektur. Der

stehen die Entwickler der entsprechenden Fachabteilungen

OEM entwickelt seine Software-Anteile wiederum Tier1-­

von Daimler vor der Aufgabe, früh im Entwicklungsprozess

übergreifend. Da diese beiden Konzepte normalerweise

den Funktionsumfang des Steuergeräts auf Software-­Kom­

nicht deckungsgleich sind, ergibt sich typischerweise ein In-

ponenten zu verteilen und auch die Steuergeräte-internen

tegrationsproblem, das z.B. durch Anpassungsmodule über­

Schnittstellen festzulegen (Bild 2). Die formale Beschrei-

wunden werden muss. Eine diesbezügliche Standardisie-

bung zwingt sehr früh zu Vollständigkeit und Konsistenz

rung durch AUTOSAR ist wünschenswert, stößt aber an

und verlagert den Aufwand im Entwicklungsprozess nach

Grenzen, wenn dadurch die Wettbewerbsdifferenzierung

vorn – zum OEM. Ein gutes Beispiel für „Front-Loading“,

beschränkt würde.

das aber erst nach Durchlaufen einer Lernkurve den ge-

Werden Software-Komponenten zusätzlich von Dritten bei­

wünschten Nutzen bringt.

gestellt, ist das Synchronisieren der Daten nochmals wich-

Für den Tier1 bedeutet das frühe Festlegen zunächst einen

tiger. Aber auch hier gilt: Durch die formalisierte Informa­

Verlust an Flexibilität, da lokale Änderungen an den Schnitt-

tion ist der Austausch deutlich erleichtert – alle sprechen

Einführung der AUTOSAR-Entwicklungsmethodik

stellen nicht mehr einfach durchführbar sind. Diese Ände-

die gleiche Sprache.

Ist AUTOSAR eine Revolution, bei der sich der schöne neue Zustand erst nach vielen Schmerzen einstellt oder doch eher

den (Bild 3). Dabei zeigte sich die Notwendigkeit leistungs-

Optimale Steuergeräte-Konfiguration ist der Schlüssel

fähiger Diff-, Merge- und Report-Algorithmen. Vector hat

für effizientes Entwickeln

in diesem Bereich erheblich investiert und bietet inzwischen

Der Werkzeughersteller ist gefordert, die dramatisch ge-

Mechanismen, um Aufwand und Fehler stark zu vermindern.

stiegene Anzahl von Konfigurationsparametern handhab-

eine Evolution, die einen sanften Übergang erlaubt? Die drei Firmen Daimler, Hella und Vector haben sehr früh das große Potential von AUTOSAR erkannt und berichten über die Erfahrungen aus vielen Serienprojekten. Sie haben gelernt, wo leicht erreichbare Vorteile liegen. Sie zeigen aber auch auf, welche Hürden zu überwinden waren und welche Hindernisse auch heute noch zu beachten sind.

6/20

Die SWC-Definition ermöglicht dem OEM, die eigenen An-

Die Funktion gab den Anstoß

Neue Methoden und Austauschformate – zunächst ein

Wesentliche Triebfeder für die Einführung von AUTOSAR

Nebeneffekt, auf lange Sicht wichtiger Baustein für hohe

war für Daimler die hohe Anzahl neuer Funktionen und die

Entwicklungs-Qualität

fortschreitende Konzentration von Funktionen auf wenige

Mit AUTOSAR hat sich die Automobilindustrie einen Stan-

Steuergeräte. Der dadurch erheblich gestiegene Kommu­

dard geschaffen, der das Entwickeln von Steuergeräte-­

nikationsbedarf erforderte den Einsatz eines FlexRay-Bus-

Software auf eine neue methodische Basis stellt. Diese

systems. Eine neue Basissoftware und ein neues Aus-

­Basis erlaubt eine deutlich verbesserte Systematik in der

tauschformat waren erforderlich. Um alle Bussysteme ein-

Zusammenarbeit zwischen Fahrzeugherstellern (OEM) und

heitlich zu behandeln, wurden die Weichen in Richtung

Zulieferern und ermöglicht damit die prozesssichere Kom-

AUTOSAR gestellt.

bination von Funktionsanteilen aus verschiedenen Quellen.

Dieser Entscheidungsprozess ist typisch, denn eine große

Die neue Methode erfordert standardisierte und vor allem

Stärke von AUTOSAR liegt darin, dass viele neue Funktio-

erweiterte Datenaustauschformate. Während die bekann-

nen standardisiert bereitstehen. Dies gilt für das Unter-

ten Austauschformate wie DBC, LDF oder FIBEX teilweise

stützen neuer Bussysteme – wie aktuell Ethernet – aber

busspezifisch sind und nur die Kommunikation beschreiben,

auch für Funktionen wie Partial Networking (Teilnetzbe-

ist das AUTOSAR-Austauschformat „System Description“

trieb), Functional Safety, Security oder Multicore-Support.

erheblich erweitert (Bild 1):

rungen müssen zwischen Tier1 und OEM ausgetauscht wer-

Bild 1: Die AUTOSAR „System Description“ enthält sowohl die Kommunikationsbeschreibungen als auch diverse weitere Informationen zu den Software-Komponenten und zur Basissoftware.

Bild 2: Der OEM hat einen tieferen Einblick in die Applikation und definiert die Struktur der Softwarekomponenten (SWCs).

6/21

AUTOSAR-Methodik in der Praxis

bar zu machen. Dem Entwickler müssen möglichst viele

Projekte parallel bearbeiten

quenten Schritt lässt sich nun mit steigender Erfahrung

Algorithmen bereitgestellt werden, um abhängige Parame-

Betrachten wir abschließend den Aspekt des parallelen Ar-

aller Beteiligten das komplette Potential von AUTOSAR er-

ter automatisiert richtig einzustellen und sinnvolle Kombi-

beitens an einem Steuergeräte-Projekt – ein elementares

schließen.

nationen vorzuschlagen. Fluch und Segen von AUTOSAR

Thema für größere Steuergeräte-Entwicklungen, wie sie

Hella sieht den größten Vorteil in dem deutlicher besser

liegen hier dicht beieinander: Die hohe Konfigurierbarkeit

bei Hella typisch sind.

strukturierten Vorgehen in der Kooperation mit dem OEM.

der Basissoftware führt zu der großen Parameterzahl, er-

Die zentrale Datenhaltung erschwert das parallele Arbei-

Es bleibt der Wunsch, dass sich dieses Vorgehen in der Brei-

laubt aber andererseits den Einsatz in vielen Projekten. Da-

ten von mehreren Teams an einem Steuergeräte-Projekt,

te durchsetzt, damit die Investition in AUTOSAR langfristig

her stellen die Tools einen wichtigen Faktor für den Erfolg

weil alle gleichzeitig auf die Daten zugreifen müssen. Ab-

zum erwarteten Gewinn an Effizienz und Qualität führt.

dar. Ein generischer Editor ist hier nicht ausreichend. Um

sprachen zwischen den Teams, die früher ein pragmati-

den Anwender maximal zu unterstützen, muss das Werk-

sches Arbeiten gefördert haben, lassen sich nicht ohne wei-

Deutsche Version des englischen Fachartikels in ATZ extra

zeug spezialisierte Ansichten und Algorithmen bieten. Damit

teres konsistent in den AUTOSAR-Beschreibungsdateien

(10 Years AUTOSAR), Oktober 2013

werden z. B. abhängige Parameter konsistent bearbeitet.

abbilden. Daher ist es vorteilhaft, die AUTOSAR-Beschrei-

Die enge Abstimmung zwischen den Projektpartnern hat

bungen in Elemente zu unterteilen, um diese getrennt in

Alle Bilder:

entscheidend dazu beigetragen, Werkzeuge und Abläufe zu

einem Konfigurationsmanagement-System abzulegen. Zu-

Daimler, Hella, Vector Informatik GmbH

verbessern. Auch wenn der Arbeitsablauf durch AUTOSAR

sätzlich sind Funktionen zur Darstellung der Unterschiede

grob vorgegeben ist, wird erst in der Praxis erkennbar, wel-

und zum konsistenten Zusammenführen notwendig. Die

che Anwendungsfälle entstehen und an welcher Stelle die

Werkzeuge müssen dabei dem Anwender möglichst viel

Werkzeuge durch entsprechende Funktionen das Arbeiten

manuelle Arbeit abnehmen. Die Qualität von Fehler- und

effizienter gestalten können.

Warnmeldungen hat sich als ganz entscheidend herausge-

In der Einführungsphase von AUTOSAR gab für alle Betei-

stellt. Anfänglich wurde dem zu wenig Aufmerksamkeit ge-

ligten eine weitere Herausforderung: Im Laufe des Projekts

schenkt. Inzwischen ist durch den intensiven Informations-

entstanden neue Anforderungen an die BSW-Module und

austausch zwischen Anwendern und Werkzeug-Entwick-

die Beschreibungsformate. Dies bedeutete, dass während

lern ein deutlich besseres Niveau erreicht worden.

Dr. Ralf Belschner ist Teamleiter Standard Software in der Mercedes-Benz ­Serienentwicklung in Sindelfingen

Steffen Herz ist Leiter Entwicklung Standard Elektronik bei Hella in Lippstadt

der Entwicklung teilweise auf neue AUTOSAR-Minor- oder -Patch-Versionen gewechselt, bzw. vorübergehend eine Er-

Revolution oder Evolution?

weiterung zur AUTOSAR-Spezifikation umgesetzt werden

Heute ziehen alle Projektpartner eine positive Bilanz. Für

musste. Dazu wurden die von Daimler verwendeten und für

Daimler war der Umstieg auf die System Description ein

AUTOSAR erweiterten in-house-Werkzeuge synchron mit

logischer und notwendiger Schritt, um die weiter steigende

den Werkzeugen von Vector angepasst. Zusätzlich muss-

Vernetzung von Fahrzeugfunktionen zu beherrschen. Die

ten die Anwendungsfälle auf Tier-1-Seite betrachtet wer-

Kombination von neuem AUTOSAR-Standard mit mehre-

den, um eine automatische Übernahme der erstellten Kon-

ren busspezifischen Konfigurationsformaten wäre sicher

figurationen zu ermöglichen.

auch nicht reibungsfrei verlaufen und durch den konse-

Dipl.-Ing. (FH) Jochen Rein ist Gruppenleiter Produktmanagement und Vertrieb für ­Embedded Software bei der Vector Informatik GmbH in ­ tuttgart S

Bild 3: Damit der Tier1 immer ­konsistente Daten verwendet, muss er regelmäßig seine Änderungen an den OEM zurückspeisen und stets die aktuellste Version vom OEM ­bekommen.

6/22

6/23

Weiteren werden die OBD-Anfragen gegenüber den UDS-­ Anfragen (Unified Diagnostic Services) entweder priorisiert oder parallel abgearbeitet. Auch das DEM-Modul enthält für OBD verschiedene Erweiterungen gegenüber UDS. Dazu gehören ein verändertes Fehlerstatusverhalten, die Ablage von permanenten DTCs, das Speichern von Freeze-Frame-­ Daten und das Berechnen der „In Use Monitor Performance Ratio“ (IUMPR). Außerdem stellt das DEM-Modul zusätz­ liche Daten zur Verfügung, wie z. B. PID $21 „Distance ­travelled while MIL is activated“. In Kombination mit dem FIM-Modul wird das Inkrementieren der IUMPR-Zähler deaktiviert, sobald bestimmte Fehlfunktionen detektiert werden. Für die AUTOSAR-4-Basissoftware von Vector (Bild 2) ist Bild 1: Die OBD-spezifische Erweiterung des Moduls DCM enthält neun zusätzliche Services.

bereits eine serienreife OBD-Erweiterung der Module DEM, DCM und FIM verfügbar, welche auch in die AUTOSAR-3-­ Lösung integrierbar ist. Dabei hat Vector für mittlerweile

OBD-Funktionen als Teil der AUTOSAR-Basissoftware

fünf Fahrzeughersteller OEM-spezifische Anpassungen der

Durch die schnelle Verbreitung elektrisch unterstützter An-

OBD-Funktion berücksichtigt.

triebe gibt es eine stark wachsende Zahl von Primary ECUs mit Comprehensive-Component-Monitor-Funktion. Daher

Deutsche Version des englischen Fachartikels in ATZ extra

bietet es sich an, im ersten Schritt die OBD-Funktionen im

(10 Years AUTOSAR), Oktober 2013

Rahmen einer Standard-Software für diese Steuergeräte zu realisieren. Die für OBD umzusetzenden Funktionen der

Alle Bilder: Vector Informatik GmbH

Module DCM (Diagnostic Communication Manager), DEM (Diagnostic Event Manager) und FIM (Function Inhibition

OBD meets AUTOSAR

Manager) sind durch AUTOSAR definiert. Dabei wird in er-

OBD-Funktionen in der AUTOSAR-Basissoftware vereinfachen

heblichem Umfang auf die Definitionen in den OBD-Normen und -Direktiven verwiesen. Die konkrete Implementie-

die Diagnoseimplementierung

rung und Konfiguration wie z. B. die Kalibrierungsstrategie

Im Zuge der Elektrifizierung des Antriebsstranges wächst die Zahl der OBD-relevanten Steuergeräte. Damit steigt auch

vom Softwarelieferanten in Zusammenarbeit mit den OEMs

die Nachfrage nach einer standardisierten Lösung – idealerweise auf der Basis von AUTOSAR. Dieser Artikel beschreibt, welche OBD-Funktionen in die AUTOSAR-Basissoftware integriert sind und welche Anwendungsfälle damit unterstützt werden.

Dr.-Ing. Thomas Necker ist Teamleiter im Bereich Embedded Software. Er ist ­verantwortlich für die Entwicklung der Diagnose-Module und deren OBD-Erweiterung.

und der Zusammenhang mit dem UDS-Fehlerspeicher muss festgelegt werden.

Dipl. Ing. Oliver Garnatz ist Produktmanager im Bereich Embedded Software. Er ist ­Mitglied in der ISO im Bereich Kfz-Diagnose sowie in AUTOAR.

Das DCM-Modul setzt dabei die OBD-spezifischen Dienste (Bild 1) um, wie zum Beispiel $04 „Clear/Reset Emission-­ Related DTCs“ und $09 „Request Vehicle Information“. Des

6/24

OBD ist nicht gleich OBD

ler Daten und steuert die Warnmeldung an den Fahrer.

Für Fahrzeuge mit Verbrennungsmotor wurden in den letz-

„Primary ECUs“ sind Steuergeräte, die lokale Daten in ih-

ten Jahren immer schärfere Emissions-Grenzwerte defi-

rem Fehlerspeicher erfassen und auch mit dem Scan-Tool

niert. Damit diese Grenzwerte auch im langjährigen Be-

kommunizieren. „Secondary ECUs“ führen zwar emissions-

trieb eingehalten werden, überwacht eine On-Board-­

relevante Funktionen aus, übertragen die benötigten Da-

Diagnose die fehlerfreie Funktion der Komponenten und

ten zum Speichern jedoch immer an eine Primary oder

Systeme. Die ersten Anforderungen an eine solche On-­

Master ECU.

Board-­Diagnose hat das Californian Air Resources Board

Die Funktionen zum Überwachen von Komponenten und

(CARB) für das Modelljahr 1988 formuliert (OBD I). Für das

Systemen sind in zwei Kategorien unterteilt: Die „Major

Modelljahr 1996 folgte mit OBD II eine Standardisierung

Monitors“ überwachen Systeme, die unmittelbaren Ein-

bezüglich der Fehlercodes (DTC = Diagnostic Trouble Code)

fluss auf Emissionswerte haben. Hierzu gehören das Kraft-

und des Steckers für das externe Scan-Tool. Dieser Stan-

stoff- und Abgasrückführ-System, Katalysatoren und Par-

dard wurde von der Europäischen Union mit der Bezeich-

tikelfilter. „Comprehensive Component Monitors“ überwa-

nung EOBD weitgehend übernommen und ab dem Modell-

chen Systeme, die für die Major Monitors benötigt werden

jahr 2001 in Europa verpflichtend.

oder indirekt die Emissionen beeinflussen. Dazu zählen z. B.

Üblicherweise sind für jedes Fahrzeug drei Klassen von

Funktionen, die die Rekuperation beim Abbremsen des Fahr-

Steuergeräten (ECUs) definiert: Die „Master ECU“ über-

zeugs beeinflussen sowie die Bereiche Batterie-Manage-

nimmt das Sammeln, Aufbereiten und Bereitstellen zentra-

ment und Klimaanlagen.

Bild 2: OBD ist für die ­Module DEM, DCM und FIM bereits verfügbar.

6/25

6/26

6/27

6/28

6/29

ELEKTRONIK & CONNECTIVITY | AUTOMOBIL-ELEKTRONIK

AUTOMOBIL-ELEKTRONIK | ELEKTRONIK & CONNECTIVITY

Steigende Umfänge der Spezifikation: Ganz einfach ist auch Autosar nicht.

hergestellt von einer Zuliefererfirma. Immer wenn bei der Realisierung einer Funktion mehrere Steuergeräte von verschiedenen Herstellern beteiligt waren, erforderte dies zusätzlichen Koordinierungsaufwand und besonders umfangreiche Integrationstests. Ein weiteres Problemfeld entsteht bei einem zusätzlichen oder einem neuen Zulieferer für ein Steuergerät (beispielsweise bei einer neuen Fahrzeuggeneration). Der Aufwand für Abstimmung und Test fällt erneut an.

Mammutprojekt: Die Umstellung auf Autosar ist noch nicht abgeschlossen.

AUTOSAR – FÜR ALLES GEWAPPNET? Zehn Jahre Autosar hat die Welt der Automobil-Elektronik entscheidend geprägt. Heute ist es die Basis für eine effiziente Realisierung von verteilten Funktionen und für die Integration von Software-Komponenten aus verschiedenen Quellen. Doch nur, wenn der komplette Entwicklungsprozess auf dem neuen Standard basiert, stellt sich die gewünschte Produktivität ein. TEX T: Helmut Schelling, Vector Informatik

BILD ER: Vector Informatik

www.mobility20.net/PDF/25758M20

In der Anfangszeit mikrorechnerbasierter Automobil-Elektronik wurde für jede Funktion wie Motormanagement oder Getriebesteuerung ein eigenes Steuergerät entwickelt. Die Koordination mit den anderen Steuergeräten erfolgte über Steuerleitungen, zum Beispiel über pulsweitenmodulierte Signale. Zunehmende Funktionalität trieb die Anzahl und die Kosten der Steuerleitungen nach oben. Daher begann Bosch 1983 mit der Entwicklung eines Netzwerkprotokolls, dem Control-

44

M2.0 1-14 Autosar.indd 44 6/30

ler-Area-Network CAN, das 1990 erstmals in einem Fahrzeug in Serie eingesetzt wurde. Mit der Möglichkeit, umfangreiche Daten in Realzeit zwischen den Steuergeräten auszutauschen, und der Kreativität der Entwicklungsingenieure konnten neben vielen neuen Komfort-Funktionen wie „Keyless Go“ vor allem erhebliche Verbesserungen in den Bereichen Sicherheit, Verbrauch und Abgasemissionen realisiert werden. Nach wie vor galt „für jede Funktion ein Steuergerät“ – entwickelt und

Mobility 2.0 | Ausgabe 1.2014

13.02.14 10:45

Zur Verbesserung dieser Situation haben Automobilhersteller und Zulieferer 2003 das Autosar-Konsortium (AUTomotive Open System ARchitecture) gegründet. Durch Standardisierung sollten Algorithmen unverändert in Steuergeräten verschiedener Hersteller integriert werden können und die Verteilung von Funktionen auf mehrere Steuergeräte sollte deutlich besser unterstützt werden.

Mehr als Basis-Software Zehn Jahre später ist Autosar zu Recht in aller Munde. Über 100 Unternehmen haben in zahlreichen Arbeitsgruppen Spezifikationen entwickelt. Mittlerweile ist die vierte Hauptversion veröffentlicht. Fahrzeuge mit Autosar sind in Serie, viele Automobilhersteller entwickeln Fahrzeuge mit Autosar und nahezu alle anderen zeigen reges Interesse und werden früher oder später auf den Zug aufspringen. Schon zu Anfang war die Begeisterung sehr groß und führte zu teilweise überzogenen Erwartungen. Der Wunsch nach einer einfachen und kostengünstigen Lösung wurde im Laufe der Zeit durch immer umfangreichere Spezifikationen relativiert. Oft wird unter Autosar im Wesentlichen die Basis-Software verstanden. Sie stellt zweifelslos einen wichtigen Bestandteil dar. Sie enthält Betriebssystem, Kommunikations- und Ver-

Mobility 2.0 | Ausgabe 1.2014

M2.0 1-14 Autosar.indd 45

waltungsdienste und stellt zur eigentlichen Applikation eine einheitliche Schnittstelle (Runtime Environment) zur Verfügung. Oft beginnen Automobilhersteller und Zulieferer bei der Migration zu Autosar mit der Basis-Software – ein naheliegender Schritt, denn die Spezifikation der Basis-Software ist gut abgesichert und viele Anbieter stellen Implementierungen bereit. Zudem erlaubt dieser Schritt dem Steuergeräte-Hersteller die Nutzung einer einheitlichen Software-Plattform für mehrere Automobilhersteller. Bei Autosar stand aber bereits zu Beginn der gesamte Entwicklungsprozess im Focus. Deshalb wurden Schnittstellen zwischen den beteiligten Partnern standardisiert und ein Vorgehensmodell definiert. Erst mit dem konsequenten Einsatz aller Elemente von Autosar kann der volle Nutzen erzielt werden.

Neue Arbeitsteilung Während früher der Automobilhersteller für jedes Steuergerät ein textuelles Lastenheft erstellte und mit der Realisierung einen Zulieferer beauftragte, ermöglicht Autosar die Ableitung und Weitergabe von maschinenlesbaren präzisen Vorgaben ausgehend von einem Entwurf des Gesamtsystem „Fahrzeugelektronik“. Unterschiedliche Lieferanten können diese Vorgaben prozesssicher und mit hoher Effizienz umsetzen. Das ermöglicht eine Arbeitsteilung ohne erhöhten Aufwand an den Schnittstellen zwischen den Partnern auf den Ebenen Steuergeräte-Hardware, Basis-Software, Applikationssoftware sowie Integration und Gesamttest. Diese Arbeitsteilung hat eine Vielzahl von Vorteilen. Es können sich auf Teilgebiete spezialisierte Anbieter herausbilden, was zu besseren und gleichermaßen preiswerteren Lösungen führt. Dies reicht von Steuergeräte-Hardware, Anbietern von Basis-Softwarekomponenten bis zu Entwicklungen ein-

45

13.02.14 10:45 6/31

ELEKTRONIK & CONNECTIVITY | AUTOMOBIL-ELEKTRONIK

Durchgängiger Prozess: Software-Entwicklung mit Autosar

zelner Fahrerassistenzsysteme oder auch nur von Teilen eines komplexen Assistenzsystems. Auch kann der Fahrzeughersteller selbst für ihn wettbewerbsrelevante Aufgaben übernehmen und so auch aufwendige Innovationen vorantreiben, ohne dass Wettbewerber über die sonst beteiligten Zulieferer zeitnah von der Entwicklung profitieren. Darüber hinaus ermöglicht die klare Strukturierung des Gesamtsystems ein hohes Maß an Wiederverwendung von einzelnen Komponenten. Die Einführung der neuen Methode erfordert eine Umstellung der Vorgehensweisen bei allen Beteiligten in der Zulieferkette. Bei Autosar ist ein konsequentes Frontloading notwendig. Der jeweilige (Sub-)Auftraggeber muss seine Vorgaben deutlich genauer und formaler formulieren. Das erfordert gegenüber dem heutigen Vorgehen ein erhebliches Umdenken sowie eine Verschiebung von Verantwortungen und Aufgaben und damit einen industrieweiten Veränderungsprozess, der an vielen Stellen Schmerzen bereitet. In der Übergangszeit entsteht in der Zulieferkette mit deutlich mehr Beteiligten oft ein weit größerer Koordinierungsaufwand. Dies birgt Risiken. Eine Kette ist eben so stark wie ihr schwächstes Glied. Kurzfristige Änderungswünsche und rasche Fehleranalysen können bei den zahlreichen beteiligten Stellen zur Herkulesaufgabe werden. Projekte in dieser Phase führen mancherorts zu dem Eindruck, dass Autosar nicht hält, was es verspricht, und zu Zusatzkosten führt. Wie bei jedem Veränderungsprozess muss zunächst das „Tal der Enttäuschungen“ durchschritten werden. Ziel muss es daher sein, die Änderungen „im laufenden Betrieb“ so schnell und konsequent wie möglich abzuschließen. Diejenigen Fahrzeugentwicklungen, die auf Grund der Reife der Beteiligten durchgehend mit der Autosar-Methodik entwickelt wurden, zeigen deutlich, dass sich der Aufwand lohnt. Es muss das Ziel sein, das „Plateau der Produktivität“ möglichst schnell zu erreichen. Dafür kann eine leistungsstarke Tool-Chain einen entscheidenden Beitrag bringen. Parallel zur Autosar-Spezifikation mussten die Entwicklungswerkzeuge erarbeitet werden. Sie sind daher bei ersten Einsätzen nicht immer ganz ausgereift. Dadurch, dass in den letzten Jahren zunehmend Stabilität bei den Autosar-Spezifikationen erreicht wurde und Erfahrungen aus vielen Serienprojekten einfließen konnten, sind inzwischen sehr leistungs-

46

M2.0 1-14 Autosar.indd 46 6/32

fähige Tools für den Produktiveinsatz verfügbar. Als Beispiel sei hier „PREEvision“ erwähnt. PREEvision ist eine Entwicklungsplattform für den gesamten E/E-Produktentwicklungsprozess nach Autosar. Es integriert Entwurf, Bewertung, Optimierung und Dokumentation von E/E-Architekturen in einem Werkzeug. Es exportiert und importiert die Schnittstellendefinition im Autosar-Format. Für eine ganzheitliche Unterstützung der E/E-Entwicklungsbereiche sind weiter Komponenten von der Anforderungsanalyse über die Bereitstellung einer Kollaborations-Plattform bis hin zur Verwaltung von Varianten notwendig. Jeder Standard, auch Autosar, birgt die Gefahr, dass er Innovationen bremst. Das aktuelle Beispiel „Ethernet im Fahrzeug“ zeigt, dass dies durch pragmatisches Vorgehen verhindert werden kann. Der Standard wird parallel zu den ersten Implementierungen entwickelt. Das fördert die schnelle Definition eines praxisgerechten Standards und erlaubt eine rasche Markteinführung. Dafür nimmt man in Kauf, dass die ersten Implementierungen auf einem vorläufigen Stand basieren und damit zusätzlicher Aufwand für spätere Anpassungen anfällt.

Kein Selbstzweck Autosar ist die konsequente Fortführung und Standardisierung der über die letzten Jahrzehnte entstandenen Entwicklungsmethodik für Automobil-Elektronik. Autosar setzt auf etablierten und bewährten Vorgehensweisen auf und nutzt neueste Software-Technologien, um die neue Generation von Fahrzeugfunktionen entwickeln zu können. Allerdings darf die Standardisierung kein Selbstzweck sein. Es gilt genau zu beobachten, inwieweit die Vorteile mögliche Nachteile ausgleichen und ob möglicherweise disruptive Technologien die etablierten Spieler bedrängen. Anzeichen hierfür gibt es: Man denke nur an neue Anbieter von Elektrofahrzeugen oder das autonom fahrende Auto von Google. ☐ > MORE@CLICK 25758M20

Helmut Schelling, Mitgründer und Geschäftsführer der Vector Informatik GmbH

Mobility 2.0 | Ausgabe 1.2014

13.02.14 10:45

ENTWICKLUNGSPROZESSE

ENTWICKLUNGSPROZESSE

rieren, zum Beispiel über Massenoperationen. Außerdem zeigt ein solcher Editor die Parameter FIBEX FIBEX SWC thematisch gruppiert LDF LDF an – auch über MoOEM TIER 1 OEM TIER 1 dulgrenzen hinweg. DBC DBC Über grafische Darstellungen trägt der Spec Spec Editor zum VerständStd.SYSD BSW MCAL SW nis der komplexen TIER 2 BSW TIER 2 MCAL TIER 2 Konfiguration bei. Solche Werkzeuge sind hilfreich und nöBild 1. Rollen in einem AUTOSAR-Entwicklungsprojekt. tig bei allen Domä(alle Bilder: Vector Informatik) nen der Basis-Software wie Kommunitraction Layer Modules (TIER2-MCAL). kation, Mode Management, Diagnose, Das bedeutet zunächst einmal mehr Memory Management oder I/O. Über Abstimmungsaufwand bei der Konfigueinen Editor im Bereich der Memoryration. Domäne fügt der Entwickler beispielsweise recht einfach einen Speicherblock Software-Werkzeuge als Helfer hinzu, der dann konsistent im Non-Volatile RAM Manager (NvM) wie auch in Der AUTOSAR-Standard entwickelt sich der Flash EEPROM Emulation (Fee) konhoch dynamisch weiter. Mit jedem Refiguriert ist. Der Overhead aus dem Verhältnis Nutzdaten zu Blockgröße lease gibt es Änderungen: Der Funktionsumfang existierender BSW-Module lässt sich durch eine grafische Darsteländert sich oder es werden neue Molung leicht abschätzen (Bild 2). dule definiert. Alle diese Module brinZusätzlich helfen Assistenzfunktionen beim Konfigurieren. Ändert der gen ihre eigenen Konfigurationsparameter mit sich. Mit formal beschreibbaEntwickler zum Beispiel einen Parameren Modulstrukturen und Parametern ter, werden die davon abhängigen Pawird das AUTOSAR-Konfigurationskonrameter durch ein Regelwerk automazept dieser Dynamik grundsätzlich tisch korrekt gesetzt. Für komplexere gerecht. Damit ist das schnelle und Aufgaben wie dem Mapping von Runeinfache Definieren von Basic Software nable Entities auf Betriebssystem-Tasks Module Descriptions (BSWMD) möglich, unterstützen Assistenten, bei denen der die in einer BSW-Lieferung enthalten sind. Diese formale Methode klingt zunächst verlockend für einen Werkzeug-Ansatz: Der Hersteller entwickelt mit überschaubarem Aufwand ein generisches Werkzeug, über das sich grundsätzlich alle Parameter einzeln konfigurieren lassen – und zwar die heute bekannten wie auch alle zukünftigen. Niemand möchte allerdings ohne weitere Unterstützung Tausende von Parametern über einen solchen Editor einstellen. Traditionelle Rollen im Entwicklungsprozess

Komfortable Konfiguration von AUTOSAR-Steuergeräten Das simple CAN-Steuergerät war gestern. Mittlerweile nutzt ein typisches Steuergerät viele Funktionen der AUTOSAR-Basis-Software, um seine komplexen Aufgaben zu erfüllen. Je mehr Funktionen, desto schwieriger und umfangreicher ist aber auch der Konfigurationsprozess. Ohne Werkzeugunterstützung wäre der Entwickler verloren. Von Matthias Wernicke

W

ährend der Entwicklung des Steuergerätes werden Teile der Software auf Basis einer spezifischen Konfiguration generiert. Drei Faktoren beeinflussen die Komplexität dieser Steuergeräte-Konfiguration: aus Elektronik automotive 4.2014

6/34

Mehr Standardisierung: Durch AUTOSAR ist mittlerweile ein großer Anteil der Steuergeräte-Software als BasisSoftware standardisiert. Das AUTOSARPrinzip „Konfigurieren statt Codieren“ zwingt die Entwickler allerdings dazu, von vornherein eine konsistente Ge-

samtkonfiguration zu erstellen. Eine Korrektur direkt im Code ist nicht vorgesehen. Mehr Funktionen: Durch neue Mikrocontroller mit mehreren Cores und Speicherschutz-Features oder durch neue Netzwerktechnologien wie Ethernet steigt der Umfang der Basis-Software und damit auch der Konfigurationsbedarf. Neue Zusammenarbeits-Modelle: Die AUTOSAR-Methode fördert neue Rollen im Entwicklungsprozess (Bild 1). Neben dem Zulieferer für die AUTOSARBasis-Software (TIER2-BSW) gibt es auch Zulieferer für Applikations-SoftwareKomponenten (TIER2-SWC) oder die Hardware-nahen Microcontroller Abs-

Rollen in einem komplexen AUTOSAR-Projekt TIER 2 SWC

Entwickler die Runnable Entities der Software-Komponenten (Software Components, SWCs) auf Basis ähnlicher Trigger-Bedingungen auswählt, einer Task zuordnet und schließlich die Ausführungsreihenfolge innerhalb der Task definiert. Ein weiteres Beispiel aus der ModeManagement-Domäne: Das BswMModul in AUTOSAR 4 erlaubt eine völlig freie Konfiguration von Arbitrierungsregeln, logischen Ausdrücken und Aktionen, um auf Mode-Änderungen in anderen BSW-Modulen zu reagieren oder um selbst Mode-Änderungen anzufordern. Über eine Assistenzfunktion wird nun zum Beispiel der BSW Mode Manager (BswM) so konfiguriert, dass er sich ähnlich verhält wie der relativ einfach zu beherrschende ECU State Manager (EcuM) aus AUTOSAR 3.

Ableiten von Parametern Die Konfiguration der Kommunikationsmodule für CAN, LIN, FlexRay oder Ethernet muss zu der vom OEM stammenden Systembeschreibung passen. AUTOSAR sieht hierfür vor, dass eine Basiskonfiguration (Base EcuC) der Module aus einem ECU-spezifischen Extrakt der Systembeschreibung (System Extract) abgeleitet wird. In der Praxis sieht die Situation allerdings etwas komplizierter aus (Bild 3): AUTOSAR hat ein Standardformat für die Systembeschreibungen definiert. Neben diesem Format setzen die OEMs aber auch die traditionellen Formate DBC, LDF und

Spezifische Editoren und Assistenzfunktionen Es gibt einige Ansätze, wie ein SoftwareWerkzeug diese Arbeit erleichtert. Ein spezifisch entwickelter Editor stellt den Zusammenhang zwischen den Parametern dar und vereinfacht das Konfigu-

Bild 2. Komfort-Ansichten helfen beim Konfigurieren des Steuergerätes. aus Elektronik automotive 4.2014 6/35

ENTWICKLUNGSPROZESSE

FIBEX ein. Außerdem verwendet der Tier 1 möglicherweise eigene Systembeschreibungen, etwa für private CANBusse innerhalb des Steuergerätes oder für LIN-Busse zur Anbindung von Sensoren. Das Software-Werkzeug muss also alle möglichen Arten von Eingangsdaten erkennen, durch geeignetes Vorverarbeiten die traditionellen Formate konvertieren und ECU-spezifische Extrakte erzeugen. Auch das Zusammenfügen von mehreren separaten Systembeschreibungen zu einer gemeinsamen Beschreibung muss möglich sein. Erst dann kann das Generieren der Base EcuC starten. Ähnliches gilt für die Diagnosemodule: Die Konfiguration der Module muss zur ODX-Spezifikation des Steuergerätes passen. Daher muss auch die ODX-Datei in die Base EcuC einfließen. Manchmal hat der Tier 1 eine Standardkonfiguration für seine Projekte, die direkt im EcuC-Format vorliegt. Auch diese Konfigurationsanteile sollten im Base EcuC enthalten sein. Die vom Werkzeug zum Überprüfen der Konfiguration benötigten BSWMDDateien können aus verschiedenen Quellen stammen: Sie werden entweder vom TIER2-BSW zur Verfügung gestellt oder zum Beispiel vom MikrocontrollerHersteller passend zu den MCAL-Modulen geliefert. Die SWCs schließlich können im System Extract enthalten sein, den der Automobilhersteller seinen Zulieferern zur Verfügung stellt. Gemäß der AUTOSAR-4-Methode wird aus dem System Extract zunächst ein ECU Extract erzeugt, der eine flache Sicht auf die SWCs darstellt. Anschließend wird der ECU Extract um weitere SWCs erweitert, die zum Beispiel externe Zulieferer (TIER2SWC) bereitstellen. Auf Basis des ECU Extract und der Base EcuC erstellt der Steuergeräteentwickler die Gesamtkonfiguration der BSW und der Laufzeitumgebung (Runtime Environment, RTE). Das Werkzeug

SWC 1

SWC 2

FunktionsEntwickler 1

RTE OS

CAN

FunktionsEntwickler 2

MEM

BSW AUTOSAR ECU

SoftwareIntegrator

Bild 4. Entwicklung von „vertikalen“ Steuergeräte-Funktionen. aus Elektronik automotive 4.2014 6/36

ENTWICKLUNGSPROZESSE

Systembeschreibungen (Kommunikation, SWCs) ARXML

ARXML

System Description

System Extract

DBC

LDF

Software-Komponenten ARXML SWC DaVinci Configurator Pro

FIBEX

LegacyFile Kommunikations-Datenbanken Conversion OEM SystemExtract TIER 1 Generation Systembeschreibungen (Diagnose, weitere Vorgaben)

ARXML System Extract

ECUEXGenerierung und -Update

ARXML ECU Extract

SWCIntegration

SystemExtract Merge ECUCUpdate

ARXML Projekt-StandardKonfiguration CDD

OEM TIER 1 TIER 2 SWC

Base ECUCGenerierung

ODX

ARXML ECUC

BSW- und RTEKonfiguration

ARXML

Diagnose-Daten OEM TIER 1

Base ECUC Moduldefinitionen

Pro BSW-Modul ARXML ARXML ARXML

TIER 2 SW

Param- Pre- RecDef Config Config

ARXML BSWMD OEM für TIER 1 TIER 2 HW Drittmodelle

ARXML AUTOSAR Standard ParamDef

Bild 3. Workflow für das Erstellen und Aktualisieren einer Steuergeräte-Konfiguration am Beispiel des DaVinci Configurator Pro von Vector Informatik. sollte hierbei diejenigen Parameter, die aus dem Base EcuC übernommen worden sind, als schreibgeschützt darstellen, um Abweichungen vom System Extract zu vermeiden.

Projekt-Update Während der Projektlaufzeit erhält der Entwickler immer wieder Updates der Eingangsdaten. Typischerweise kommen diese Updates zu verschiedenen Zeitpunkten und unterschiedlich oft. Der OEM verteilt neue Systembeschreibungen passend zu den jeweiligen Meilensteinen der Fahrzeugentwicklung, während die Diagnosebeschreibung in der Regel wesentlich häufiger aktualisiert wird. Oft liegt nur eine kurze Zeitspanne zwischen dem Erhalt der Systembeschreibung und dem Abgabetermin. Ein Werkzeug muss daher in der Lage sein, die Konfiguration möglichst automatisch mit den neuen Eingangsdaten zu aktualisieren. Durch ein Projekt-Update wird dabei ein neues Base EcuC erzeugt und die eigentliche Konfiguration damit abgeglichen. Aber was passiert bei Fehlern in der Systembeschreibung? Selbst nach Klärung der Probleme mit dem OEM ist eine korrigierte Systembeschreibung

meistens nicht sofort verfügbar. In solchen Fällen möchte der Steuergeräteentwickler manche der abgeleiteten Parameter bewusst ignorieren und mit einem anderen Wert überschreiben. So kann er den Fehler direkt in der ECUKonfiguration beheben. Weil eine solche Abweichung immer kritisch ist, sollte der Steuergeräteentwickler über sein Werkzeug den Zustand explizit auf „user-defined“ setzen können. Solange der Parameter in diesem Zustand ist, darf das Werkzeug dessen Wert auch bei einem erneuten Update nicht überschreiben. Erst wenn der Steuergeräteentwickler den Status „user-defined“ zurücknimmt, fällt der Parameter auf den abgeleiteten Wert zurück. Auch bei der Abstimmung zwischen dem Steuergeräteentwickler und dem OEM hilft das Werkzeug, zum Beispiel indem es einen Report über die überschriebenen Parameter erzeugt.

Merge-Funktion für paralleles Arbeiten mit mehreren Entwicklern Selbst in kleineren Steuergeräte-Projekten arbeiten immer mehrere Entwickler gleichzeitig am Projekt. Wenn die Zuständigkeiten klar getrennt sind – beispielsweise „Kollege xy ist immer für das Betriebssystem verantwortlich“

Komfort-Editoren betrachten, mit denen er auch die Konfiguration erstellt hat. So fühlt er sich zu Hause und muss sich nicht erst mühsam in eine andere Darstellung der Daten einarbeiten. Trotzdem gilt die Devise: Je weniger Änderungen zusammenzufügen sind, desto besser. Massive Änderungen an der Konfiguration Bild 5. Diff/Merge-Unterstützung in DaVinci Configurator Pro. entstehen zum Bei–, lassen sich parallele Änderungen am spiel durch ein Projekt-Update auf eine gleichen Modul oder an der gleichen neue Kommunikations-Matrix (K-Matrix). Software-Komponente vermeiden. Daher empfiehlt sich folgende VorgeTypisch ist allerdings eher eine Arbeitshensweise: Ausgehend von einem Inteweise, bei der die Entwickler parallel grations-Meilenstein MS0 entwickeln jeweils eine Steuergeräte-Funktion die Feature-Entwickler jeweils auf einem entwickeln, die sich vertikal durch alle eigenen Zweig (Bild  6). Die Zweige Architekturschichten der Steuergerätewerden nacheinander im Hauptzweig Software durchzieht (Bild 4). Zu Zeiten zusammengefügt – eventuell auch in der manuellen C-Codierung hat der mehreren Zwischenschritten (MS1 bis Integrator die unterschiedlichen StänMS3). Erst dann führt der Integrator ein de anschließend textuell zusammenProjekt-Update auf eine neue K-Matrix gefügt. Mit AUTOSAR bedeutet das durch (MS4). Danach lassen sich neue allerdings, dass der Integrator XMLZweige ziehen und Funktionen passend Dateien im AUTOSAR-Format zusamzur neuen K-Matrix entwickeln. Das Ganze kann durch ein Konfigurationsmenfügen muss, die viele Megabytes groß sein können. Mit herkömmlichen management-System (CM) unterstützt XML-Werkzeugen lässt sich eine AUTOwerden, das auch die ImplementieSAR-Konfiguration praktisch nicht verrungsdateien der SWCs verwaltet. gleichen oder zusammenfügen. Die Struktur der Datei und die vielen RefeVerfügbare Werkzeuge renzen innerhalb der Datei sind dazu Das Werkzeug DaVinci Configurator Pro viel zu kompliziert. Hier hilft nur ein AUTOSAR-Werkvon Vector Informatik ermöglicht die zeug, das die Unterschiede in der AUbeschriebene Arbeitsweise. In der komTOSAR-Konfiguration übersichtlich menden Version lassen sich mit dem darstellt und Merge-Optionen anbietet DaVinci Configurator Pro zudem Konfigu(Bild 5). Idealerweise kann der Anwenrationsvarianten erstellen, die dynamisch der die Unterschiede direkt in den im Steuergerät umgeschaltet werden – sogenannte PostBuild-Selectable-Varianten. Auch hierbei gilt es, die verfügbaren AUTOSAR-Konzepte geschickt in Werkzeug-Funktionen umzusetzen. MS0 MS1 MS2 MS3 MS4 CM Damit erhält der Entwickler weitere wertvolle Unterstützung K-Matrix K-Matrix für die Entwicklung (Version 1) (Version 2) von AUTOSAR-ProBild 6. Paralleles Arbeiten an der gleichen Steuergeräte-Konfiguration. jekten. eck

Dipl.-Ing. (FH) Matthias Wernicke war nach Abschluss seines Studiums der Industrieelektronik an der FH Ulm zunächst vier Jahre im Daimler-Forschungszentrum in Ulm tätig. Seit Anfang 2000 arbeitet er bei Vector Informatik in Stuttgart an der Entwicklung von Methoden und Werkzeugen für den Entwurf verteilter Elektronikfunktionen im Kfz. Er ist heute für das Produkt-Management der DaVinci-AUTOSAR-Werkzeuge verantwortlich.

aus Elektronik automotive 4.2014 6/37

Safety automotive

Safety automotive

OS Application

ISR

Runnable

Runnable

Runnable

Task

Runnable

SWC

Task

Runnable

Runnable

Runnable Task

Task

Runnable

OS Application

Core 1

Core 2

Bild 1: Der Entwickler fasst die Tasks in OS Applications zusammen und verteilt sie auf die Kerne. (alle Bilder: Vector Informatik)

aus funktionale sicherheit Juli 2014 6/38

Lockstep Mode Beim Lockstep Mode führen zwei Kerne identischen Code aus. Ein unabhängiger Komparator vergleicht die Ergebnisse und erzeugt bei Unterschieden einen Fehler-Trap. Das weitere Vorgehen hängt

Eine perfekte Störungsfreiheit ist nur dann erreichbar, wenn die Hardware über eine Memory Protection Unit (MPU) verfügt. Sie sorgt dafür, dass die Anwendungsteile nur auf vordefinierte Speicherbereiche zugreifen können (Bild 3). Diese Speicherbereiche sind für jeden Kern getrennt definiert, müssen sich aber die Hardware-Resourcen (RAM

Application 2

SWC a

SWC b

Application 3

Application 4

SWC d

SWC e

SWC c

Check point

Check point

Check point

Program Flow Monitor Watchdog Manager ECU State Manager SYS

COM

I/O

Program Flow Monitor

V2G CAN LIN

FR ETH AVB

XCP EXT

MCAL Core 1

OS Multi Core

LIBS

RTE

Watchdog Manager Satellite ECU State Manager Satellite Core Test

Complex Driver

muss der Entwickler beim Verteilen der Software-Module darauf achten, die gemeinsame Ressourcennutzung über Kerngrenzen hinweg zu minimieren. Bei den Ressourcen handelt es sich um Hardware-Register und – in den meisten Fällen – um Datenbereiche. Die Herausforderung bei der kernübergreifenden Ressourcennutzung ist nicht die Zugriffskoordination, sondern das Vermeiden von Wartezuständen bei konkurrierendem Zugriff auf die gemeinsamen Ressourcen. In so einem Fall geht die unabhängige Datenverarbeitung verloren und der Nutzen der Parallelisierung vermindert sich.

Application 1

Speicherschutz und sichere Kommunikation im Steuergerät

LIBS

D

er Hauptgrund für die Einführung von Multicore-Architekturen ist das Erhöhen der Rechnerleistung, ohne die Taktfrequenz anheben zu müssen. Dieses Ziel wird aber nur erreicht, wenn sich ein ausreichender Anteil der Anwendungs-Software parallelisieren lässt. Die klassische Referenz hierzu ist Amdahls Gesetz. Hieraus ergibt sich zum Beispiel für einen Dual-Core-Prozessor und eine Software mit einer Parallelisierbarkeit von 50 Prozent eine maximale Leistungssteigerung von nur 30 Prozent im Vergleich zu einer Single-Core-Architektur. Um eine bestmögliche Rechenleistung zu erreichen,

Das Berücksichtigen der Anforderungen an die funktionale Sicherheit nach ISO 26262 ist inzwischen fester Bestandteil des Entwicklungsprozesses im Automobilbau. Auf Basis der Gefahren- und Risikoanalyse werden die Anforderungen an die Funktionen eines Steuergeräts bezüglich ihrer Sicherheitsrelevanz bewertet und der passende Automotive Safety Integrity Level (ASIL) wird zugeordnet. Wie wirkt sich das auf eine Multicore-Software-Architektur aus, wenn sicherheitsrelevante Funktionen umzusetzen sind? Vor der Beantwortung dieser Frage ein paar Hinweise zum Lockstep-Konzept für Multicore-Prozessoren, das in vielen Safety-Projekten zum Einsatz kommt.

Die Multicore-Architektur lässt sich zur Erhöhung der Rechnerleistung oder bei sicherheitsrelevanten Systemen auch zur parallelen Realisierung von diversitären Algorithmen wie ASIL-Dekompositionen verwenden. Der Entwickler ordnet die Software-Module gemäß Parallelisierbarkeit und abhängig vom Sicherheitskonzept den in AUTOSAR definierten OS Applications zu. Diese lassen sich den in der ISO 26262 definierten Partitionen gleichsetzen. Dabei handelt es sich um Bereiche innerhalb eines Steuergerätes, die störungsfrei voneinander ablaufen müssen – Freedom from Interference. In MulticoreSteuergeräten werden die OS Applications den unterschiedlichen Rechnerkernen zugewiesen (Bild  1). Für den Entwickler spielt es keine Rolle, ob das Ziel der Aufteilung die Parallelisierbarkeit oder die Dekomposition ist: Er muss einen störungsfreien Ablauf zwischen den OS Applications herstellen. Das erfordert im Wesentlichen das Überwachen von Laufzeiten und Vermeiden einer fehlerhaften Änderung von sicherheitsrelevanten Speicherinhalten.

MEM

Von Helmut Brock und Joachim Kalmbach

Funktionale Sicherheit nach ISO 26262

AUTOSAR spezifiziert mit der Betriebssystemklasse SC2 eine Laufzeitüberwachung. Diese greift allerdings für sicherheitsrelevante Anwendungen zu kurz. Das AUTOSAR-Betriebssystem prüft zwar, dass keine Task übermäßige Laufzeit beansprucht oder Interrupts zu lange sperrt, aber die Konfiguration der korrekten und sicheren Task-Reihenfolge und des Task Triggering stellt für den Entwickler eine sehr hohe Komplexität dar, die schwer abzusichern ist. Von den Firmen TTTech und Vector Informatik gibt es eine alternative Lösung. Diese besteht aus einem nach ASIL-D entwickelten Program Flow Monitor, der die Ausführungszeiten und -reihenfolge der Tasks und der darin enthaltenen Funktionen überwacht. Für jeden Kern wird eine Instanz dieses Program Flow Mo-

DIAG

Zur Zeit dominieren zwei Themen die Software-Entwicklung für Fahrzeugsteuergeräte: zum einen das zunehmende Umstellen der Rechnerarchitekturen auf Multicore-Prozessoren und zum anderen die Sicherheitsbetrachtungen nach ISO 26262. Jedes dieser beiden Themen ist schon für sich alleine komplex genug – was ergibt sich da erst aus der Kombination?

Multicore-Architektur mit verteilter Software

Überwachen der Laufzeit

AMD

AUTOSAR goes Multicore – mit Sicherheit

von der Hardware und dem Sicherheitskonzept des Steuergeräts ab. Die Hardware muss so ausgelegt sein, dass sie nach dem Auftreten des Fehler-Trap einen sicheren Zustand erreicht. Weil beide Kerne identischen Code ausführen, sind außer der Fehlerbehandlung keine Erweiterungen der Software bezüglich Multicore notwendig. Anders formuliert: Auch wenn hier mehrere Kerne zum Einsatz kommen, handelt es sich nicht um eine Multicore-Architektur, die zur Leistungssteigerung beiträgt.

Complex Driver

Runnable

SWC

ISR

Runnable

Task

Runnable

Runnable Task

OS Application

SWC

Task

Runnable

Runnable

Runnable

ISR

Task

Runnable

SWC

SWC

Task

Task

Runnable

SWC

nitor angelegt. Die Informationen über die Funktionsausführung erhält der Monitor durch die in der Software eingefügten Checkpoints (Bild  2). Nur wenn die sicherheitsrelevanten Programmteile korrekt abgearbeitet werden, werden diese Checkpoints in der richtigen Reihenfolge und mit dem richtigen Timing durchlaufen. Der zentrale Watchdog Manager sammelt die Statusmeldungen aller Monitore und triggert den Watchdog. Es ist nicht möglich, jeden Kern separat zu verwalten, weil die Tasks oft über Kerngrenzen hinweg voneinander abhängen. Zum anderen erlaubt die AUTOSAR-Spezifikation nur einen gemeinsamen Neustart aller Kerne. Deshalb muss der Watchdog Manager als zentrales Modul für das gesamte Steuergerät entwickelt werden. Die Monitore selber laufen dagegen auf jedem Kern unabhängig ab und sind in der Lage, ihren Status über Kerngrenzen hinweg dem Watchdog Manager mitzuteilen.

Core 2

Bild 2: Das Flow Monitoring stellt zusammen mit den Checkpoints in der Applikation die korrekte Ablaufreihenfolge sicher. aus funktionale sicherheit Juli 2014 6/39

Safety automotive

usw.) mit den anderen Kernen teilen. Das Betriebssystem hat hierbei eine zentrale Rolle: Bei jedem Task-Wechsel muss es die MPU umprogrammieren, damit ein Wechsel der Speicherpartition erfolgt. Dieser für den Kontextwechsel zuständige Teil des Betriebssystems ist eine sicherheitsrelevante Komponente und muss in jedem Fall der höchsten erforderlichen Sicherheitsstufe entsprechen. Der Schutz vor fehlerhaftem Datenüberschreiben ist das eine. Das andere ist die Notwendigkeit eines korrekten Datenaustausches zwischen den Tasks und über verschiedene Prozessorkerne hinweg. Im AUTOSAR-Architekturmodell erfolgt ein solcher Datenaustausch zwischen zwei Tasks über den Virtual Function Bus (VFB). In der Implementierung wird der VFB durch das Runtime Environment (RTE) dargestellt. Für ein sicherheitsrelevantes Steuergerät mit Multicore-Architektur werden folgende zusätzliche Anforderungen an die RTE gestellt: Sie muss die Kommunikation über Speicherpartitionen hinweg ermöglichen und dabei unterscheiden, ob ein Kommunikationsweg über Kerngrenzen hinweg (Inter-Core) oder zwischen zwei auf demselben Kern ablaufenden Tasks (Intra-Core) verläuft. Eine Datenübertragung über Kerngrenzen hinweg erfordert zusätzliche Koordinationsmechanismen. Das Betriebssystem stellt der RTE hierfür eine InterOS-Application Communicator (IOC) genannte Funktion bereit. Diese erlaubt den Datenaustausch zwischen Tasks und Interrupt-Service-Routinen auf verschiedenen Kernen.

Nutzung von Standardlösungen Das Gewährleisten von funktionaler Sicherheit nach ISO 26262 auf MulticoreSteuergeräten scheint also keine ganz einfache Aufgabe zu sein. Das Rad muss allerdings nicht neu erfunden, sondern korrekt verwendet werden. Steuergeräteentwickler erhalten von Vector Informatik und TTTech Betriebssysteme, RTE und Program Flow Monitoring für Multicore-Architekturen bis ASIL D. Generell sind Multicore-Systeme deutlich komplexer als Single-CoreLösungen. Das muss jedoch nicht für die Konfiguration der Basis-Software gelten: Nach dem Verteilen der Software auf die Prozessorkerne ist der weitere Konfigurationsaufwand für ein Multicore-System bei optimaler Werkzeug-

Core 1

MPU

RAM

Application A - Task 1

Task 1 - Stack - Application Data

Application B - Task 2

Task 2 - Stack - Application Data

Core 1

Task 3 - Stack - Application Data

Application C - Task 3

Bild 3: Die Memory Protection Unit sorgt dafür, dass die Anwendungsteile nur auf vordefinierte Speicherbereiche zugreifen können. Unterstützung nicht schwerer als für eine Single-Core-Architektur. Der Entwickler fasst Tasks, Interrupt-ServiceRoutinen und ähnliches in Containern, den OS Applications, zusammen. Diese OS Applications weist er anschließend den Prozessorkernen zu. Im Konfigurationswerkzeug DaVinci Configurator Pro von Vector Informatik sind das nur wenige Klicks. Der integrierte RTE-Generator kümmert sich selbsttätig darum, die richtigen Kommunikationsmethoden, Intra- oder Inter-Core, zwischen den Software-Modulen einzurichten. Es gibt also bereits viel Unterstützung für Multicore-Steuergeräte wie Basis-Software und Konfigurationswerkzeuge. Für die Erstellung der SoftwareArchitektur und Verteilung der Software-Anteile auf die Prozessorkerne ist eine gute Werkzeugunterstützung weit schwieriger zu realisieren. Sie ist auch zumeist auf die Bewertung von Varianten beschränkt. Hier sind auf absehbare Zeit weiterhin das Experten-Knowhow und die Erfahrung des Steuergeräteentwicklers gefragt. eck

AUTOSAR-Steuergeräte erfolgreich entwickeln Von den Anforderungen bis zur Serie

Dr.-Ing. Helmut Brock ist seit 1999 bei Vector Informatik und dort als Produktmanager Betriebssysteme tätig. [email protected]

Sichern Sie sich mit der Vector Lösung für AUTOSAR den entscheidenden Entwicklungsvorsprung. > Projektspezifisch abgestimmte Basissoftware, verfügbar für eine große Anzahl an Mikrocontrollern > In allen Phasen effizient entwickeln mit einer intelligenten Werkzeugkette

> Reduzierte Entwicklungs- und Zertifizierungsaufwände für Steuergeräte nach ISO 26262 bis ASIL D > Vollumfänglich testen: Von der Freigabe des ersten Softwaremoduls bis hin zum Integrationstest > Schneller am Ziel durch professionelle und

Dipl.-Ing. (FH) Joachim Kalmbach

> Leistungsstarke Security-Funktionen schützen das

ist seit 2006 bei Vector Informatik und dort als Produktmanager im Bereich Embedded Software tätig. Seine Themenschwerpunkte sind AUTOSAR

Nutzen Sie die Vorteile der praxiserprobten Produkte sowie die Erfahrung von Vector für die Entwicklung

Steuergerät vor unautorisierten Zugriffen

maßgeschneiderte AUTOSAR-Dienstleistungen

Ihrer serienreifen Steuergeräte. Infos und Downloads: www.autosar-solutions.de

und Multicore. [email protected]

aus funktionale sicherheit Juli 2014 6/40

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Figure 1: AUTOSAR structure

AUTOSAR-compliant Development of an In-car Radio Product Using MICROSAR for the European Market Alpine Electronics, Inc. (“Alpine”), manufacturer of car audio and navigation systems, developed an AUTOSAR-compliant in-car radio product for a European automotive manufacturer for series production in 2013. Alpine completed development of AUTOSAR related software components for CAN, diagnostics and other functions within one year starting from October 2010 and then also completed development of other software components. By using MICROSAR from Vector Japan Co., Ltd. (“Vector”) as the AUTOSAR platform and developing a proprietary wrapper that leveraged existing software assets, Alpine succeeded in its product development while meeting a tight schedule and high quality demands.

AUTOSAR Enables Sharing of Automotive Embedded

tomotive embedded software as assets. AUTOSAR is a sys-

Software as Assets

tem that abstracts the differences in hardware, such as

Electronics becomes more widely used in automotive sys-

microcontrollers, and enables a standardization and reuti-

tems, such as power-train, safety functions, and infotain-

lization of in-car application software assets, in short.

scribed the challenges. “We were asked to build an in-car

on combination of in-house solutions, Alpine contracted

radio for a European automobile manufacturer, and they

MICROSAR BSW modules. Alpine used MICROSAR SYS for

specified as part of the RFQ that it must be developed in

its error reporting, communication management, and ECU

compliance with AUTOSAR Release 3.0. We had never

state management, MICROSAR MEM for managing flash

developed any product using AUTOSAR, so it was our first

memory, and MICROSAR CAN and MICROSAR COM for its

time.” Also this particular in-car radio uses a Renesas SH2A

CAN control. They did not use any AUTOSAR runtime envi-

microcontroller, with existing software assets based on

ronment (RTE), because a large number of changes were

µITRON (see Figure 2). Alpine immediately began work on

expected in reuse of the existing software assets. Also, be-

introducing AUTOSAR. For the development infrastructure,

cause the conventional µITRON-based operating system

the company selected MICROSAR, the AUTOSAR-based

would be utilized, MICROSAR OS was not used. The entire

embedded software products developed by Vector. Kusano

configuration is shown in Figure 3. MCAL (Microcontroller Ab-

explained. “We selected MICROSAR because Vector is one

straction Layer), which abstracts the microcontroller hard-

of the suppliers recommended by the European automobile

ware, was not supplied from the microcontroller vendor at

manufacturer and because we had worked with Vector in

the start of development, so it was developed at Alpine.

the past on CAN bus-related development.”

As mentioned above, Vector’s MICROSAR was chosen as

Next, Alpine consulted with Vector and gained an understand-

the BSW modules. The Complex Drivers, which is highly de-

ing of the functions realized by the basic software (BSW)

pending on the vehicle variants, was provided by the auto-

of AUTOSAR. After analysis to extract minimum set of

mobile manufacturer. The software components (SW-C),

BSW regarding with required functionalities and possibility

which are equivalent to the application layer, were developed by Alpine using existing assets based on µITRON.

ment. The transition from conventional mechanical and

6/42 6/44

hydraulic systems to E/E architecture will never stop ad-

MICROSAR Selected at the Recommendation

vancing in the future. While evolving electronics enrich the

of European Automobile Manufacturer

automotive functions, the number of man-hours required to

AUTOSAR brings certain advantages on high efficiency on

develop the control software are higher than ever before,

automotive software development. However, for manufac-

creating a significant burden on automobile manufacturers

turers and suppliers using it for the first time, it’s not really

and suppliers. To deal with this situation, the open and

easy to read through all the specifications and understand

standardized automotive software architecture AUTOSAR

the full picture. It is also challenging to understand the

(AUTomotive Open System ARchitecture) (see Figure 1)

detailed development activities.

was jointly developed by automobile manufacturers, sup-

Alpine was among one of those car audio and navigation

pliers, electronics manufacturers, semiconductor vendors,

system companies struggling to go with AUTOSAR. Tomohiro

and software vendors, to aim enhancement of reuse of au-

Kusano (Alpine’s OEM Product Development Dept.) de-

Figure 2: In-car radio for European automobile manufacturer developed based on AUTOSAR

Figure 3: Software stack of developed in-car radio

6/43 6/45

AUTOSAR-compliant Development of an In-car Radio Product Using MICROSAR for the European Market

Leveraging Existing Assets with a Proprietary Wrapper

development work was nearly complete, and next, the

without Using RTE

weight shifted to development of the SW-C, which is the

During actual development, the schedule became an initial

application layer. The SW-C, which is comprised of func-

issue. Kusano recalled the process. “We began develop-

tions including the radio tuner and USB audio playback,

ment in October of 2010, but we had to provide the client

follows the conventional architecture that interfaces with

with a prototype based on the evaluation board by Febru-

µITRON using the communication server named Virtual

ary 2011, so we had to have big progress with AUTOSAR on

MOST and interfaces with the BSW modules using a spe-

a very tight schedule.”

cially developed wrapper without using the RTE (see Figure 5).

As a solution, training on the development flow of AUTOSAR,

Kusano explained. “The number of man-hours required to

a BSW functional overview, and configuration of the

develop the wrapper was about five man-months, but that

MICROSAR environment and BSW were held at Alpine by

figure is smaller than it would have been if using the SW-C

instructors from Vector to improve the skills of the develop-

with an RTE.” After performing a series of tests, the team

ment leads. At the same time, development of MCAL was

completed a bug-free version of the prototypes incorporat-

immediately started. Next, Alpine worked with Vector to

ing all functions in October 2011, and series production was

implement an integration of products, starting with the

started at the end of 2013.

MICROSAR BSW modules, Alpine-developed MCAL, and

Figure 5: Development of a proprietary wrapper to replace the RTE and reduce the changes to software assets

Complex Driver and CAN database (*.dbc) files that the cli-

Launching Product Development with AUTOSAR

ent provided, and also combining EcuC (ECU configuration

Release 4.0

description), GENy and DaVinci Configurator Pro (both

Although increased man-hours is a typical concern with

Vector’s configuration tools1) (see Figure 4).

AUTOSAR-based development, Kusano revealed that there

“The schedule leading up to the provision of the prototype

was no significant increase, with only two people (it be-

to Vector Japan were handled within 24 hours, and we were

provide products and services that best meet the needs of

was tight, and in the end, we went to Europe, where the

came one at the final development stage) required for con-

very pleased with their technical support.”

our customers.”

automobile manufacturer is located, and worked together

figuring the MICROSAR BSW while each did other develop-

Alpine has already started developing new products using

with Vector to accelerating integration and perform test-

ment tasks in parallel, only three people (only in the initial

AUTOSAR Release 4.0, with series production scheduled for

Image rights:

ing,” explained Kusano.

development phase) required for integration work while

2016. “Introducing MICROSAR RTE that we skipped this

Cover and Figure 1: Vector Japan

These efforts were worthwhile, as the team successfully

they also did other tasks too, and only about five man-

time will be next challenge in our next product. We will work

Figure 2-5: Alpine Electronics, Inc.

provided the prototype based on the evaluation board by

months required for wrapper development.

to develop new products with the continuous cooperation

February 2011, as requested by the client. They were also

Kusano also revealed that he was quite satisfied with the

of Vector,” Kusano said.

Contact in Japan for further information:

able to release a prototype which is based on the hardware

quality of MICROSAR provided by Vector. “During the eval-

Now, as AUTOSAR has been getting more mandated in

Sales Division (Embedded Software), Vector Japan Co., Ltd.

for series production by April 2011. The AUTOSAR-related

uation process, we discovered several problems, but they

RFQs of European automobile manufacturers, Alpine’s

[Tokyo] Tel: +81 3-5769-7808

were mainly caused by incorrect settings, wrong use or

example of development with AUTOSAR by introducing

E-mail: [email protected]

problems caused by other tools. There was only one prob-

MICROSAR for short turnaround and reduced man-hours

lem within MICROSAR itself. Moreover, all detailed inquiries

will surely serve as an exemplary model for other suppliers

1 In new AUTOSAR 4.x projects GENy is no longer used for configuring AUTOSAR BSW. The current solution uses just one tool – DaVinci Configurator Pro.

Find your local contact person: www.vector.com/contact

Reviewing the Project Tomohiro Kusano OEM Product Development Dept. ALPINE ELECTRONICS, INC. “Thanks to the high-quality MICROSAR product and Vector’s support, we were able to meet the tight schedule and quality demands of our European automobile manufacturer client. AUTOSAR-compliant development will certainly become more important in the future, and we would like to leverage our experience and knowledge to other parts of the company and to new products.” Tsuyoshi Sakurai Embedded Software Dept. (PES) Vector Japan Co., Ltd. Figure 4: Flow of Integration Using MICROSAR

6/44 6/46

“The expertise of the Alpine engineers also helped us out. We were very happy that our AUTOSAR solution could efficiently contribute to their development. We will continue to

6/45 6/47

and watchdog initialisation and state-handling, a non-vol-

The AUTOSAR Operating System

atile memory software stack for various memory devices,

In particular, the AUTOSAR OS offers many more features

an abstraction driver layer for the microcontroller peripher-

that were currently unavailable or not even considered by

als and also the operating system (OS).

the ECU supplier. In the past, a simple single-tick or superloop scheduler may have been adequate to host all the ECU

Increased Processing Demand from the AUTOSAR

application tasks. Now, with the alternative inclusion of an

“Sweet Shop”

AUTOSAR OS, a new set of operating system features be-

The AUTOSAR standards are still growing and evolving to

comes immediately available to the software engineers.

meet the very latest vehicle E&E requirements – at the end

The AUTOSAR OS is offered in a range of “Scalability

of 2014 the AUTOSAR Basic Software attained its highest

Classes”, extending from SC1 to SC4: > AUTOSAR OS Scalability Class 1 extends the OSEK/VDX

ever level of complexity so far, when version 4.2 was released. Over 90 scalable embedded software modules are defined and are supplied along with powerful configuration tools and code generators in conjunction with a set of fur-

standard operating with the addition of schedule tables > OS Scalability Class 2 extends AUTOSAR OS SC1 with the addition of timing protection

ther standards for the workflows, methodologies and data

> OS Scalability Class 3 extends AUTOSAR OS SC1 with

exchange formats. When an ECU supplier chooses to equip their ECU with

the addition of memory protection > OS Scalability Class 4 extends AUTOSAR OS SC1 with

AUTOSAR Basic Software, they find themselves being of-

the addition of both timing and memory protection

fered a new range of feature-rich embedded software modules that become available as off-the-shelf commodi-

The additional features within the AUTOSAR OS do not

ties. Lengthy software development lead-times are no lon-

come without a resource penalty and, like every other mod-

ger a constraint in deciding whether to build further fea-

ule within the AUTOSAR Basic Software, the increased

tures into the ECU, since including an additional AUTOSAR

functionality requires RAM and ROM resources within the

module simply becomes a tick-box within the Basic Soft-

microcontroller and consumes additional processor run-

ware configuration. Software architects can find them-

time overhead. These additional requirements would gen-

selves like “kids in a sweet shop” with over 90 software

erally need to be supported with higher ECU processing

modules to pick and choose from.

power and greater microcontroller memory capacity.

Of course, each of these software modules comes at its

A common misconception has subsequently arisen, that

within an AUTOSAR System

own cost; not only in terms of a license fee that is used to

adopting an AUTOSAR software architecture will auto-

The electrical and electronic (E&E) functions inside a modern vehicle have grown both in number and complexity; this new

recoup the development efforts of designing and creating

matically require the ECU supplier to upgrade the internal

each module, but also in terms of processor load. Each

microcontroller from a 16-bit to a 32-bit processor. Of

software module will take up precious RAM and ROM re-

course, this should not be the natural conclusion, since re-

sources within the microcontroller and also has functions

placing an existing OSEK OS with an AUTOSAR OS SC1

that need to be scheduled and called, that consume valu-

would incur only a minimal additional overhead, and only if

able processor runtime overhead.

the schedule tables feature is utilised.

High-Rate Task Scheduling within AUTOSAR Vector Addresses the Challenges of High-Rate Application Task Scheduling

level of complexity has led automotive vehicle manufacturers and their suppliers to form the AUTOSAR partnership, to define a standardised yet feature-rich software architecture for within the vehicle Electronic Control Units. A common misconception is that high-rate application tasks cannot be scheduled within an AUTOSAR system. This article explains the mechanisms in place within the AUTOSAR operating system to handle the application scheduling requirements and how a successful configuration of the OS allows the software engineer to continue running the high-rate task schedules within an AUTOSAR system.

6/46 6/48

The Drivers for AUTOSAR

AUTomotive Open System ARchitecture (AUTOSAR) devel-

In recent years, the electrical and electronic (E&E) func-

opment partnership; where their mutual goal has been to

tions inside the vehicle have grown exponentially, both in

define a common and standardised software architecture

number and complexity. This trend has been driven by a

for use within the vehicle ECUs, that would ultimately pro-

number of factors within the automotive industry, includ-

vide the software features, mechanisms and support nec-

ing an increased demand for E&E-based end-customer

essary to meet the higher demands of the vehicle’s underly-

features, the advent and proliferation of ADAS systems

ing E&E architecture.

and increasingly demanding legislation in diagnosing E&E

Before AUTOSAR was defined, the primary focus of the

system faults and Electronic Control Unit (ECU) failures.

vehicle manufacturers for an ECU’s embedded software

The newest vehicle functions have reached such a level of

was often limited to the network communication stack and

complexity that traditional automotive ECU capabilities

diagnostics. But with AUTOSAR, the underlying software

and supplier development methods can no longer fulfil the

within an ECU has undergone significant expansion;

demands imposed by the modern vehicle E&E architecture.

AUTOSAR “Basic Software” covers not only areas such as

In 2003, this increasing level of complexity led automotive

network communications for CAN, LIN, FlexRay, Ethernet

vehicle manufacturers and their suppliers to form the

and diagnostics protocols, but also now includes system

Figure 1: AUTOSAR OS Scalability Classes

6/47 6/49

High-Rate Task Scheduling within AUTOSAR

However, the software engineer now has the option to up-

Cat2 interrupts are normally used to schedule all the tasks

Conclusions

grade the operating system to include timing and/or mem-

of the Basic Software and application level software com-

The AUTOSAR standards have reached a new height, but

ory protection features, with just a simple selection within

ponents, where the AUTOSAR modules are specified to use

will continue to grow and evolve to meet the today’s latest

the required Basic Software configuration. The lead-time

the AUTOSAR OS and API (application programming inter-

vehicle E&E requirements. For ECU software developers,

associated to develop these features no longer has to be a

face). Where the application has a specific high-rate task

embracing AUTOSAR in addition to enhancing their appli-

hindrance, or even a consideration, since the OS is available

scheduling requirement, the software engineer can make

cation features is often considered to be just one further

as a commercial off-the-shelf (COTS) component. If all the

use of the AUTOSAR Cat1 interrupt, and hook the applica-

burden that is too often undertaken only if mandated by

AUTOSAR Basic Software modules are handled in a similar

tion task directly into the microcontroller’s interrupt table

the vehicle manufacturer. The proliferation of AUTOSAR

manner, the inclusion of all the new AUTOSAR features can

using the configuration tool. The Cat1 interrupts are essen-

architectures into powertrain areas has been particularly

become technically trivial, however a significant and visible

tially “invisible” to the rest of the AUTOSAR system.

slower than in other domains (such as body and chassis ap-

impact to the processor load and memory requirements

Cat1 interrupts offer a powerful way to interact with the

plications) with one reason being the concern of handling

would immediately be observed.

hardware directly, and therefore a degree of care and dili-

the high-rate task scheduling demands in addition to all

gence must be exercised when utilising this type of inter-

the new AUTOSAR features.

Scheduling a High-Rate Application Task

rupt; the main advantage is that the latency of the inter-

However, the mechanisms to handle such demands have

Just like the misconception that an AUTOSAR software ar-

rupt is very low, and hence the required high-rate task

already been considered and addressed by the AUTOSAR

chitecture inherently requires a 32-bit processor, a similar

scheduling can be achieved. However the normal protec-

standards and many AUTOSAR applications are success-

misunderstanding occurs that high-rate application tasks

tions offered by the AUTOSAR OS are not present, and

fully running high-rate task schedules using the OS Cat1

cannot be scheduled within an AUTOSAR system. Many

therefore the interactions from within the Cat1 interrupt

interrupts. By analysing the processor load within such sys-

typical automotive applications, especially within the power-

with the rest of the system have to be carefully considered

tems, Vector have observed that in many cases the high-

train domain, require tasks that can run at rates of every

prior to implementation.

rate task scheduling can still be achieved whilst also run-

100 microseconds (10 kHz) or even faster. Such a challeng-

Another aspect that has to be thought out is the allocation

ning the feature-rich AUTOSAR Basic Software.

ing scheduling requirement puts a very high demand on the

of the interrupt priorities across the system. The AUTOSAR

But inevitably the additional features that are provided

AUTOSAR OS, and in turn on the microcontroller process-

OS is a fully pre-emptive operating system and therefore

within the AUTOSAR Basic Software and AUTOSAR OS will

ing load.

the AUTOSAR application tasks may interrupt each other.

bring further demands in load onto the processor, and

For these purposes, the AUTOSAR OS provides two types

But it would be unacceptable for an AUTOSAR task to be

therefore new differentiators have emerged within the em-

of interrupt “category”: > Cat1 interrupts are “unsupported” by the AUTOSAR OS.

allowed to interrupt, or block, the high-rate scheduled task

bedded software market. The scalability, configurability,

and therefore the priorities need to be allocated such that

efficiency and optimisation of each new AUTOSAR module

This means that the code to get safely into and out of

the high-rate task has the highest priority in the system.

has to be considered when sourcing AUTOSAR Basic Soft-

the interrupt handler is not generated by the AUTOSAR

This means that the high-rate task can interrupt any other

ware as off-the-shelf commodity parts.

OS and has to be generated in another way. [1]

task in the system, including the AUTOSAR OS, and every

Adopting AUTOSAR continues to be a concern for many

> Cat2 interrupts are supported by the OS. This means

other interrupt in the AUTOSAR system must be at least

ECU suppliers, often heightened by the perception of the

that the OS’s code generator and libraries abstract the

one priority level below that of the high-rate task, this is

complexity it can bring. But the complexity is inherently

interrupt from the hardware in a portable way. [1]

termed the “system interrupt level”.

present within the system already, driven by the end-cus-

Steve Waldron, Vector GB Ltd. Local Product Line Manager for the Embedded Software Product Line

Tom Dalek, Vector GB Ltd. Software Engineer for Embedded Software

Alex Ghinet, Vector GB Ltd. Senior Software Engineer for Embedded Software

tomer’s feature requirements and the underlying E&E architecture necessary to support those required features. AUTOSAR only provides the mechanisms and structures necessary to manage the already existing complexity; therefore an AUTOSAR system should not be viewed as a problem – but rather, that it provides the solution. Figures: Vector Informatik GmbH / Vector GB Ltd. Literature: [1] Explanation of Interrupt Handling in AUTOSAR, sourced from www.autosar.org on 09/07/2015: www.autosar.org/ fileadmin/files/releases/3-2/software-architecture/general/auxiliary/AUTOSAR_InterruptHandling_Explanation.pdf Links: Website Vector: www.vector.com Figure 2: Example High-Rate Task Scheduling within an AUTOSAR System

6/48 6/50

Vector AUTOSAR Solution: www.vector.com/autosar/

6/49 6/51

M O B I L E A U T O M AT I O N 2 015

|

STEUERUNGEN

STEUERUNGEN

Neue Chancen mit AUTOSAR AUTOSAR wurde seit 2009 schrittweise für die Anwendung in Nutzfahrzeugen angepasst, und ist bereits in einigen Lkw-Baureihen im Serieneinsatz. Jetzt beginnt die Einführung von AUTOSAR in Landmaschinen, die mit ein paar Erweiterungen von AUTOSAR ebenfalls zur Erfolgsgeschichte werden kann.

|

M O B I L E A U T O M AT I O N 2 015

erreicht wurde. Die Basissoftware erlaubt es einerseits, Standardsoftware einzusetzen und dadurch Kosten zu sparen. Andererseits ermöglicht sie einen einfacheren Wechsel der Hardware eines Steuergerätes. Die zweite Zielsetzung von AUTOSAR war das Herunterbrechen von komplexen Funktionen. Dies wurde durch die Einführung von Software-Komponenten (SWCs) umgesetzt, die über einen abstrakten Kanal kommunizieren, den sogenannten virtuellen Funktionsbus (VFB). Die tatsächlichen Kommunikationsbeziehungen ergeben sich erst durch das Verteilen der Komponenten auf Steuergeräte. Die gesamte Kommunikation wird zur Laufzeit durch die RTE (Runtime Environment) umgesetzt, die für externe Kommunikation auf die Basissoftware zugreift. Bild 1 zeigt einen Teil der für J1939Anwendungen relevanten Basissoftware, sowie die RTE und die SWCs der Anwendungsschicht. Das SoftwareKomponenten-Modell von AUTOSAR

Bilder: Vector Informatik GmbH

S

6/50

eit ein paar Jahren interessieren sich nach den Lkw-Herstellern auch Hersteller von Landwirtschafts- und Baumaschinen für AUTOSAR. Diese bauen im Vergleich zur Automobil- und Lkw-Industrie noch mehr Fahrzeug-Varianten mit noch geringeren Stückzahlen. Das Problem der steigenden Kosten mit zunehmender Elektronik in neuen Fahrzeugen trifft sie daher besonders stark. Um wettbewerbsfähig zu bleiben, ist es für Landmaschinen- und Baugerätehersteller entscheidend, ganze Steuergeräte und auch einzelne in Software implementierte Funktionen möglichst oft

wiederzuverwenden. Für genau diese Anforderungen wurde AUTOSAR entwickelt, und drängt sich deswegen geradezu als Lösungsansatz auf. Konzeptionelle Vorteile von AUTOSAR AUTOSAR fördert das Wiederverwenden einzelner Funktionen durch sein Software-Komponenten-Modell. Für das Wiederverwenden von ganzen Steuergeräten steht ein ausgeklügeltes Varianten-Handling und die Möglichkeit der Nachkonfiguration (Post-Build) zur Verfügung. Die größten Vorteile resultieren

aber wahrscheinlich aus dem konsequenten Anwenden der AUTOSAR-Methodik: Durch das Umstellen der Entwicklungsprozesse ergibt sich die Chance, die komplette Steuergeräte-Architektur zu überdenken, und dabei für eine modulare Nutzung aller Bestandteile zu optimieren – Hardware wie Software. Die AUTOSAR-Methodik ist somit ein wichtiger Innovationstreiber. Für die Entwicklung des AUTOSARStandards gab es hauptsächlich zwei Motivationen: Ein Ziel war das Vereinheitlichen der Hardware- und Protokolltreiber, was durch die Spezifikation der Basissoftwaremodule (BSW-Module)

Die Software-Komponenten von AUTOSAR sind in eine Hierarchie von Kompositionen eingebettet. Ihre Funktionalität wird durch Runnables implementiert. SWCs definieren ihren Kommunikationsbedarf durch Schnittstellen (Ports), die zu übertragende Datenelemente und Operationen gruppieren. Der virtuelle Funktionsbus verbindet diese Ports auf abstrakter Ebene. Nach dem Verteilen der Software-Komponenten auf Steuergeräte werden die abstrakten Signale des virtuellen Funktionsbusses auf konkrete NetzwerkSignale, PDUs und Frames abgebildet, und damit einem physikalischen Netzwerk zugeordnet. Einsatz von AUTOSAR in Nutzfahrzeugen Die ersten Lkws mit AUTOSAR-basierter EE-Architektur sind bereits seit einigen Jahren auf der Straße. Auch einzelne Steuergeräte aus anderen Industriezweigen basieren bereits auf diesem Standard, zum Beispiel Motorsteuergeräte für Dieselaggregate. Derzeit stellen die ersten Landmaschinenhersteller ihre Prozesse auf AUTOSAR um

Bild 1: Ausschnitt aus einer für Landmaschinen erweiterten AUTOSAR­ Architektur.

und haben damit bereits erste Vorserien-Steuergeräte entwickelt. Durch das konsequente Umstellen auf die AUTOSAR-Methodik wurden dabei deutliche Effizienzsteigerungen bei der Implementierung erreicht. Ermöglicht wurde der Einsatz von AUTOSAR im Nutzfahrzeugbereich durch das schrittweise Erweitern der Basissoftware um J1939-Protokolle (Bild 2). Im Jahr 2009 hat die Spezifikation des J1939 Transport Layer (J1939Tp) in AUTOSAR 4.0.1 den Grundstein dazu gelegt. Vier Jahre später kam mit AUTOSAR 4.1.1 die Einführung der Metadaten, und damit die Möglichkeit, aus höheren Schichten der Basissoftware heraus auf die für J1939 wichtigen Adressinformationen in den CAN-IDs zuzugreifen. Mithilfe der Metadaten kann eine Botschaft

unabhängig von ihrem Absender bearbeitet oder geroutet werden, was insbesondere für die korrekte Antwort auf einen Request nötig ist. Für diese Aufgabe wurde der J1939 Request Manager (J1939Rm) als weiteres BSW-Modul eingeführt. Außerdem kam das J1939 Network Management (J1939Nm) für die Adress-Arbitrierung hinzu, sowie der J1939 Diagnostic Communication Manager (J1939Dcm), der sich zusammen mit dem erweiterten Diagnostic Event Manager (DEM) um die Diagnose gemäß J1939 kümmert. Seine Grenzen findet AUTOSAR derzeit bei der volldynamischen Adress-Vergabe (Bild 3), die in Landund Baumaschinen weit verbreitet und eine Voraussetzung für die Vernetzung über den ISOBUS ist. Ebenso 6/51

M O B I L E A U T O M AT I O N 2 015

|

STEUERUNGEN

Bild 2: Meilensteine für J1939 in AUTOSAR.

Bild 3: Dynamische Adressver­ gabe auf dem ISOBUS.

fehlt noch die Handhabung mehrerer Multiplexoren in proprietären Nachrichten (PropA, PropA2, PropB) und die Transportprotokolle von NMEA2000 und ISO 11783. Auch für die Protokolle der Komponenten von ISO 11783 wie Virtual Terminal oder Task Controller gibt es noch keine Unterstützung. Weiterentwicklung von AUTOSAR

INFO

Derzeit sind bereits Lösungen für die volldynamische Adressvergabe und für

das erweiterte Transportprotokoll aus ISO 11783 sowie für den Umgang mit den proprietären Botschaften auf dem Markt. Darin sind die Module CANInterface (CanIf), J1939Nm, J1939Tp und J1939Rm entsprechend erweitert. Diese Erweiterungen zu AUTOSAR sind allerdings nur teilweise zwischen den verschiedenen Anbietern abgestimmt. Eine Standardisierung auf Ebene der Basissoftware wäre hier wünschenswert. Auch für die Protokolle der Komponenten aus ISO 11783 gibt es bereits

Implementierungen. Eine Standardisierung dieser Protokolle in AUTOSAR könnte durch „Application-Interfaces“Dokumente erfolgen, welche nur die Schnittstellen zur Applikation definieren. Die Implementierung würde dann in Form von Complex Drivers (CDD) erfolgen. Da in letzter Zeit mehrere Hersteller von Nutzfahrzeugen wie beispielsweise Caterpillar, CNHi und John Deere, Mitglieder von AUTOSAR geworden sind, wachsen die Chancen, den Standard mittelfristig um dynamische Adressierung und die fehlenden Protokolle zu ergänzen. Dann steht einem Einsatz von AUTOSARImplementierungen im Bereich der landwirtschaftlichen Nutzfahrzeuge und Baumaschinen nichts mehr im Wege. W (oe)

j

Vector Informatik GmbH www.vector.com Dipl. Inf. Martin Schlodder studierte Informatik an der Universität Tübingen und ist seit 2004 bei Vector Informatik tätig. Er entwickelt J1939Software und ist Mitglied in AUTOSAR-Arbeitsgruppen zur Integration von J1939.

[email protected]

Die wichtigsten Merkmale von ISO 11783 / ISOBUS Die ISO 11783 wurde mit dem Ziel entwickelt beliebige Traktoren mit beliebigen Anbaugeräten über den ISOBUS zu kombinieren, und neue Entwicklungen in der Landtechnik zu fördern wie beispielsweise „Precision Farming“. Die Norm basiert auf SAE J1939 mit volldynamischer Adressierung und fügt spezialisierte Komponenten sowie die Satelliten-Navigation aus NMEA 2000 hinzu. Die wichtigsten Komponenten sind:

W Virtual Terminal: Überwachen und manuelles Steuern von Anbaugeräten. W Task Controller: Automatisches Steuern von Anbaugeräten anhand von Positionsdaten.

W Tractor Controller: Austausch von Daten zwischen Fahrzeugnetz und Anbaugerätenetz.

W Sequence Controller: Aufzeichnen und Wiederholen von gleichbleibenden Abläufen, beispielsweise Wenden am Feldende.

W File Server: Speichert auf Anfrage Daten anderer Steuergeräte. ISO 11783 verwendet gegenüber J1939 zwei zusätzliche Transport-Protokolle: Das extended TP für große Datenmengen und FastPacket für Navigationsdaten. Außerdem schränkt es die Diagnose auf die aktiven und zuletzt aktiven Fehler ein (DM1-DM3).

6/52

Impressum Verlag: Carl Hanser Verlag GmbH & Co. KG, Kolbergerstr. 22, 81679 München © Lizenzausgabe mit Genehmigung des Carl Hanser Verlags, München. Alle Rechte, auch die des Nachdrucks, der photomechanischen und der elektronischen Wiedergabe sowie der Übersetzung dieses Sonderdrucks behält sich der Verlag vor.

Messen/Testen/Tools Funktionale Sicherheit

Alle Bilder: Vector Informatik GmbH

Messen/Testen/Tools Funktionale Sicherheit

Safety systematisch verankern Modellbasierte funktionale Sicherheit in der E/E-Systementwicklung Um funktionale Sicherheit als integralen Bestandsteil der Entwicklung von E/E-Systemen zu ermöglichen, sind neue Ansätze nötig. Schließlich gilt es, alle Ebenen von Systementwürfen zu berücksichtigen und sicherzustellen, dass die Sicherheitsziele der Systeme nachweislich und gemäß der „Safety-Norm“ ISO 26262 umgesetzt sind. Autoren: Albert Habermann und Dr. Simon Burton

D

ie Einführung der internationalen Norm ISO 26262 zur funktionalen Sicherheit von elektrisch/elektronischen Systemen im Automobil hat das Bewusstsein für dieses Thema in der Industrie deutlich verstärkt. Viele Hersteller und Lieferanten suchen daher nach Ansätzen, die Vorgaben aus der Norm pragmatisch und effizient zu erfüllen und gleichzeitig der steigenden Komplexität sicherheitsrelevanter Funktionen gerecht zu werden. Das Entwickeln sicherheitskritischer Systeme führt im Vergleich zu herkömmlichen Entwicklungen zu erhöhten Aufwänden. So sind zusätzliche Aktivitäten bei gleichbleibenden Rahmenbedingungen hinsichtlich Zeitplänen, Ressourcen und Kosten, unvermeidbar. Bestehende Entwicklungs-, Analyse- und Testmethoden sowie die dazugehörenden Werkzeuge sind oft fragmentiert und lassen sich nur mit großem Aufwand in einen durchgängigen Prozess integrieren.

Ganzheitliche Betrachtung von Systemarchitekturen Eine wesentliche Forderung aller gängigen Sicherheitsnormen im Automotive- sowie im Non-Automotive-Bereich (zum Beispiel IEC

7/0 2

34

Automobil ElEktronik 02/2012

methoden sind solche Zusammenhänge bei komplexen Systemen kaum zu durchblicken. Hier zwei Beispiele für typische Entwurfsfehler: ■ Während der SW-Entwicklung werden inkorrekte Annahmen über die Integrität des Kommunikationsmediums zwischen zwei Funktionen gemacht. Somit werden Kommunikationsfehler nicht ausreichend berücksichtigt. Beispielsweise kann eine nachträgliche Umverteilung der SW-Funktionen auf verschiedene ECUs in unterschiedlichen Bussegmenten zur Verletzung der ursprünglichen Annahme führen, ohne dass dies dem SW-Entwickler bewusst wird. ■ Eine Hardware-Komponente zeigt durch Positionierung in einem Fahrzeugbereich, der extremen Umweltbedingungen wie beispielsweise Feuchtigkeit, mechanischem Stress oder elektromagnetischen Störungen ausgesetzt ist, untypisch hohe Ausfallraten. Die erhöhten Ausfallraten werden im Sicherheitskonzept nicht berücksichtigt. Um solche komplexen Zusammenhänge während der Entwurfsphase berücksichtigen zu können, ist ein ganzheitlicher Ansatz zur Systemmodellierung notwendig. Dieser Ansatz vereint in einem Datenmodell alle funktionalen und nichtfunktionalen Anforderungen, den logischen Systementwurf, die Netzwerk-Architektur sowie die Software- und Hardware-Komponenten-Architektur. Ebenso sind der Leitungssatz sowie die topologische Verteilung der Komponenten und des Kabelbaums im Fahrzeug zu berücksichtigen. Wichtig ist hierbei die Möglichkeit, die Zusammenhänge der verschiedenen Architekturebenen sowie die domänenspezifischen Attribute der modellierten Artefakte (beispielsweise Buslatenzzeiten, Hardware-Ausfallraten oder Temperaturbereiche von Bauräumen) ebenfalls beschreiben zu können. Auf Basis dieser Daten lassen sich dann Analysefragen formulieren und teilweise automatisiert durchführen, wobei eine derartige Frage zum Beispiel so lauten könnte: „Werden Kabel, die für das Sicherheitskonzept relevante Signale übertragen, in crash-gefährdeten Bereichen verlegt?“

Modellbasierte Sicherheitsanalysen Die ISO 26262 fordert, Sicherheitsanalysen auf System-, Softwareund Hardware-Ebene durchzuführen, damit Schwächen im Entwurf entdeckt und verbessernde Maßnahmen ergriffen werden können. Ein Beispiel für solche Analysen ist die Fehler-Möglich-

61511 Prozessindustrie, IEC61513 Kernkraftwerke, EN 50128 Eisenbahn) besteht darin, das Erfüllen der Systemsicherheitsziele durch das entwickelte Systemkonzept nachzuweisen. Sicherheitsziele werden typischerweise durch Gefährdungs- und Risikoanalysen auf der funktionalen Systemebene identifiziert. Die aus den Sicherheitszielen abgeleiteten funktionalen und technischen Sicherheitsanforderungen sind dann Systemkomponenten zuzuordnen. Das korrekte Umsetzen dieser Sicherheitsanforderungen ist durch eine geeignete Kombination von Reviews, Analysen und Tests sicherzustellen. Das Erreichen der Systemsicherheitsziele hängt von einer Vielzahl verschiedener Faktoren ab. Ein Beispiel hierfür sind fehlerhaft programmierte Software-Funktionen oder zufällige Hardware-Fehler in kritischen Komponenten. Solche isolierten Fehler lassen sich mit gängigen Entwicklungsmethoden, wie in der ISO 26262 empfohlen, relativ einfach vermeiden oder zumindest entdecken und damit beherrschen. Problematischer wird es, wenn eine Kombination verschiedener Systemfaktoren aus unterschiedlichen Architekturebenen die Sicherheitsziele beeinflusst. Mit herkömmlichen, dokumentenbasierten Entwurfswww.automobil-elektronik.de

keits- und Einflussanalyse (FMEA). Mit ihr werden potenzielle Fehler einzelner Komponenten identifiziert und deren Auswirkungen auf Systemziele sowie deren Auftretenswahrscheinlichkeit betrachtet (Bild 1). Diese Analyseart ist gut geeignet, um Komponenten zu identifizieren die aus Sicht der Sicherheitsziele kritisch sind. Das Ergebnis ist aber sehr stark von der Qualität und dem Umfang des modellierten Systementwurfs abhängig auf dem die Analyse basiert. Bei nicht ausreichender Dokumentation der Systemabhängigkeiten greifen die Ingenieure häufig auf ihre individuelle Erfahrung und ihr Wissen zurück, was oft zu den im Beispiel oben angeführten Problemen führt. Eine ganzheitliche Modellierung des Systems ist die optimale Voraussetzung für das Durchführen von Sicherheitsanalysen. Beim Durchführen der Analysen greift der Safety-Experte direkt auf Informationen aus dem Modell zu. Abhängigkeiten, insbesondere zwischen unterschiedlichen Architekturebenen, lassen sich automatisiert analysieren und deren Auswirkungen auf die Systemsicherheit bewerten. Die sich aus der Analyse ergebenden Maßnahmen werden direkt im Modell umgesetzt und mit der entsprechenden Analyse verlinkt. Dadurch wird eine Verfolgbarkeit zwischen dem Entwurf, der Analyse und den betroffenen Sicherheitszielen hergestellt, die bei der Führung des Sicherheitsnachweises sowie für Impaktanalysen bei Systemänderungen unabdingbar ist. Die enge Verzahnung von dem System-entwurf, der Sicherheitsanalyse und dem Entwurf des Sicherheitskonzeptes erlaubt es, Auswirkungen von Modell-Änderungen unmittelbar zu analysieren und zu bewerten. Dadurch entfallen aufwändige Redesigns, die im Falle des sequentiellen Ab1rbeitens des Entwurfs und der Sicherheitsanalyse unvermeidbar sind. Darüber hinaus lassen sich auch mehrere Umsetzungsvarianten eines Systems vergleichen und bewerten. Eine Systemoptimierung unter Einbeziehung sicherheitstechnischer Gesichtspunkte findet somit schon in einer frühen Phase der Systementwicklung statt.

Produktlinienansatz bringt Effizienzsteigerung Die Personalisierung von Fahrzeugen, also das Bereitstellen unterschiedlicher Varianten und Ausprägungen, führt auch aus System-

Bild 1: Round-Trip-Engineering für Safety-Designs: Das Durchführen von Sicherheitsanalysen sowie das Modellieren des Sicherheitskonzepts und des Systementwurfs erfolgen in einem Modell. Dadurch lassen sich Abhängigkeiten und Auswirkungen von Änderungen unmittelbar erkennen und bei der weiteren Analyse berücksichtigen. www.automobil-elektronik.de

Automobil ElEktronik 02/2012

35

7/1

Messen/Testen/Tools Funktionale Sicherheit Bild 2: Gemeinsame Elemente der Sicherheitsarchitektur werden für unterschiedliche Fahrzeuge wiederverwendet.

hene Redundanz nicht vorhanden ist, identifiziert eine variantenspezifische Konsistenzprüfung dies als nicht erfüllte Anforderung.

Umsetzung mit Tools

sicht zu einer schier unüberschaubaren Variantenvielfalt. Der Safety-Engineer steht damit zunächst vor der Herausforderung, für jede Variante des Systems den geforderten Sicherheitsnachweis zu erbringen. Ein Weg, dieser Herausforderung zu begegnen, ist die Anwendung eines Produktlinienansatzes. Dieser Ansatz basiert auf der Analyse (Domain-Analysis) variantenbehafteter Systeme (Produktfamilien) hinsichtlich Gleichteilen (Commonalities) und Unterschieden (Variabilities). Das Identifizieren der Gleichteile bildet die Grundlage dafür, diese über eine Reihe von Produkten (Fahrzeugen) hinweg wiederzuverwenden. Zudem fallen Aufwände für das Erstellen von Anforderungsanalysen, Implementierungen oder Tests nur einmal an. Um das Konzept der Wiederverwendung auch für die Entwicklung sicherheitskritischer Systeme nutzbar zu machen, muss der Produktlinienansatz auf Gefahren- und Risikoanalysen sowie auf Sicherheitskonzepte ausgeweitet werden. Sofern sich diese Analysen und Konzepte auf einen gemeinsamen Satz von Features beziehen, stehen sie zur Wiederverwendung bereit. Aus dem funktionalen Sicherheitskonzept werden die technischen Sicherheitsanforderungen für konkrete Fahrzeugprojekte abgeleitet. Konkrete Fahrzeuge sind zum Beispiel durch eigene Betriebszustände, Systemarchitektur etc. gekennzeichnet (Bild 2). Durch das Anwenden der Domain-Analyse auf die technischen Sicherheitsanforderungen stehen auch Teile dieser Anforderungen zur Wiederverwendung bereit. Um den Mehrwert des Wiederverwendens zu maximieren, lässt sich die Domain-Analyse ebenfalls auf Systemkomponenten (Software-Komponenten, Hardware-Komponenten) ausdehnen. Das Führen des Sicherheitsnachweises wird durch das Wiederverwenden eines Teils der Argumentationsstruktur (Safety Case Argumentation Structure) unterstützt. Annahmen über die konkrete Fahrzeugumgebung werden dabei als Anforderungen formuliert, deren Umsetzung oder Gültigkeit dann im konkreten Kontext zu analysieren sind. Der modellbasierte Ansatz bildet die Voraussetzung für variantenspezifisch durchgeführte Analysen und Konsistenzprüfungen. Auf diese Weise ist sichergestellt, dass beispielsweise alle im Sicherheitsnachweis angeführten Maßnahmen und die aus dem wiederverwendeten Sicherheitskonzept resultierenden technischen Anforderungen im konkreten Fahrzeug auch tatsächlich umgesetzt werden. Wenn beispielsweise eine im Sicherheitskonzept vorgese-

Der alles entscheidende Erfolgsfaktor ist die Verfügbarkeit einer bewährten Werkzeugunterstützung, um den hier beschriebenen Paradigmenwechsel vom dokumentenzentrierten hin zum modelbasierten Ansatz in der täglichen Praxis umzusetzen. Eine wesentliche Anforderung an ein Werkzeug ist die Eignung zum Beschreiben komplexer Systeme durch ein entsprechendes semantisches Datenmodel. Aber auch domänenspezifische grafische Notationen und die Unterstützung bei Analysen sowie beim Führen des Sicherheitsnachweises sind unabdingbar. Weitere Anforderungen ergeben sich aus der Zusammenarbeit in größeren Teams, wo die Bereitstellung einer Kolaborationsplattform für die Datenhaltung im Single-Source-Prinzip sowie der Austausch zwischen allen Projektbeteiligten gefragt sind. Zuständigkeiten und Verantwortlichkeiten müssen dabei über ein Rechte- und Rollenkonzept abgebildet werden können. Aus der zeitlichen Nachverfolgbarkeit (Versionshistorie) ergibt sich die Forderung nach einem integrierten Versions- und Konfigurationsmanagement. Vector Informatik bietet mit PREEvision ein seit mehr als fünf Jahren im Markt etabliertes und bewährtes Werkzeug für Modelbasiertes Systems Engineering an. Darüber hinaus unterstützt PREEvision in den Bereichen Test (Testdatenmanagement), Planung (Produkt- und Releasemanagement) und Änderungsmanagement. Mit der neuesten Version unterstützt PREEvision einen ISO-26262-konformen Ansatz zur Modellierung, Analyse und Test von funktionalen Sicherheitskonzepten. (av) ■

Die Autoren: Albert Habermann ist als Projekt Manager im Bereich Customer Services für das Architektur-und SystemsEngineering-Werkzeug PREEvision bei Vector Informatik tätig. Dr. Simon Burton ist Safety-Spezialist und war zuletzt als Produktmanager für das Architektur- und Systems-EngineeringWerkzeug PREEvision bei Vector Informatik tätig.

Auf einen Blick Funktionale Sicherheit beherrschen Modelbasierte Methoden und ein ganzheitlicher Ansatz (Systems Engineering) geben dem System-Entwickler eine Methode an die Hand, komplexe Systeme zu verstehen und zu beherrschen, was letztlich zu sicheren Systemen führt. Der modelbasierte Ansatz ermöglicht die notwendige Effizienzsteigerung, um die zusätzlichen Aufwände zu kompensieren, die trotz des Durchführens von Sicherheitsanalysen, des Umsetzens der daraus resultierenden Maßnahmen und des Führens von Sicherheitsnachweisen entstehen. Das Wiederverwenden ganzer Teile der Sicherheitsarchitektur vermeidet Doppel- oder gar Mehrfacharbeiten und führt zu einer weiteren Effizienzsteigerung. infoDIREKT www.all-electronics.de

322AEL0212

Erschienen in Automobil Elektronik, 2/2012 7/2

36

Automobil ElEktronik 02/2012

www.automobil-elektronik.de

Software SIchErhEIt

Software SIchErhEIt

AutorEn

funktionale Sicherheit und autoSar

AutorEn

funktionale Sicherheit und autoSar

dr.-ing. günther heling

ist Leiter der Produktlinie dr.-ing. günther Embedded Software bei derheling Vector ist Leiter der Produktlinie Informatik Gmbh in Stuttgart. Embedded Software bei der Vector Informatik Gmbh in Stuttgart.

dipl.-ing. (fh) Jochen rein

ist Gruppenleiter Produktdipl.-ing. (fh) Jochen rein management und Vertrieb für ist Software Gruppenleiter ProduktEmbedded bei der Vector management und in Vertrieb für Informatik Gmbh Stuttgart. Embedded Software bei der Vector Informatik Gmbh in Stuttgart.

dipl.-ing. (fh) patrick Markl

ist teamleiter der Konzeptdipl.-ing. (fh) patrick Markl entwicklung in der Produktlinie ist teamleiter derder KonzeptEmbedded Software bei Vector entwicklung in der Produktlinie Informatik Gmbh in Stuttgart. Embedded Software bei der Vector Informatik Gmbh in Stuttgart.

Koexistenz von sicherer und nicht-sicherer software Koexistenz von sicherer auf einem steuergerät und nicht-sicherer software auf einem steuergerät

Watchdog. Die Steuergeräteentwicklungen erfüllen ISO 26262 [2]. Softwareentwicklung für SicherheitSrelevante Steuergeräte Softwareentwicklung für SicherheitSrelevante Steuergeräte Autosar unterstützt das Verteilen von Funktionen auf mehrere

Steuergeräte. Dies erleichtert die Funktionsentwicklung, die Autosar unterstützt das Verteilen von Funktionen auf mehrere zunächst ohneDies Rücksicht auf die dasFunktionsentwicklung, Mapping von Funktionsanteilen Steuergeräte. erleichtert die auf bestimmte Steuergeräte erfolgt. Andererseits hat das zur zunächst ohne Rücksicht auf das Mapping von Funktionsanteilen Folge, dass es eine überproportional hohe Zahl von auf bestimmte Steuergeräte erfolgt. Andererseits hatSteuergeräten das zur 1. Diese gibt, denen Sicherheitsanforderungen zugeordnet sind, Folge, dass es eine überproportional hohe Zahl von Steuergeräten Steuergeräte müssten vollständig entsprechend dem höchsten 1. Diese gibt, denen Sicherheitsanforderungen zugeordnet sind, ASIL (Automotive Safety Integrity Level) ihrer Anforderungen Steuergeräte müssten vollständig entsprechend dem höchsten entwickelt werden,Safety auch wenn derLevel) überwiegende Teil ihrer FunkASIL (Automotive Integrity ihrer Anforderungen tionen nicht sicherheitsrelevant ist. Eine einzige Sicherheitsanforentwickelt werden, auch wenn der überwiegende Teil ihrer Funkderung nach sicherheitsrelevant ASIL-D hätte zur Konsequenz, dassSicherheitsanfordas gesamte tionen nicht ist. Eine einzige Steuergerät nach ASIL-D entwickelt werden muss. derung nach ASIL-D hätte zur Konsequenz, dass das gesamte Um diesennach ASIL-Lift-up-Effekt [3] werden zu vermeiden, Steuergerät ASIL-D entwickelt muss. sieht die ISO 26262 die Koexistenz von Subelementen mit unterschiedlichem Um diesen ASIL-Lift-up-Effekt [3] zu vermeiden, sieht die ISO ASIL vor. Die Koexistenz erfordert den Nachweis, dass es keine 26262 die Koexistenz von Subelementen mit unterschiedlichem ungewollte Wechselwirkung zwischen Subelementen gibt. ASIL vor. Die Koexistenz erfordert den den Nachweis, dass es keine Im Softwarebereich ist die Partitionierung ein probates Mittel, ungewollte Wechselwirkung zwischen den Subelementen gibt.um diese „Freedom fromistInterference“ zu realisieren. Hierbei sindum Im Softwarebereich die Partitionierung ein probates Mittel, folgende Aspekte zu betrachten: diese „Freedom from Interference“ zu realisieren. Hierbei sind :folgende Speicherzugriffe Aspekte zu betrachten: :: Zeitverhalten und Ausführungsreihenfolge Speicherzugriffe :: Austausch von Informationen. Zeitverhalten und Ausführungsreihenfolge : Austausch von Informationen. „Standardfall“ der koexiStenz „Standardfall“ der koexiStenz Steuergeräte, die Funktionen mit und ohne Sicherheitsbezug

beinhalten, Mixed-ASIL-Systeme genannt. Zur VereinfaSteuergeräte,werden die Funktionen mit und ohne Sicherheitsbezug chung wird in diesem Artikel Software mit niedrigem genebeinhalten, werden Mixed-ASIL-Systeme genannt. ZurASIL Vereinfarell als wird QM-Software Software mit höherem ASIL ASIL als ASILchung in diesemund Artikel Software mit niedrigem geneSoftware bezeichnet. Voraussetzung für den Einsatz von rell als QM-Software und Software mit höherem ASIL als ASILASILSoftware dass die Voraussetzung Hardware für den geforderten Software ist, bezeichnet. für maximal den Einsatz von ASILASIL ausreichend ist. Software ist, dass die Hardware für den maximal geforderten Zurausreichend Kategorie „Standardfall“ gehören Systeme mit mittlerem ASIL ist. ASIL-Anteil, wobei die Interaktion zwischen den mit verschiedenen Zur Kategorie „Standardfall“ gehören Systeme mittlerem Anteilen eher gering ist. Das Trennen der Partitionen wird in dieASIL-Anteil, wobei die Interaktion zwischen den verschiedenen sen Fälleneher sehrgering effizient separateder Elemente realisiert. Anteilen ist. durch Das Trennen Partitionen wird inZwidieschen den Partitionen werden Barrieren errichtet, die eine Fehlersen Fällen sehr effizient durch separate Elemente realisiert. Zwifortpflanzung mit genügender Wahrscheinlichkeit ausschließen schen den Partitionen werden Barrieren errichtet, die eine Fehleroder zumindest erkennen und an die ASIL-Software melden. fortpflanzung mit genügender Wahrscheinlichkeit ausschließen Dadurch müssenerkennen nur die Barrieren und die sicherheitsrelevante oder zumindest und an die ASIL-Software melden. Software nach dem zugehörigen ASIL entwickelt werden, 2. In Dadurch müssen nur die Barrieren und die sicherheitsrelevante Microsar Safe, der Vector Informatik und TTTech Automotive 2. In Software nach demvon zugehörigen ASIL entwickelt werden, gemeinsam entwickelten Basissoftware (BSW), sind diese Microsar Safe, der von Vector Informatik und TTTech Automotive Schutzmechanismen bis ASIL-D verfügbar. gemeinsam entwickelten Basissoftware (BSW), sind diese

In künftigen Fahrzeugen werden die meisten Steuergeräte „Mixed-ASIL-Systeme“ sein. Diese enthalten sowohl sicherheitsrelevante Funktionen als auch Funktionen ohne Sicherheitsbezug. In diesem Artikel stellt Vector Informatik Konzepte vor, um diese Mixed-ASIL-Systeme effizient und entsprechend Autosar zu realisieren. Etwa durch die Autosar-Basissoftware SilentBSW, die sich selber kontrolliert und unzulässige Schreibzugriffe in sicherheitsrelevante Software blockiert. „Mixed-ASIL-Systeme“ sein. Diese enthalten In künftigen Fahrzeugen werden die meisten Steuergeräte sowohl sicherheitsrelevante Funktionen als auch Funktionen ohne Sicherheitsbezug. In diesem Artikel stellt Vector Informatik Konzepte vor, um diese Mixed-ASIL-Systeme effizient und entsprechend Autosar zu realisieren. Etwa durch die Autosar-Basissoftware SilentBSW, die sich selber kontrolliert und unzulässige Schreibzugriffe in sicherheitsrelevante Software blockiert.

Schutzmechanismen bis ASIL-D verfügbar.

7/4

62

Das Thema Funktionale Sicherheit wurde von Autosar schon früh adressiert. Die aktuellen Versionen dieser Spezifikation Das Thema Funktionale Sicherheit wurde von Autosar schon[1] enthalten eine Reihe von Konzepten, diedieser das Entwickeln sicherfrüh adressiert. Die aktuellen Versionen Spezifikation [1] heitsrelevanter Steuergeräte unterstützen. So zum Beispiel die enthalten eine Reihe von Konzepten, die das Entwickeln sicherEnd-to-End-Absicherung für unterstützen. den Austausch heitsrelevanter Steuergeräte Sovon zumInformationen Beispiel die oder die Überwachung des Programmablaufes durch einen End-to-End-Absicherung für den Austausch von Informationen Watchdog. Die Steuergeräteentwicklungen erfüllen ISO einen 26262 [2]. oder die Überwachung des Programmablaufes durch

Sonderheft electronica 2012

7/5

63

1 Beispiel eines Mixed-ASIL-Systems mit Funktions-Mapping auf mehrere Steuergeräte

Schutz vor Speicherverletzungen

Um den Schreibzugriff auf die Speicherbereiche der eigenen Partition zu begrenzen, wird die Memory Protection Unit (MPU) des Mikrocontrollers verwendet. Die Software, die die MPU ansteuert und den Kontextwechsel ausführt, muss den höchsten zugewiesenen ASIL unterstützen. Diese Software ist Teil eines AutosarBetriebssystems nach Scalability Class 3 oder 4 und muss nach ASIL-D entwickelt werden. Unter der Bezeichnung SafeContext ist diese Funktion ein Teil von Microsar Safe. Schutz vor verletzungen deS zeitverhaltenS und der auSführungSreihenfolge

Fehler in der QM-Software dürfen das zeitgerechte Bearbeiten der Tasks der ASIL-Software nicht verhindern. Dies erreicht man, indem die definierte Ausführungsreihenfolge und die Zeitabstände zwischen verschiedenen Funktionen der ASIL-Software überwacht werden. Autosar hat in der Version 4.0 hierfür Funktionen definiert. In Verbindung mit einem sicheren Hardware Watchdog erkennt die Software so das Verletzen der Vorgaben und überführt das System in einen sicheren Zustand. Dadurch werden Fehler zwar nicht verhindert, aber ein Auftreten wird erkannt. Bei typischen zulässigen Fehlerreaktionszeiten hat sich dieses Verfahren bewährt. Diese Funktion ist unter der 7/6

64

Bezeichnung SafeWatchdog in Microsar Safe enthalten. Schutz vor koMMunikationS fehlern

In der ISO 26262 sind relevante Fehlermuster beim Informationsaustausch aufgeführt und Autosar hat Algorithmen definiert, wie diese in einer End-to-End-Absicherung erkannt werden. Wie beim Programmablauf ist das Ziel, einen Fehler sicher zu entdecken und das System in einen sicheren Zustand zu überführen. Das Überwachen erfolgt durch Einfügen von Sequenznummern und die Ergänzung um eine Check-Summe. Um nicht eine sichere RTE (Runtime Environment) voraussetzen zu müssen, erfolgt die Überwachung oberhalb der RTE in einer sicheren

Partition der Applikationssoftware durch die Module E2E Protection Wrapper und E2E-Lib. In Microsar Safe sind beide Module in der Option SafeCom enthalten. koexiStenz bei eineM geringen anteil SicherheitSrelevanter Software

Ist der Anteil an ASIL-Software gering, kann es sinnvoll sein, dass sich die ASILSoftware gegen ungewollte Speicheränderungen selber schützt. Das ungewollte Verändern wird etwa durch folgende Maßnahmen erkannt oder sogar korrigiert, 3: : redundante und gegebenenfalls diversitäre Berechnung – auch zum Absichern der Algorithmen der ASIL-Software : redundante und gegebenenfalls diversitäre Ablage von Daten

: Deaktivierung von Interrupts in kritischen Bereichen, zum Beispiel in den Bereichen, in denen verglichen und entschieden wird. Kann man Fehler nur erkennen aber nicht verhindern, muss die ASIL-Software geeignete Maßnahmen treffen, um das System in einen sicheren Zustand zu bringen. Den Selbstschutz gegen Speicheränderungen realisiert man projektspezifisch in der ASIL-Software. Bezüglich Programmablauf und Kommunikation werden die oben dargestellten Verfahren übernommen, da hier kein Selbstschutz möglich ist. koexiStenz Mit Starker interaktion

Der oben dargestellte Schutz vor Speicherverletzungen auf Basis einer MPU ist ein sehr mächtiges Mittel für eine beliebige Kombination von Partitionen verschiedener ASILs auf einem Steuergerät. Die erforderlichen Kontextwechsel zwischen den Partitionen bewirken jedoch einen Laufzeit-Overhead, der kritisch sein kann. Das ist beispielsweise der Fall, wenn eine hohe Zahl von Signalen synchron zwischen der ASIL-Applikationssoftware und der QM-Basissoftware ausgetauscht wird und das Gruppieren der Signale nicht möglich ist. In solchen Fällen ist es von Vorteil, wenn die QM-Basissoftware in der gleichen Partition wie die ASIL-Applikationssoftware läuft. Das ist aber nur möglich, wenn die Basissoftware mit dem ASIL der Applikationssoftware entwickelt wurde. Der hierfür erforderliche Entwick-

lungsaufwand ist oft nicht angemessen, da die Anforderungen an die eigentliche Funktion der Basissoftware typischerweise nicht als sicherheitsrelevant eingestuft sind. Dies gilt etwa für das Versenden von Signalen, da für die Kommunikationeine End-to-End-Absicherung in jedem Fall erforderlich bleibt, um Fehler bei der Übertragung über den Bus zu erkennen. Ein höchst effizienter Ansatz ist daher, die Basissoftware generell auf QM-Niveau zu belassen und die Koexistenz mit der ASIL-Software ohne Einsatz einer MPU zu ermöglichen. Microsar Safe bietet hierfür eine Lösung unter der Bezeichnung SilentBSW – eine Basissoftware, die nicht stört. Um das ungewollte Überschreiben von Speicherzellen der ASIL-Software durch die QM-Software zu verhindern, 4, wird bei jedem Schreibbefehl der QM-Software überprüft, ob er auf den zulässigen Bereich zugreift. Die besondere Schwierigkeit besteht in der Eigenart der Basissoftware, dass Teile des Programmcodes generiert werden und das Entwickeln der Konfigurations- und Generierungswerkzeuge entsprechend der ISO 26262 nicht praktikabel ist. Die Lösung besteht darin, den gesamten Code nach dem Generieren zu überprüfen. Die Überprüfung erfolgt nicht durch Tests, sondern mittels eines speziell entwickelten Code Checkers. Durch dieses Überprüfen wird der überwiegende Teil der Fehlermuster abgedeckt. Die verbleibenden Fehlermuster werden durch Code-Inspektionen oder Überprüfungen zur Laufzeit abgedeckt.

3 Die ASILSoftware schützt sich selber vor Fehlern

2 Barrieren verhindern die Fehlerfortpflanzung in die ASIL-Software

Sonderheft electronica 2012

zuSaMMenfaSSung und fazit

Konzepte für das Entwickeln von Steuergerätesoftware entsprechend Autosar und ISO 26262 bis ASIL-D sind heute bereits verfügbar. Das schließt Verfahren für die besonders relevanten Mixed-ASIL-Systeme ein. Dazu zählt auch das neue Konzept der SilentBSW von Vector, das den Laufzeitbedarf für einige Anwendungsfälle deutlich vermindert. Es ist nicht erforderlich, jede Anforderung an die Basissoftware pauschal als sicherheitsrelevant anzunehmen. Es geht vielmehr darum, einzelne Anforderungen, die sich aus dem Sicherheitskonzept eines Steuergerätes ergeben, mit dem jeweils benötigten ASIL in der Basissoftware umzusetzen. literaturhinweiSe

[1] Autosar Gbr: http://www.autosar.org [2] International organization for Standardization (ISo), ISo 26262-1 bis ISo 26262-9, road vehicles – Functional safety ISo 26262-1:2011(E) bis ISo 26262-9:2011(E), First Edition 2011-11-15 [3] Poledna, S. et al.: Ein ASIL D Plattformsteuergerät für eine elektrische hinterachse mit Fahrdynamikfunktionalität. VDI-Bericht nr. 2132, 2011 [4] heling, G.: VDI-tagung Baden-Baden-Spezial, VDI-Bericht 2172

4 Die QM-Software blockiert selber unzulässige Schreibzugriffe in den Speicher der ASIL-Software

65

7/7

7/8

7/9

Sichere Steuergeräte nach ISO 26262

Solutions for Functional Safety

Profitieren Sie bei der Steuergeräte-Entwicklung von der Vector Lösung für Funktionale Sicherheit: > Sicherheitsrelevante E/E-Architekturen mit PREEvision entwickeln und analysieren > Implementierung von Sicherheitsanforderungen bis ASIL D im Steuergerät mit MICROSAR Safe

> Training und Coaching zur Qualifizierung von Fachund Führungskräften sowie Beratung zu sicherheitsrelevanten Entwicklungsprojekten Infos und Downloads: www.vector.com/safety

Mit Erfahrung, Engagement und praxiserprobten Produkten ist Vector Ihr kompetenter Partner für die Entwicklung von sicherheitsrelevanten Steuergeräten.

7/10

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

7/12

7/13

7/14

7/15

7/16

SPECIAL: AUTOSAR

SPECIAL: AUTOSAR

Fehlertolerante Systemarchitekturen mit AUTOSAR-Basis-Software realisieren:

Sieht so die Zukunft aus?

Priorität

(Bild: Jakub Krechowicz – Fotolia; Vector Informatik)

Hochautomatisiertes Fahren bringt neue Anforderungen an bestehende Sicherheitskonzepte. Eine Funktion einfach abzuschalten, um den sicheren Zustand zu erreichen, ist nicht mehr ausreichend. Der sichere Zustand erfordert Energie und aktive Funktionen. Von Jonas Wolf

I

n sicherheitsrelevanten Systemen im Fahrzeug ist heute das Ausschalten oder Zurücksetzen einer fehlerhaften Funktion die häufigste Fehlerreaktion. Sie wird als fail-silent bezeichnet. Die Maßnahme ist einfach umzusetzen und wirksam, um einen sicheren Zustand

einzunehmen und zu erhalten. Zunehmend übernehmen aber E/E-Systeme im Fahrzeug auch Funktionen, die im Falle eines Fehlers verfügbar bleiben müssen, beispielsweise beim Ausfall eines Mikrocontrollers. Dieses Verhalten wird fail-operational genannt und im Weiteren als fehlertolerant bezeichnet. Die Forderung Mikrocontroller- Funktionsüberwachung übergreifende Integrität (ASIL- und ApplikationsMaßnahmen nach fehlertoleranten Syste(ASIL-abhängig) abhängig) (ASIL-abhängig) men wird im Automobilbau Watchdog Watchdog Watchdog in Zukunft stark zunehmen. (Alive Monitoring) (Logic Monitoring) (Deadline Monitoring) Ein Beispiel: Lenkunterstützungssysteme in schweren Memory Partitioning/ Lock-step CPU Sensor Monitoring Coexistence (Mixed ASIL) SUVs sind heutzutage teilweise notwendig, um die ECC RAM Actuator Monitoring Communication Beherrschbarkeit durch den Protection (E2E) ECC ROM Limiter Fahrer sicherzustellen. Wähprojektspezifische rend die Entwickler Fail-SiBITs Applikations-Software Standard-Software lent-Systeme in der ZwiBild 1. Durch ein modulares Konzept lassen sich Sicherheitsschenzeit mit ISO 26262 gut beherrschen, sind Fragestelmechanismen effizient für das jeweilige Projekt zuschneiden. (Quelle: Vector Informatik) lungen beim Auslegen von aus Elektronik automotive 11.2015

7/18

ry Protection Unit (MPU) mit Verzögerte einem AUTOAktivierung von SAR-BetriebssysTask C um 1 ms. tem mit Scalability Class 3 (SC3), A A A A das die AnsteuB B erung der MPU mit dem geforC C derten ASIL 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 übernimmt. Das Zeit Überwachen der Bild 2. Die AUTOSAR Timing Protection erkennt frühzeitig ein Überschreiten zeitlichen Anfor(Quelle: Vector Informatik) derungen erleder erlaubten Zeit-Budgets von Tasks und Interrupts. digt üblicherFunktion und ergeben sich aus dem zu weise der Watchdog durch ein Deadline erreichenden Diagnosedeckungsgrad Monitoring. Sobald sicherheitsrelevan(Diagnostic Coverage, DC) für ein bete Daten zwischen mehreren Steuergeräten ausgetauscht werden, kommt eine stimmtes ASIL. Oft machen die Mikrocontroller-Hersteller konkrete Vorgaben Kommunikationssicherung (Communibasierend auf ihren Sicherheitsanalysen. cation Protection) ins Spiel. Hierzu bietet So können beispielsweise eingebaute AUTOSAR mit der End-to-End Protection (E2E) einen wirksamen SicherheitsmeSelbsttests (Built-in Tests, BITs), die zychanismus. Für diese übergreifenden klisch durch die Software angestoßen werden, für eine DC für ASIL D notwenMaßnahmen sind bis ASIL D zertifizierte dig sein. Bereits ab ASIL B muss in der Produkte von Vector Informatik verfügRegel die Auftretenswahrscheinlichkeit bar. sogenannter Single Event Upsets (SEUs) oder Bit-Kipper betrachtet werden. Transition zu Wirksamen Schutz gegen SEUs bieten fehlertoleranten Systemen Mikrocontroller im Lock-Step-Betrieb und Speicher mit FehlererkennungsHardware wird aktuell aus Kostengrünund korrektur-Codes (ECC RAM, ECC den nahezu redundanzfrei ausgelegt. ROM). Beide Sicherheitsmechanismen Ein Hardware-Fehler führt daher in der sind in der Hardware enthalten, nahezu Regel direkt zu einer schwerwiegenden transparent für die Software-EntwickBeeinträchtigung der Funktion bis hin zum Ausfall. Auf der anderen Seite lung und daher effiziente Lösungen. Zur Funktionsüberwachung setzt der existieren ausgereifte Verfahren zur Entwickler normalerweise weitere MaßQuantifizierung von Hardware-Ausfällen nahmen in der Applikation um. Hierzu wie in IEC 62380 und SN 29500 definiert, gehören Monitoring-Aufgaben für Sendie eine Vorhersage über die gewünschsorik und Aktuatorik genauso wie Limite Versagensrate erlauben [2]. ter oder eine Programmablaufkontrolle Das Quantifizieren von Software(Logic Monitoring). Die ProgrammabFehlern fällt oft schwer, weil es sich laufkontrolle wird beispielsweise mit ausschließlich um systematische Fehler einem AUTOSAR-Watchdog erreicht. handelt [3]. Um die Fehlertoleranz geFunktionsüberwachung und Mikrogenüber Software-Fehlern zu erhöhen, ist die Timing Protection als Sicherheitscontroller-Integrität sind projektspezifisch festzulegen und umzusetzen. Es mechanismus ein geeignetes Mittel. Die gibt jedoch auch Maßnahmen, die in fast Timing Protection schützt beispielsweijedem Steuergerät mit Sicherheitsbezug se gegen Endlosschleifen in Softwarezum Einsatz kommen und unabhängig Komponenten, die das Ausführen der von Funktion und ASIL sind. Nahezu eigentlich relevanten Funktion verhinjedes Steuergerät mit ASIL-Software dern. Bei der Timing Protection vergibt führt auch QM-Software aus. Um die der Entwickler zeitliche Budgets für die Koexistenz nach ISO 26262 zu gewährLaufzeit von Tasks und Interrupt-Routinen und für die Sperrzeiten von Interleisten, sind eine Speicherseparierung rupts und Ressourcen. Ebenso werden und eine Überwachung der zeitlichen die zeitlichen Abstände zwischen Tasks Randbedingungen notwendig [1]. Das Partitionieren des Speichers erfolgt und Interrupt-Routinen überwacht durch das Zusammenspiel einer Memo(Bild 2). Das AUTOSAR-Betriebssystem Task Zykluszeit Budget Die Timing Protection A 5 ms 1 ms erkennt Überschreitung B 10 ms 3 ms des erlaubten Zeit-Budgets. C 12 ms 5 ms

fehlertoleranten Systemen durch die ISO 26262 aktuell schwierig zu beantworten. Insbesondere die genaue Definition des sicheren Zustands bereitet in diesem Zusammenhang noch Kopfzerbrechen. Auch die zweite Auflage von ISO 26262, deren Veröffentlichung für 2018 geplant ist, wird hier noch keine endgültige Klarheit schaffen. Unabhängig von den Vorgaben durch Standards zeigen die folgenden Kapitel, wie sich die bestehenden Sicherheitskonzepte mit AUTOSAR auf fehlertolerante Systeme ausweiten lassen.

Modulares Sicherheitskonzept für Fail-Silent-Systeme Safety-Ingenieure schneiden durch ein modulares Konzept die unterschiedlichen Sicherheitsmechanismen effizient auf das jeweilige Projekt zu (Bild 1). Dabei unterscheiden sie grob zwischen Maßnahmen zur Mikrocontroller-Integrität, Maßnahmen zur Funktionsüberwachung und übergreifenden Maßnahmen. Maßnahmen zum Herstellen der Integrität des Mikrocontrollers werden abhängig vom höchsten Automotive Safety Integrity Level (ASIL) der verwendeten Software getroffen. Diese sind unabhängig von der auszuführenden

stoppt im Fehlerfall die verursachende Task oder Interrupt-Routine und schließt sie von der weiteren Ausführung aus. Die Timing Protection ist jedoch nur ein erster Schritt hin zu fehlertoleranten Systemen, wie sie in Zukunft gebraucht werden.

Fehlertolerante Systemarchitekturen In der Luftfahrt kommen fehlertolerante Systemarchitekturen seit vielen Jahren zum Einsatz. Für die sicherheitskritischen Flugsteuerungssysteme sind oft dreioder vierfach redundante Steuergeräte zu einem komplexen System vereint. Diese Redundanz in der Hardware ist selbstverständlich äußerst kostenintensiv. Für den Einsatz fehlertoleranter Systeme in der Automobilindustrie müssen daher neue Ansätze gesucht werden. Hierbei lässt sich in der Risikoabschätzung auch von der geringeren Schwere des Schadensausmaßes profitieren. Eine mögliche Systemarchitektur (Bild 3) weist in jedem Fall mindestens zwei Kanäle auf. Ein Kanal besteht in diesem Beispiel aus einem Sensor, einer Logikeinheit und einem Aktuator [4]. Es lässt sich schnell erkennen, dass beim Versagen des Mikrocontrollers eines Kanals auch die zugehörige Software und damit die Funktion ausfällt. Mikrocontroller haben aufgrund ihrer Komplexität häufig die höchsten Ausfallraten in einem Steuergerät; daher ist das korrekte Ausführen einer Funktion selbst für kleinste Zeiträume nicht sichergestellt. Damit dieses zweikanalige System fehlertolerant ist, muss jeder Kanal für sich alle Einzelfehler entdecken und sich passiv schalten [5]. Ohne diese Anforderung sind beide Kanäle für den sicheren Betrieb der Funktion notwendig.

Steuergerät 1. CANKommunikation

1. SBC/ Watchdog

1. Sensor

1. Mikrocontroller

1. Spannungsversorgung 1. Aktuator

Datenaustausch 2. Sensor

2. Mikrocontroller

2. CANKommunikation

2. SBC/ Watchdog

2. Aktuator

2. Spannungsversorgung

Bild 3. Beispiel für eine fehlertolerante Systemarchitektur (Quelle: Vector Informatik) durch redundante Auslegung. aus Elektronik automotive 11.2015 7/19

SPECIAL: AUTOSAR

der redundanten Kanäle gibt MICROSAR.RTE es zwei PhilosoKanalSensor- und statusStellwertphien, diversitär Fehleraustausch MICROSAR.COM austausch IO oder homogen. zustandsaustausch Die diversitäre Philosophie verwendet unterschiedliche Software auf beiden Kanälen. Bei gleichartigen XCP Kanälen und MiMICROSAR.MCAL MICROSAR.EXT krocontrollern lässt sich auf Mikrocontroller beiden Kanälen Legende: mögliche Neuerungen in der Basis-Software Basis-Software Applikation dieselbe SoftBild 4. MICROSAR-Software-Architektur für auf AUTOSAR basierende fehlerware nutzen, die (Quelle: Vector Informatik) nur je nach Katolerante Systeme. nal anders paraDadurch würde sich die Ausfallrate metriert ist. Dafür eignet sich der verdoppeln und nicht wie gewünscht sogenannte Post-Built-SelectableMechanismus von AUTOSAR, der halbieren. Diese Systemarchitektur erfordert eine redundante Energieversornormalerweise beim Entwickeln von gung der beiden Kanäle ebenso wie Steuergerätevarianten zum Einsatz einen redundanten Kommunikationskommt. Das Verwenden von gleichpfad zu relevanten Partnern. IEC 61508 artigen Kanälen erfordert das Unterbezeichnet ein solches System als 1-outsuchen von Fehlern mit gemeinsaof-2 with Diagnostics (1oo2D). mer Ursache [7]. Um eine schnelle Übernahme im FehSoftware-Architektur mit AUTOSAR lerfall durch den anderen Kanal zu erfür fehlertolerante Systeme möglichen, werden Sensor- und Stellwerte ebenso wie Statusinformationen Durch das Einführen von Redundanzen zum Kanal zwischen den Kanälen ausin der Hardware steigt grundsätzlich getauscht (Bild 3). Durch die Mechanisauch die Komplexität in der Applikation. men von AUTOSAR ist das mit nur einer So entstehen neue Herausforderungen Konfiguration der Basis-Software umim Bereich der Regelungstechnik, beisetzbar. Die Kanalumschaltung im Hotspielsweise bei Reglerstabilität oder Standby-Betrieb kann der Entwickler Aktuatorik durch Eingriff redundanter applikationsspezifisch als SoftwareRegler. Auch die Datenkonsistenz in Komponente (SWC) implementieren Netzwerken („byzantinischer Fehler“ [6]) oder die flexiblen Konfigurationsmögmuss neu bewertet werden. Aus Sicht lichkeiten der AUTOSAR-Manager-Komder Systemarchitektur lässt sich diese ponenten Basic Software Mode ManaKomplexität zum Beispiel durch einen ger (BSWM) und ECU State Manager (ECUM) ausreizen. Zum Austausch des Hot-Standby-Betrieb beschränken. DaFehlerzustands zwischen den Kanälen bei steuert zu einem Zeitpunkt immer wird heute applikationsspezifische nur einer der beiden Kanäle die AktuaSoftware implementiert. Es ist jedoch torik. Kommt es in diesem Kanal zu eivorstellbar, dass in Zukunft standardinem Fehler, übernimmt der andere Kanal sofort die Steuerung. Zur vereinfachsierte Basis-Software-Komponenten für ten Applikationsentwicklung ist die genau diesen Zweck spezifiziert werden. AUTOSAR-Basis-Software (Bild  4) aus den folgenden Gründen von Nutzen: Werkzeugunterstützung ➜ Wiederverwendung: Die für ein modulares Sicherheitskonzept bereits Um den weiteren Grad an Komplexität oben vorgestellten AUTOSAR-Komzukünftig zu beherrschen, bedarf es ponenten verwendet der Entwickler bereits ab einer frühen Entwicklungsweiterhin für die Fehlererkennung. phase wirksamer und durchgehender Werkzeugunterstützung. Dadurch wer➜ Einsatz von bestehenden Mechanismen: Für das Umsetzen der Software den die Ressourcen auf die ApplikatiMICROSAR.LIBS Complex Drivers

MICROSAR.ETH

MICROSAR.FR

MICROSAR.LIN

MICROSAR.CAN

MICROSAR.MEM

MICROSAR.V2G

SWC

MICROSAR.AVB

SWC

MICROSAR.DIAG

SWC

MICROSAR.AMD

MICROSAR.SYS

Kanalumschaltung

MICROSAR.OS (SC3/4)

SWC

onsentwicklung konzentriert und Ingenieure von lästiger und fehleranfälliger Arbeit entlastet, beispielsweise der manuellen Konsistenzprüfung von redundanten Signalen im Systemmodell.

Ausblick Mit den AUTOSAR-Bordmitteln lassen sich bereits heute Projekte mit Sicherheitsbezug effizient umsetzen. Wenn zusätzliche Fehlertoleranz von E/ESystemen gefordert wird, sind neue Systemarchitekturen erforderlich, die auch den Ausfall des Mikrocontrollers verkraften. Daraus ergeben sich für die Applikation und Basis-Software neue Herausforderungen. Mit der AUTOSARMethodik ist jedoch für diese Art von Systemarchitekturen die Komplexität beherrschbar. Die AUTOSAR-Basis-Software bietet hier durch die Konfigurierbarkeit eine hervorragende Ausgangslage. Die zugehörige Werkzeugkette erleichtert das Beherrschen der benötigten Redundanz. Zukünftig wird sich die Unterstützung durch die Basis-Software und deren Werkzeuge noch weiter verbessern. Ein erster Schritt ist jedoch das Bewusstsein, dass fehlertolerante Systeme auch neue Ansätze in der Systemarchitektur brauchen. eck

Steuergeräte und Netzwerke sicher schützen

Literatur [1] Definition des Fault tolerant time interval (FTTI) in ISO 26262-1, 1.45 [2] ISO 26262-5:9 Evaluation of safety goal violations due to random hardware failures [3] ISO 26262-10:4.3 Relationship between faults, errors and failures [4] Definition eines Systems in ISO 26262-1, 1.129 [5] ISO 26262 Single-point fault metric (SPFM) für ASIL D [6] L. Lamport et al.: The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 1982 [7] Definition einer Common Cause Failure in ISO 26262-1, 1.14

Dipl.-Ing. Jonas Wolf studierte Luft- und Raumfahrttechnik an der Universität Stuttgart. Er ist seit 2012 bei Vector und jetzt als Senior Product Management Engineer für funktionale Sicherheit und Cyber Security tätig. [email protected]

Automotive Cyber Security Lösungen von Vector

Bei der Entwicklung von Security-Steuergeräten profitieren Sie von der umfangreichen Vector Lösung aus Software-Tools, Embedded-Komponenten und Dienstleistungen: > Einheitliche Lösung für das Testen von Security-

> Flash Bootloader für das sichere Booten und

geschützten Steuergeräten und Netzwerken > Effizientes Testen von Security-Mechanismen durch

Aktualisieren der Steuergeräte-Software > Systematisches Security-Engineering sowie

Fuzz-Testing > Effiziente und konfigurierbare AUTOSAR-Basissoftware für die Realisierung von Security-Anforderungen

Erstellen und Validieren von Security-Konzepten Mehr Infos: www.vector.com/security_de

Entwickeln Sie Ihre Security-Projekte sicher und effizient mit den Lösungen von Vector.

aus Elektronik automotive 11.2015 7/20

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

ENTWICKLUNGSWERKZEUGE

ENTWICKLUNGSWERKZEUGE

Verschlüsselte Signalübertragung mit AUTOSAR in einem CAN-FD-Netzwerk

Bild 1: Botschaftsübertragung und Timing der verschlüsselten Kommunikation.

wurden, ob es sich also um authentische Daten handelt. Ebenso sind die Daten offen zugänglich. Folglich lässt sich durch eine Analyse der Businformationen auf den Signalinhalt schließen. Eine vertrauliche Übertragung findet also genauso wenig statt wie eine authentifizierte. Mit diesem Problem wurden die Ingenieure der Vector Informatik GmbH konfrontiert. Die Aufgabe bestand dar-

In aktuellen Fahrzeugnetzwerken erfolgt die Datenübertragung weitgehend ohne besondere Schutzmaßnahmen. Dadurch ist es beim Zugang zum Bussystem des Fahrzeugs möglich, die im Rohformat übertragenen Daten auszulesen

in, eine sichere Kommunikation auf einem CAN-Netzwerk zu realisieren, die flexibel einsetzbar ist und sich ebenfalls mit der AUTOSAR-3.x-Basissoftware integrieren lässt. Bei den Schutzzielen stand neben der Authentizität auch das Verhindern von Replay-Attacken im Vordergrund. Eine abhörsichere Kommunikation war gewünscht. Für die Verschlüsselung wählten die Spezialisten den AES-Algorithmus [3],

der aus heutiger Sicht als kryptografisch sicher gilt. Hier handelt es sich um eine symmetrische Blockchiffrierung mit einer Blocklänge von 128 Bits. Im Ergebnis erhält man somit 16 Bytes oder Vielfache davon, die vom Sender zum Empfänger zu übertragen sind. Vorteilhaft ist, dass manche Mikrocontroller bereits über sehr schnelle Hardware-Implementierungen für diesen Algorithmus verfügen.

oder gar verändert einzuspielen. Eine verschlüsselte Datenübertragung würde nicht nur sicherstellen, dass diese Informationen nur von autorisierten Empfängern auswertbar sind, auch ein Abhören oder Nachstellen der Nachrichten wäre zumin-

V

erfolgt man die Berichterstattung über Fahrzeugmanipulationen in den Medien [1, 2], stellt sich die Frage, ob dadurch tatsächlich Daten im Fahrzeugnetzwerk beeinflusst werden können. Gelingt es durch ein manipuliertes oder intern angebrachtes Gerät mit Fernsteuerfunktion Einfluss auf das

8/0

HANSER automotive 10 / 2014

Fahrzeugverhalten zu nehmen und welche Maßnahmen können dagegen getroffen werden? Aktuelle Fahrzeuge sind hochkomplexe Systeme, die aus vernetzten Sensoren und Aktoren bestehen und permanent wichtige Daten über Bussysteme übertragen. In den überwiegenden

Fällen liegen die Informationen bei der Übertragung im Rohdatenformat vor. Eine Plausibilitätsprüfung findet, soweit möglich, nur in gewissen Grenzen statt. Der Empfänger ist nicht in der Lage zu prüfen, ob diese Daten tatsächlich vom gewünschten Sender geliefert oder von einem Fremdsteuergerät eingestreut © Carl Hanser Verlag, München

Alle Bilder: Vector Informatik GmbH

dest erheblich erschwert.

Bild 2: ID-Keys mehrerer Empfänger bei Verwendung von CAN FD. www.hanser-automotive.de

HANSER automotive 10 / 2014

8/1

ENTWICKLUNGSWERKZEUGE

ENTWICKLUNGSWERKZEUGE

um eine Überlast des Bussystems zu vermeiden. Zur Stabilisierung des Protokolls überwacht die Empfängerseite die Antwort des Senders mit dem neuen Zählerwert durch den Timer T(Resent). Beim Ausbleiben einer Bestätigungsnachricht vom Sender, generiert der Receiver einen neuen ID-Key und sendet diesen erneut. Damit lässt sich auch ein kurzzeitiger Ausfall des Sendesteuergeräts abfangen und das Wiederaufsetzen verkürzen. Weiterhin vermeidet man das Ablegen des IDKeys im nichtflüchtigen Speicher.

Datenübertragung mit CAN FD ohne Segmentierung

Bild 3: Software komponenten zur verschlüsselten Übertragung.

Da eine CAN-Nachricht maximal acht Datenbytes in einem Frame überträgt, musste der Transfer über das bereits im Kommunikations-Stack enthaltene ISO-Transportprotokoll (TP) gewählt werden. Dies erforderte zur Vereinfachung der Konfiguration und des Protokolls für CAN eine gerichtete Kommunikation mit fester 1:1-Beziehung vom Sender zum Empfänger. Die symmetrische Verschlüsselung benötigt denselben Schlüssel auf Sender- und Empfängerseite. Die verwendeten Softwaremodule erlauben eine dynamische Zuordnung der Schlüssel zur Laufzeit, sodass der Anwender bzw. OEM ihn frei wählen kann. So lässt sich übergeordnet beispielsweise ein (asymmetrisches) Schlüsselaustauschverfahren implementieren oder aber auch eine statische Zuordnung realisieren, z. B. am Bandende. Beim Verwenden fahrzeugbezogener Schlüssel muss man bei einem Steuergerätetausch in der Werkstatt das autorisierte Einlernen des neuen Steuergeräts berücksichtigen, da der Schlüssel unter allen Umständen geheim zu halten ist.

8/2

HANSER automotive 10 / 2014

Replay-Attacken verhindern In dieser Konfiguration ist nun die verschlüsselte Übertragung der Nachrichten möglich, wobei die Informationen aber noch rein statisch sind, d. h., den Klartextsignalen lässt sich ein eindeutiger Chiffretext zuordnen. Dadurch sind Replay-Attacken, also das Mitschneiden und spätere Wiedereinspielen einer gewünschten Kommunikation, nach wie vor durchführbar. Denn der Empfänger kann nicht prüfen, ob die Nachricht tatsächlich zu diesem Zeitpunkt von diesem Sender stammt. Um hier eine Überprüfbarkeit zu erreichen, generiert der Empfänger beim Start der Kommunikation einen von ihm gewählten Zufallswert – im Folgenden als IDKey bezeichnet – und übermittelt ihn an den Sender. Dieser inkrementiert den Wert bei jedem Sendevorgang und fügt ihn der Sendenachricht hinzu. Der Empfänger prüft beim Eintreffen ob der IDKey dem erwarteten Wert entspricht. Ist dies der Fall, verarbeitet er die Nachricht, ansonsten verwirft er sie. Um mögliche Botschaftsverluste zu tolerie-

ren akzeptiert der Empfänger auch einen geringfügig größeren Wert. Somit führt der Zähler in der Sendenachricht zu einer permanenten Änderung der chiffrierten Daten auch bei gleichbleibenden Signalinhalten (Bild 1). Je nach Wortbreite des ID-Keys und der Sendehäufigkeit der Nachricht sind Überläufe im Zählerwert zu erwarten, die bei gleichbleibenden Signalen zu einer Wiederholung der Chiffrenachricht führen würden. Um dies zu vermeiden, erhält der ID-Key zusätzlich eine Gültigkeitsdauer. Läuft diese ab, muss der Empfänger einen neuen Wert generieren und dem Sender zuspielen. Unmittelbar nach Empfang eines neuen IDKeys überträgt der Sender die Chiffrenachricht. Damit ist der Empfänger auch in der Lage, das Wiederholen einer Nachricht anzustoßen, wenn beispielsweise der empfangene ID-Key nicht mit dem internen übereinstimmt, wodurch sich Latenzzeiten reduzieren. Die Senderseite empfängt und berücksichtigt für eine Zeit T(offset) zwar erneute ID-Key-Nachrichten, diese führen aber nicht mehr unmittelbar zu einem erneuten Senden der Chiffrenachricht, © Carl Hanser Verlag, München

Ein wesentlicher Nachteil stellt vor allem die segmentierte Datenübertragung bei CAN über das ISO15765-Transportprotokoll dar. Es erhöht die Übertragungszeit und erfordert die Einschränkung auf eine feste 1:1-Beziehung, da eine segmentierte Datenübertragung über ISO 15765 mit mehreren Teilnehmern nur sehr aufwendig realisierbar ist. CAN FD dagegen erlaubt es, die gesamte Chiffrenachricht gleichzeitig an mehrere Empfänger zu übermitteln [4]. Jeder Empfänger benötigt denselben symmetrischen Schlüssel zum Entschlüsseln der Chiffrenachricht. Für den ID-Key zur Authentifizierung kommen nun zwei Varianten in Frage: Entweder einigen sich alle Empfänger auf einen gemeinsamen abgestimmten Wert oder alle Empfänger generieren und senden unabhängig ihren ID-Key an den Sender. Dieser verwaltet alle Zähler und ergänzt die Datennachricht damit. Die Positionen der Zählerwerte in der Chiffrenachricht müssen den Empfängern eindeutig zugeordnet sein. Bild 2 zeigt die Datenübertragung für mehrere Empfänger. Zunächst übermitteln die Empfänger ihre jeweils generierten, zufälligen Startwerte an den Sender. Dieser inkrementiert alle ID-Keys pro Sendezyklus und fügt sie der Chiffrenachricht an der vordefinierten Position hinzu. Der entsprechende Empfänger prüft nun seinen ID-Key und akzeptiert die Daten oder verwirft sie.

Bei steigender Anzahl der Empfänger reduziert sich allerdings die verbleibende Anzahl der Nutzdatenbytes. Sie hängt auch maßgeblich von der gewählten Wortbreite des ID-Keys ab. Das Timing der Kommunikation ist wie in Bild 1 beschrieben anwendbar. Notwendig war lediglich eine Anpassung für den Sender beim Empfang des IDKeys. Statt der unmittelbaren Übertragung der Chiffrenachricht wartet der Sender eine einstellbare Zeit T(IdKeyReply), um eventuelle weitere ID-Key-Nachrichten anderer Empfänger mit zu berücksichtigen. Der Sonderfall T(IdKeyReply)=0 deckt das ursprüngliche Verfahren ab. Vector hat das Protokoll für CAN FD in einer CANoe-Umgebung implementiert. Mit diesem Software-Werkzeug zur Entwicklung, Simulation und zum Test von Steuergeräten und Netzwerken haben die Spezialisten es umfangreichen Tests unterzogen. Neben der geforderten Robustheit gegen ReplayAngriffe lag der Fokus unter anderem auf Untersuchungen von Botschaftsverlusten, Ausfall und Wiedereinstieg von Sender und Empfänger sowie TimingFehlern und Burst-Attacken. Das Verschlüsselungssystem lieferte in allen Fällen eine stabile Übertragung.

Fazit und Ausblick Mit vergleichsweise geringem Aufwand ist es insbesondere bei CAN FD gelungen, eine robuste Übertragung verschlüsselter Daten mit mehreren Teilnehmern zu realisieren, die sich auch in eine bestehende AUTOSAR3.x-Umgebung einpassen lässt. Ein Nachteil dort stellt die Serialisierung und Deserialisierung der Daten auf Anwenderebene dar (Bild 3), sodass die Modellierungseigenschaften der RTE für Einzelsignale nicht mehr nutzbar ist. Weiterhin muss man stets die klassischen Angriffspunkte solcher Systeme im Auge behalten. Dazu gehören etwa schwache Zufallszahlengeneratoren für die ID-Keys (beim Startup) oder das Ausspähen der symmetrischen Schlüssel. Der AES-128-Algorithmus gilt in der Fachwelt auch in naher Zukunft als si-

cher, die Implementierungen dafür sind ausgereift oder werden sogar durch entsprechende Hardware-Beschleunigungen unterstützt. Das hier vorgestellte Verfahren erschwert Angriffe auf die CAN(-FD)-Kommunikation erheblich und lässt Manipulationen ohne „Insiderwissen“ kaum durchführbar erscheinen. Es ist bereits seit einigen Jahren im Serieneinsatz und hat nebenbei auch zu einer günstigeren Einstufung des betreffenden Fahrzeugs in der Versicherungsprämie geführt. In diesem Fall schützt Security nicht nur, sondern bietet sogar dem Endanwender einen direkten Kostenvorteil. In naher Zukunft nehmen RemoteVerbindungen wie Car2x-Kommunikation, WLAN, Bluetooth und Internet weiter zu und stellen noch deutlich höhere Anforderungen an die IT-Security. Diese Zugänge müssen sicher gegen Angriffe sein und dürfen ferngesteuert keine Manipulationen zulassen. Dies gilt insbesondere für Informationen an Fahrerassistenzsysteme, die auf verlässlichen Nachrichten von anderen Verkehrsteilnehmern oder der Infrastruktur basieren. Bei der Analyse und Entwicklung solcher Systeme bietet Vector ebenfalls entsprechende Unterstützung an. W (oe) » www.vector.com Literatur: [1] http://www.chip.de/news/CAN-Hacking-ToolAutos-hacken-fuer-20-Dollar_67066892.html [2] http://www.can-newsletter.org/engineering/ engineering-miscellaneous/140822_list-ofpotentially-vulnerable-cars_blackhat/ [3] Advanced Encryption Standard (AES), FIPS PUB 197 [4] CAN with Flexible Data Rate – Specification Version 1.0, Robert Bosch, GmbH; April, 2012 http://www.bosch-semiconductors.de/en/ ubk_semiconductors/safe/ip_modules/ can_fd/can.html

Dipl.-Ing. Armin Happel ist Principal Software Development Engineer bei Vector Informatik im Bereich Research and Development for Innovative Applications und dort für den Bereich Applied Security zuständig. E-Mail: [email protected]

Impressum Verlag: Carl Hanser Verlag GmbH & Co. KG, Kolbergerstr. 22, 81679 München © Lizenzausgabe mit Genehmigung des Carl Hanser Verlags, München. Alle Rechte, auch die des Nachdrucks, der photomechanischen und der elektronischen Wiedergabe sowie der Übersetzung dieses Sonderdrucks behält sich der Verlag vor.

8/3

Integrierte Entwicklung von Safety- und Security-Anforderungen

externen Netzen vergrößern die Bedrohungen in Bezug auf

nisses mit dem sogenannten Safety Integrity Level quanti-

Die systematische Entwicklung von Safety-Anforderungen ist heute unabdingbar bei der Entwicklung von eingebetteten

Security.

fiziert. Für jedes relevante Gefährdungsereignis werden

Die Abhängigkeiten und Wechselwirkungen zwischen Safe-

anschließend noch relativ grobe Safety-Anforderungen, so-

ty- und Security-Anforderungen müssen im Requirements

genannte Safety-Ziele, identifiziert. In den nachfolgenden

Engineering methodisch sauber und systematisch betrach-

Designschritten werden die Safety-Ziele auf funktionale

tet werden. Die beschriebenen Zusammenhänge sind in

und technische Sicherheitsanforderungen heruntergebro-

Bild 1 visualisiert. Diese müssen in einer integrierten Vorge-

chen und den Elementen des System-Designs zugeordnet,

hensweise für die Entwicklung und Verifikation von Anfor-

die für die Realisierung der Anforderungen zuständig sind.

derungen beherrschbar gemacht werden. Momentan ge-

Gemeinsam bilden diese das Funktionale Sicherheitskon-

schieht dies eher unsystematisch, da die Industriestan-

zept. Alle weiteren Safety-Prozessschritte wie beispielsweise

Systemen. Die steigende Anzahl von Funktionen mit Anbindung an Backend- und Cloud-Dienste verlangen, dass Safety zunehmend zusammen mit Security betrachtet wird. Hierfür fehlt noch eine durchgängige Vorgehensweise. In diesem Beitrag wird eine Methodik für eine integrierte semiformale Entwicklung von Safety- und Security-Anforderungen vorgestellt. Die Vorteile dieser Safety/Security Requirements Engineering Methodik werden am Beispiel eines ADAS (Advanced Driver Assistance System) illustriert und das Potential einer Werkzeugunterstützung demonstriert.

8/4

1 Anforderungen für Safety und Security

Die gleiche Bedeutung hat die Absicherung gegen den Fall,

dards für Safety und Security noch stark voneinander

quantitative und qualitative Sicherheitsanalysen befinden

Überlebensnotwendige Cloud-Dienste wie Notfallsysteme

dass Funktionen ausgeführt werden ohne dass dies not-

isoliert aufgestellt sind. Wir wollen in diesem Beitrag auf

sich außerhalb des Scopes dieses Beitrags. Im folgenden Ab-

werden durch Überlastattacken lahm gelegt. Hacker drin-

wendig ist. Dabei kann ein Maßnahmenkatalog dazu bei-

die Integration der Vorgehensweise im Rahmen eines sys­

schnitt ergänzen wir diese Methodik um Vorgehensweisen zur

gen in Zugsteuerungen ein und verursachen Fehlfunktio-

tragen, dass die gewünschte Funktion unter verschiedenen

tematischen Requirements Engineering eingehen. In Ab-

Entwicklung und Verifikation von Security Anforderungen.

nen. Industrieanlagen werden durch Trojaner sabotiert. Im-

Randbedingungen erhalten bleibt. Entsprechende Überwa-

schnitt Entwicklung und Verifikation von Safety-Anforderun-

plantierte Medizintechnik wird über die Diagnoseschnitt-

chungsmaßnahmen stellen die ordnungsgemäße Ausfüh-

gen werden zunächst Ausschnitte der Vorgehensweise für

3 Entwicklung und Verifikation von Security Anforderungen

stelle manipuliert und versagt ihren Dienst. Wer kennt diese

rung sicher. Wir nennen den Begriff daher im Deutschen

Safety-­Anforderungen dargestellt. Wir beschränken diese

Analog zur Definition der Grundfunktionen des Systems

Schlagzeilen nicht? Die Sabotage von kritischer Infrastruk-

auch „funktionale Sicherheit“, oder im Englischen „Safety“.

Ausschnitte bewusst bis zur Erstellung der funktionalen Si-

werden auf dieser Basis die schützenswerten Assets und

tur ist nicht nur das Ziel von Terroristen, sondern leider auch

Abwesenheit von Gefahr bedeutet aber auch Vertrauen. Ich

cherheitsanforderungen, da die frühen Phasen prägend für

deren Besitzer identifiziert [2]. Ein Asset für einen Fahr-

zunehmen von Irre geleiteten Fachleuten. Der eine will da-

kann mich darauf verlassen, dass die Nachricht von einem

den Rest der Vorgehensweise sind. Diese bilden die Grund-

zeugbesitzer ist beispielsweise, dass seine Privatsphäre

mit die Ohnmacht unserer Gesellschaft demonstrieren, und

Übermittler auch wirklich von ihm stammt. Oder ich möch-

lage zur Integration der Vorgehensweise für Security-An-

nicht dadurch verletzt wird, dass seine Bewegungsprofile

der andere seine eigene Macht. Immer mehr eingebettete

te eine Nachricht übermitteln und dabei sicher sein, dass

forderungen die in Abschnitt Entwicklung und Verifikation

durch Dritte ausgewertet werden können. Bei der Bedro-

Systeme sind sicherheitskritisch. Kompromittierte Soft­ware

sie niemand beeinflussen kann. Dieser Begriff der Sicher-

von Security Anforderungen vorgestellt wird. Abschnitt 4

hungs- und Risiko-Analyse werden ausgehend von den

kann zum Ausfall kritischer Funktionen führen. Eine Insulin-

heit stellt im näheren Sinne das Themengebiet „Security“

illustriert die integrierte Vorgehensweise am Beispiel eines

­Assets Angreifer identifiziert, welche das Potential haben

pumpe, wie sie bei vielen Personen implantiert ist, kann von

dar. Es geht um Integrität, Authentizität und Vertraulich-

ADAS (Advanced Driver Assistance System). Das Potential

eine feindliche Aktion auf einen Angriffspunkt des Systems

einem informierten Hacker so beeinflusst werden, dass sie

keit von Informationen, weshalb man im deutschen auch

für eine Werkzeugunterstützung wird in Abschnitt Potenti-

durchzuführen und damit eine Bedrohung für das Asset

eine falsche Menge abgibt – mit möglicherweise tödlichen

von „Informationssicherheit“ spricht.

al für Werkzeugunterstützung dargestellt.

darstellen. Das Risiko ergibt sich aus dem Angriffspotential

Konsequenzen. Es ist höchste Zeit, Sicherheitsanforderungen

Qualität in einem System bedeutet grundsätzlich, dass das

nicht nur aus Softwarefehlern und zufälligen Fehlfunktionen

System alles das tut, was von ihm erwartet wird [1]. Die

2 Entwicklung und Verifikation von Safety-Anforderungen

abzuleiten, sondern die Aufmerksamkeit ganz gezielt auf

Verknüpfung von Safety und Security erweitert diese klas-

Zunächst wird das betrachtete System abgegrenzt und in

setzung geeigneter Security Goals auf ein akzeptables Maß

Angriffe im Sinne der Informationssicherheit zu lenken.

sische Definition im Sinne, dass das System sowohl bei

seinen Grundfunktionen beschrieben. Zusätzlich werden

reduzieren. Diese Zusammenhänge sind in Bild 2 dargestellt.

Funktionale Sicherheit und Informationssicherheit wach-

Ausfällen, menschlichen und technischen Fehlfunktionen

relevante Betriebs-Szenarien definiert. In der Gefahren-

In den nachfolgenden Designschritten werden die Security-­

sen zunehmend zusammen. Funktionale Sicherheit benö-

und auch bei einem böswilligen Angriff nichts tut, das von

und Risiko-Analyse werden ausgehend von den Grundfunk-

Ziele auf funktionale Security-Anforderungen herunterge-

tigt eine verlässliche Informationssicherheit, egal ob es sich

ihm nicht erwartet wird. Wir werden in diesem Beitrag zur

tionen und möglichen Fehlfunktionen sogenannte Gefähr-

brochen und den Elementen des System-Designs zugeord-

um Fahrzeuge, Medizintechnik oder Automatisierung han-

besseren Nachvollziehbarkeit der verschiedenen Semantik

dungsereignisse abgeleitet. Unter Beachtung der relevanten

net, die für die Realisierung der Anforderungen ­zuständig

delt. Dabei stehen Anforderungen an die Sicherheit und da-

und damit auch der unterschiedlichen methodischen Vorge-

Betriebsszenarien wird das Risiko des Gefährdungsereig-

sind. Gemeinsam bilden diese das Funktionale Security-­

mit ein nachvollziehbares und konsequentes und durchgän-

hensweisen die Begriffe „Safety“ und „Security“ verwenden.

giges Requirements Engineering im Mittelpunkt. Das Ziel

Funktionale Sicherheit, also „Safety“ ist ohne Informations-

der integrierten Entwicklung von Safety und Security ist die

sicherheit, also „Security“ in Zukunft nicht mehr ausrei-

Entwicklung von Funktionen, die möglichst robust auf tech-

chend. Das zeigt sich an zwei wesentlichen Trends. Die ste-

nische und menschliche Fehler sowie Angriffe von außen

tig steigende Vernetzung von Funktionen sowie die Ent-

reagieren und so das Risiko von Gefährdungssituationen

wicklung zunehmend autonom agierender Diagnose- und

auf ein akzeptables Maß begrenzen. Der Beitrag zeigt, wie

Assistenzsysteme. Beide Trends haben als Folge eine wach-

funktionale Sicherheit und Informationssicherheit in sol-

sende Anzahl von potentiell sicherheitsrelevanten Funktio-

chen Systemen aus Sicht des Requirements Engineering

nen. Als relativ neuer Trend ist die wachsende Vernetzung

erfolgreich realisiert werden kann.

von Fahrzeugfunktionen mit Back-End-Diensten von Fahr-

Der Begriff „Sicherheit“ hat in der deutschen Sprache zwei

zeugherstellern oder IT-Cloud-Diensten erkennbar. Diese

Bedeutungen. Sicherheit bedeutet die Abwesenheit von

Vernetzung eröffnet vollkommen neue Dienste und Ge-

Gefahr. Die Nutzung eines Produkts oder einer Funktion

schäftsmodelle wie beispielsweise die Nachrüstung von

darf keine Gefahr für Gesundheit oder Leben des Nutzers

Funktionen per Software-Update oder die Kommunikation

und seiner Umwelt verursachen. Der Produzent und damit

zwischen Geräten, beispielsweise IT und Automatisierungs-

die Entwickler einer Funktion müssen sicherstellen, dass

technik in der Industrie 4.0. Diese Verknüpfung ganz unter-

diese Funktion zur Verfügung steht, wenn sie benötigt wird.

schiedlicher Komponenten und deren Netze mit offenen

sowie dem Schweregrad der Bedrohung. Die Besitzer der

System:

Assets wollen das Risiko der Bedrohungen mit Hilfe der Um-

Funktion: Korrigierender Lenkeingriff

Asset: Schutz der Assistenzfunktion vor Manipulation

Gefahren-Analyse

Bedrohungs-Analyse

Anforderungen an Safety

Anforderungen an Security

z.B.: Spurhalteassistent

Neue Funktionen mit Mehrwert und mit beherrschtem Risiko

Bild 1: Requirements Engineering identifiziert Wechselwirkungen und Abhängigkeiten von Safety und Security

8/5

Integrierte Entwicklung von Safety- und Security- Anforderungen

Potenzial für Angriff auf

Asset

Angriffspotenzial

hat einen Wert für

Bedrohung

Potenzial für Durchführung von

hat

Angreifer

Besitzer

Potenzial mit Risiko für

Risiko wird reduziert durch

Feindliche Aktion

Security Goal

wird ausgeführt auf

Angriffspunkt

heit, beispielsweise um unbeabsichtigte Lenk- und Brems­

matischen Lenkeingriff nachdem das Verlassen der Spur

manöver zu vermeiden. Die Vernetzung ganz unterschied­

erkannt wurde und eine Warnzeit verstrichen ist.“ Als für

licher Informationsquellen aus der Sensorfusion wie Radar

das SHA-System relevante Betriebssituation wurde u.a. die

und Kamerasystemen sowie verschiedenen Steuergeräten

folgende relevante Betriebssituation BS1 identifiziert:

im Fahrzeug verlangt nach einer sorgfältigen Absicherung

„Fahren auf Landstraßen, entgegenkommender Verkehr,

gegen Eingriffe von außen. Diese Anforderungen beeinflus-

Geschwindigkeit > 50 km/h“. Im Rahmen der Gefahren- und

sen sich gegenseitig in ihrer methodischen Umsetzung und

Risiko-Analyse wurde die Fehlfunktion FF1 für F1 identifi-

müssen daher gemeinsam entwickelt werden. Das wollen

ziert: „Das Gegenlenken wird durchgeführt, allerdings in die

wir anhand der beschriebenen Methodik demonstrieren.

falsche Richtung“. Aus dem Zusammenspiel von F1, FF1 und BS1 ergibt sich das Gefährdungsereignis H1:“ Er erfolgt ein

Identifikation von Grundfunktionen und Ableitung von

Zusammenstoß mit dem entgegenkommenden Verkehr.“.

Safety-Zielen

Um die Relevanz von H1 zu bewerten, werden als Kriterien

Im Rahmen der System-Definition werden zunächst die

die Auftretenswahrscheinlichkeit E, der Schweregrad S und

Grundfunktionen identifiziert und im Rahmen der Gefah-

die Kontrollierbarkeit C herangezogen. Zur Vermeidung von

ren- und Risikoanalyse die Safety-Ziele abgeleitet.

H1 wird das Sicherheitsziel SG1 definiert: „Vermeide nicht

Für das SHA-Beispiel u.a. die folgende Grundfunktion F1

plausiblen Lenkeingriff des SHA-Systems.“

identifiziert: „Der Spurhalteassistent startet einen auto-

Bild 2: Zusammenhänge bei der Bedrohungs- und Risiko-Analyse

Konzept. Analog zur Safety Vorgehensweise befinden sich

lassen der Spur warnt und falls nötig einen Lenkeingriff

alle weiteren Security-Prozessschritte außerhalb des Fokus

vornimmt, um das Fahrzeug zurück in die Spur zu lenken.

dieses Beitrags. Bild 3 stellt die betrachteten Security-Akti-

Das System verfügt über eine Reihe von Sensoren zur Er-

vitäten und ihre Beziehung zum Gesamtprozess sowie zu

fassung des Umfelds sowie eine Reihe von Aktuatoren für

den Safety-Aktivitäten vereinfacht dar.

Fahreingriffe und die Benachrichtigung des Fahrers. In Bild 4 ist die vorgegebene Systemstruktur dargestellt.

4 Fallstudie: ADAS System

An diesem Beispiel werden die Gemeinsamkeiten und Un-

Beispielhaft wird im Folgenden ein Teil-System eines ADAS

terschiede bei Entwicklung von Safety- und Security Anfor-

(Advanced Driver Assistance System) für ein Automobil be-

derungen in den frühen Phasen verdeutlicht.

trachtet. Dieses Teil-System ist ein Spurhalte-Assistent

Aufgrund der direkten Einwirkungen in die Fahrdynamik

(SHA), welches den Fahrer vor dem unbeabsichtigten Ver-

hat das System Anforderungen an die funktionale Sicher-

Attack: Delay or Remove Warning Messages

Advanced Driver Assistance System Sensor Fusion

Night Vision Front Camera

Central Processor

Steering Column

Front Camera

Electronic Brake

Mid Range Front Radar

Driver Display

Watchdog

Long-Range Front Radar

RAM RAM ROM

Schutzziele, Bedrohungen, RisikoAssessment

Op. Szenarien, Gefahren, RisikoAssessment

Security-Ziele und Anforderungen

Safety-Ziele und Anforderungen

Technisches Security Konzept

Security Implementierung

Funktionales und technisches Safety Konzept Safety Implementierung

Safety Case, Zertifizierung, Abnahme

Security Case, Audit, Compliance

Safety Validierung

Security Validierung

Test der Safety Funktionen

Safety Verifikation

NIGHT VISION CAMERA

REVERSE CAMERA

VIDEO CAMERA

Test der Security Funktionen

Security Verifikation Safety Methodik Security Methodik

8/6

ROM

Bild 3: Gemeinsame ­Betrachtung von Safety und Security Anforderungen

LONG-RANGE RADAR

MID-RANGE RADAR FRONT

ULTRASOUND

MID-RANGE RADAR BACK

Bild 4: Grobe System Struktur des ADAS ­(Teilsystem Spurhalteassistent)

8/7

Integrierte Entwicklung von Safety- und Security- Anforderungen

Identifikation von Assets und Ableitung von Security-Zielen

werden. Dazu gehört das Potential der Bedrohung Safety-­

Nach der Ableitung der Safety und Security Ziele kann die

Im Rahmen der System-Definition werden zunächst die schüt­

Ziele zu verletzen, aber auch das Potential der Bedrohung

weitere Verfeinerung auf die funktionale und technische

ability, Verifikation, Modellierung und Testorientierung soll-

zenswerten Assets identifiziert und im Rahmen der Bedro-

für operative und finanzielle Schäden des Asset-Besitzers

Anforderungseben erfolgen. Zu jeder Phase ist es sinnvoll

ten gemeinsam angewandt werden. Vorgehensweisen wie

hungs- und Risikoanalyse die Security-Ziele abgeleitet.

B1. Als Security-Goal zur Begegnung der Bedrohung wird

die Anforderungen durch Allokation an der (vorläufigen)

die Einforderung von „Common Criteria“ in der Informa­

Im Rahmen der Asset-Definition wird unter anderem das

SCG1 abgeleitet: „SW- und HW Security-Schutzmechanis-

funktionalen bzw. technischen Architektur zu spiegeln.

tionstechnik können dafür relativ einfach – und damit kos-

thodische Vorgehensweisen für Konsistenzsicherung, Trace­

Asset A1 definiert: „Der Spurhalteassistent verhält sich in-

men müssen sicherstellen, dass Software- und Konfigurati-

nerhalb seiner Spezifikation“. Asset-Besitzer B1 ist der Fahr-

onsparameter für das SHA-System nicht verfälscht oder

5 Potential für Werkzeugunterstützung

tenorientiert – für funktionale Sicherheit und spezifische Anwendungen erweitert werden. Eine semiformale Spezifi-

zeughersteller. Der Angreifer AT1 ist ein erfahrener ­Hacker.

verzögert werden können, ohne dass dies unerkannt bleibt.“

Bei klassischen Werkzeugketten wie sie heute bei der Ent-

kation von Safety- und Security-Anforderungen zusammen

Ein Angreifer dieser Ausprägung verfügt typischerweise

In der nachfolgenden Tabelle sind die Gemeinsamkeiten

wicklung von Systemen eingesetzt werden, sind die Prozes-

mit geeigneter Werkzeugunterstützung trägt dazu bei, die

über die prinzipiellen Fähigkeiten des Reverse Engineering

und Unterschiede bei der Ermittlung von Safety- und Secu-

se, die in Abschnitt Entwicklung und Verifikation von Safe-

Komplexität und Aufwände beherrschbar zu halten.

von Hardware und Software und die Möglichkeit über

rity-Anforderungen zusammenfassend dargestellt.

ty-Anforderungen und Entwicklung und Verifikation von

­Remote-Schnittstellen privilegierte Schadsoftware zu ins-

Security Anforderungen beschrieben wurden stark fragmen-

Beitrag für ObjektSpektrum zum Themenspecial Require-

tallieren, die mit dem Rest des Systems kommuniziert. AT1

tiert. Anforderungs-Entwicklung, Funktions-Design sowie

ments Engineering

kann die Feindliche Aktion FA1 durchführen: „Unterdrücke Nachrichten an die Aktuatoren beim Verlassen der Fahrspur durch Manipulation der Funktionssoftware.“ Als Angriffspunkt AP1 wurde die Manipulation der Software des ADAS Systems durch ein nicht autorisiertes Software-Update identifiziert. Das Angriffspotential des Angreifers wird anhand von mehrdimensionalen Kriterien bewertet. Zu diesen Kriterien zählen unter anderem das Wissen des

Safety

Security

System und Top-­Level Funktionen

System und zu ­schützende Assets

Ermittlung der Top-Level-­ Anforderungsebene

Risiko-basierte Ableitung von ­Safety-Zielen über Betrachtung der Fehlunktionen der ­Systemfunktionen

Risiko-basierte ­Ableitung von ­Security-Zielen über Betrachtung von ­möglichen Angriffen auf Assets

Risiko­ bewertung

Risiko für ein Gefährdungsereignis wird ­bewertet über Auftretenswahrscheinlichkeit, Schweregrad ­sowie Kontrollierbarkeit des Gefährdungsereignisses durch den ­Benutzer

Risiko einer Bedrohung wird bewertet über Angriffs­ potential des Angreifers und Schweregrad der ­Bedrohung. Der Schweregrad teilt sich auf in die ­Bewertungsdimensionen Funk­tionale Sicherheit, Wirtschaftliche Kosten und Privatsphäre.

Ausgangspunkt

Angreifers über das System, die technische Ausrüstung des Angreifers sowie die benötigte Zeit für das Ausführen eines Angriffs. Der Angriff auf das Asset führt zu der Bedrohung T1: „Das Fahrzeug verhält sich wie bei ausgeschaltetem System ohne dass dies dem Fahrer bewusst ist. Dadurch kann es zu Unfällen kommen, die dem Hersteller angelastet werden.“ Der Schweregrad dieser Bedrohung kann nun anhand verschiedener Security-relevanter Kriterien bewertet

Tabelle 1: Vergleich der Herangehensweise bei Safety- und ­Security Anforderungen

Safety- und Security Analysen werden mit verschiedenen Werkzeugen durchgeführt, wobei die Schnittstellen oft kei-

URLs zum Beitrag:

nen verlustfreien Austausch ermöglichen.

1. Buch “Systematisches Requirements Engineering”

Dadurch ist beispielsweise die Konsistenz der Safety- und



Security Ziele und der daraus abgeleiteten Anforderungen

2.  Beiträge zu Informationssicherheit und funktionaler

mit dem System Design nur mit großem Aufwand über den gesamten Lebenszyklus hinweg sicherzustellen. Als Schritt hin zu einem integrierten Safety und Security-­

Kurz-URL: www.vector.com/RE-Buch ­Sicher­heit:

 Kurz-URL: www.vector.com/security, www.vector.com/­ safety

Konzept und der weiterführenden Verfeinerung der Anforderungen sollten die Safety- und Security-Ziele der vorläu-

Literatur:

figen Architektur zugeordnet. Dies hat den Vorteil dass

[1] Ebert, C.: Systematisches Requirements Engineering.

bereits früh eine Verfolgbarkeit von Anforderungen auf die

Dpunkt-Verlag, Heidelberg, Germany, 5. komplett überar-

Konzeptebene gegeben ist. Ebenso können dadurch poten-

beitete Auflage, 2014.

tielle Wiedersprüche und Konflikte zwischen Safety- und

[2] CCRA, „ISO/IEC 15408: Common Criteria for Information

Security-Anforderungen an System-Elemente früh erkannt

Technology Security Evaluation,“ 2012.

und aufgelöst werden. Dazu ist es vorteilhaft wenn Werkzeuge in der Lage sind die Anforderungsentwicklung und das System-Design integriert zu unterstützen. Dieses er-

Christof Ebert ist Geschäftsführer der Vector Consulting Services GmbH und Professor an der Universität Stuttgart

möglicht die in Bild 5 dargestellte graphische Visualisierung Lane Position / -;R+1 (Sense)

Keep Vehicle in Lane / -;R+1 (Logical Function) Alarm:LKAAlarm LanePosition:LanePosition

Lane Position:LanePosition {-/LanePositio…

Sound Alarm / -;R+1 (Actuation) Alarm:LKAAlarm {-/AlarmCode/-} Warn Driver when leaving lane

sprüche rasch zu erfassen. In Bild 2 haben wir die Zusammenhänge von Security-­Zielen mit Feindlichen Aktionen und Assets gezeigt. Solche Zu-

Indicators / -;R+1 (Sense) Indicator Position:IndicatorStatus {-/IndicatorStat…

Indicators:IndicatorStatus LKAWarning:LKAWarning

{-/WarningCod…

Vehicle Speed / -;R+1 (Sense)

Display Warning / -;R+1 (Actuation) DisplayText:LKAWarning

sammenhänge lassen sich in gerade in integrierten Werk-

Warn Driver when leaving lane

formalisieren, um Lücken und Unvollständigkeiten in Anfor-

{-/VehicleSpee…

CounterSteering:CounterSteering

ASIL Colours Functions

Brake Pedal / -;R+1 (Sense)

ASIL undefined / -;- (Sense) BrakePedal:BreakPedalStatus

BC:BreakPedalStatus {-/BrakeComm…

LKAStatus:LKAStatus AngularSpeedOfSteering_SteeringW…

SWP:SteeringWheelStatus

Allocated Requirements unassigned

ASIL A ASIL B

ASIL A / -;- (Logical Function)

ASIL C ASIL D

{-/SteeringWhe… ASIL B / -;- (Actuation) Inhibit unintentional steering action Assure activation above 30 km/h Assure activation after warning time Assure correct direction of counter steering

Bild 5: Allokation von ­Safety-Zielen auf ­System-Elemente

zeugen für mustergestützte Konsistenzprüfungen leicht

von Anforderungen geschieht hat dies das Potential Aufwände für manuelle Reviews zu reduzieren.

QM QM / -;- (Logical Function)

Angular Speed of Steering / -;R…

Eduard Metzker ist Solution Manager für Cyber Security bei der Vector Informatik GmbH

derungen zu erkennen. Wenn dies während der Entwicklung

VehicleSpeed:Speed

Current Speed:Speed

8/8

der Allokation. Mit Hilfe solcher Darstellungen sind Wieder-

ASIL C / -;- (Logical Function)

ASIL D / -;- (Logical Function)

6 Zusammenfassung und Ausblick Requirements Engineering bei sicherheitskritischen Systemen muss Anforderungen an die funktionale Sicherheit und an die Informationssicherheit systematisch parallel ent­ wickeln und bewerten. Die bisher etablierte Trennung der zwei „Disziplinen“ mit jeweils eigenen Standards und Vorgehensweisen ist nicht länger tragfähig, da Abhängigkeiten und gegenseitige Beeinflussungen übersehen werden. Zudem ist eine getrennte Vorgehensweise ineffizient, da viele Funktionen mehrere Male angefasst werden müssen. Me-

8/9

Sicherheit Security

Cybersecurity mit überschaubarem aufwand umsetzen Funktionale Sicherheit braucht Informationssicherheit

Bilder: www.vector.com/trends

Sicherheit Security

60%

Zukünftige Herausforderungen

50% 40%

Big Data

Autoren: Dr. Christof Ebert, Dr. Nico Adler

A

Wieviel Security braucht Safety? Cybersecurity ist in kurzer Zeit zu einem der intensiv diskutierten Themen der Automobilelektronik geworden. Typische Fragen i n d iesem Zusa m men ha ng beschäftigen sich mit der Verwundbarkeit der Fahrzeugelektronik und der Zielset8/10

38

Automobil ElEktronik 03-04/2016

zung, wie sich Funktionen, etwa ADAS oder OTA-Updates, nachvollziehbar sicher realisieren lassen. Doch wieviel Security braucht Safety eigentlich? Sicher ist, die Fahrzeugelektronik ist angreifbar. Viele Funktionen sind aufgrund der hohen funktionalen Komplexität und Vernetzung direkt oder mittelbar sicherheitskritisch. Funktionale Sicherheit braucht Informationssicherheit (IS). Was für viele Autofahrer ein Fahrerlebnis mit tollen Funktionen ist, bedeutet für Ingenieure und Führungskräfte ein Sicherheitsrisiko – im Produkt und persönlich aufgrund der Haftungsrisiken. Kosten und Komplexität der Produktentwicklung bleiben branchenübergreifend die größten Herausforderungen. Funktionale Sicherheit und Cybersecurity sind 2016 als Paket jedoch schnell in den Vordergrund gerückt.

Konnektivität

Sicherheit hat zwei Bedeutungen Safety und Security gehören zusammen. Das zeigt auch die deutsche Etymologie. Wir verwenden den Begriff „Sicherheit“ im Deutschen mit zwei Bedeutungen. Sicherheit bedeutet die Abwesenheit von Gefahr. Die Nutzung eines Produkts oder einer Funktion darf keine Gefahr für die Gesundheit oder das Leben des Nutzers und seiner Umwelt verursachen. Der Produzent und damit die Entwickler einer Funktion müssen sicherstellen, dass diese Funktion über einen längeren Zeitraum erhalten bleibt. Sicherheit bedeutet aber auch Vertrauen. So müssen sich Nutzer darauf verlassen können, dass die Systeme und Funktionen keiner Manipulation ausgesetzt und die Daten geschützt sind. Dieser Begriff der Sicherheit stellt im näheren Sinne das Themengebiet

Eck-DatEn Zur Abwehr intelligenter Angriffe auf die Fahrzeugelektronik müssen die Verantwortlichen wirkungsvolle Maßnahmen sowohl im Produkt als auch im Entwicklungsprozess und im Feld umsetzen. Noch viel wichtiger ist aber die systematische Umsetzung der getroffenen Maßnahmen und die Prüfung ihrer Wirkung, um auf dieser Basis Sicherheitsmaßnahmen zielorientiert zu verbessern. Wie sich Informationssicherheit mit überschaubarem Aufwand umsetzen lässt, veranschaulicht dieser Beitrag.

www.automobil-elektronik.de

Effizienz und Kosten Komplexität

30%

0%

Bild 1: Herausforderungen in der Elektronikentwicklung, die sich im Rahmen einer Umfrage herauskristallisierten.

Verteilte Entwicklung Governance

10%

utonomes Fahren schafft Sicherheit, da die Fahrzeugelektronik stets hellwach ist. Doch mit was beschäftigen sich die elektronischen Helfer eigentlich? Ist die Elektronik so verlässlich, wie man es von ihr erwartet? Das Beispiel Infotainment veranschaulicht den Sachverhalt. Ein Fahrer fährt durch Assistenzsysteme in Spur und Abstand geführt auf der Autobahn. Multisensorsysteme wiegen ihn in vermeintlicher Sicherheit. Plötzlich ertönt ein schriller Pfeifton im Lautsprecher. Der Fahrer reagiert falsch und verursacht einen Unfall. Mit wachsender Komplexität und Vernetzung, der Nutzung von Standardkomponenten sowie offenen Schnittstellen werden die verschiedenen Elektroniksysteme, vor allem im Infotainment, zunehmend angreifbarer und verlangen wirkungsvolle Schutzmaßnahmen.

Innovative Produkte

20%

Viele Funktionen in modernen Fahrzeugen sind aufgrund der hohen funktionalen Komplexität und der enormen Vernetzung direkt oder mittelbar sicherheitsrelevant. Um wichtige Fahrzeugfunktionen wie Fahrerassistenzsysteme (ADAS) oder OTASchnittstellen vor bösartigen Manipulationsversuchen von außen erfolgreich zu schützen, muss eine gute Portion Informationssicherheit in die Entwicklung einfließen.

Safety und Security

Andere 0%

10%

Aktuelle Herausforderungen 20%

30%

40%

„Security“ dar. Es geht um Integrität, Authentizität und Vertraulichkeit von Informationen, weshalb man im Deutschen auch von Informationssicherheit spricht. Die Methodik des „Security Engineering“ lässt sich nicht einfach 1:1 aus der Informationstechnik (IT) übertragen. Ganz anders als in der IT und der Anwendungssoftware geht es bei Fahrzeugen heute um eine komplexe IT-Infrastruktur mit eingebetteten Systemen von fünfzig bis hundert Steuergeräten im Fahrzeug sowie einer schnell wachsenden ITInfrastruktur in der Cloud für Diagnose, Kommunikation und zunehmend auch Software-Aktualisierungen, wie das Beispiel des US-amerikanischen Unternehmens Tesla zeigt. Dies alles erfolgt in einem regulierten Rahmen, mit Milliarden Nutzern weltweit, und unter hohen Anforderungen an die funktionale Sicherheit des Fahrzeugs. Durch die dafür notwendige komplexe Software und IT dürfen betriebsunabhängig keine Schäden entstehen, weder für Personen noch für die Daten und Informationen der Nutzer, Eigentümer und Hersteller. Im weiteren Verlauf widmet sich dieser Fachbeitrag der nachhaltigen und durchgängigen Umsetzung von Informationssicherheit in sicherheitskritischen Systemen. Der Fokus liegt dabei auf der Automobilbranche, da sie aktuell die höchsten Anforderungen an moderne IT-Systeme stellt. Wie keine andere Branche befinden sich dort ganz unterschiedliche IT- und Software-Systeme im Einsatz und sind miteinander verknüpft – und das bei einem weltweit einzigartigen Wachstum und Innovationstempo. www.automobil-elektronik.de

50%

60%

70%

Informationssicherheit und funktionale Sicherheit Die Bedrohungsszenarien in der Automobilbranche verändern sich derzeit stark. Als besonders akut gelten solche Risiken dort, wo Informationssicherheit und funktionale Sicherheit zusammenkommen. Diese Bedrohungen wachsen, denn der zunehmende Einsatz standardisierter Komponenten und offener Schnittstellen ruft Angreifer oder Hacker auf den Plan, die sich immer neue Herausforderungen suchen. Durch die zunehmende Vernetzung auf verschiedenen Ebenen, sowohl innerhalb des Fahrzeugs als auch nach außen hin, entsteht eine noch nie da gewesene Komplexität. Diese Komplexität führt dazu, dass nicht mehr alle Kombinationen von Ereignissen und Funktionen in gleichem Ausmaß wie bisher beherrschbar sind. Es ist eine Frage der Zeit, bis Angreifer hierdurch entstandene Schwächen identifizieren und missbrauchen. Beispielsweise lassen sich Bussysteme wie CAN von außen relativ leicht in Überlastsituationen bringen, die dann zu Fehlverhalten führen. Heute übliche Kommunikationssysteme, wie sie immer häufiger Einzug ins Auto halten, bieten offene Schnittstellen. Man denke beispielsweise an DVDs, USB, Bluetooth und Wartungsschnittstellen, über die sich Viren und Trojaner in die jeweiligen eingebetteten Betriebssysteme einbringen lassen. Schließlich können fehlerhafte Codes und Konfigurationen zu vielfältigen, unbekannten Angriffspunkten führen. Einige aktuelle Beispiele aus untersuchten Fahrzeugen veranschaulichen die Bedrohungsszenarien. Viele Komfortfunktionen lassen sich heute von außen beeinflussen und konfigurieren. Nicht nur das Infotainment sondern zunehmend die gesamte Elektronik weist über OTA-

Updates Schnittstellen nach außen auf. Mit diesen Konfigurationen können sich Angreifer mit Fahrzeugen über externe Kommunikations- und Unterhaltungssysteme verbinden und Netzwerkschwachstellen nutzen, um wesentliche Funktionen anzugreifen. Dies kann aufgrund der engen Verknüpfung mit sicherheitsrelevanten Anforderungen wie beispielsweise Bremssysteme verheerende Folgen haben. Die Ursachen für unzureichende Informationssicherheit zeigt Tabelle 1 anhand von vergleichsweise einfachen Beispielen aus der Praxis von Vector Consulting. Sie sind gemäß der ursächlichen Entstehungsszenarien im Produkt (Funktionen, Architektur und Konfigurationen), im Prozess (Entwicklung, Prüfung und Kommunikation) sowie im Feld (Wartung, Updates und Erweiterungen) unterschieden. Security Engineering ist im Fahrzeug wie auch die funktionale Sicherheit derzeit noch stark auf Funktionen und Komponenten ausgerichtet. Eine systemische Bewertung und Absicherung wird aus Komplexitätsgründen erst langsam aufgebaut. Einzelne Komponenten schützt man beispielsweise durch eine verschlüsselte Freischaltung von Flashware. Sensible Funktionen wie Motormanagement, Wegfahrsperre oder Diagnoseschnittstellen sind individuell zu prüfen. Darüber hinaus finden Mechanismen der funktionalen Sicherheit (Safety) wie beispielsweise die Orientierung an Automotive Safety Integrity Levels (ASILs) Verwendung. Diese decken allerdings die Informationssicherheit nicht ab, da sie von einem zufälligen Ausfall von Komponenten ausgehen und nicht von einem böswilligen Angriff. Zudem liegt der Fokus heute primär auf einzelnen Komponenten und nicht auf einer systematischen Abhärtung auf Systemebene mit Netzwerken und Architekturen. Insofern sind Sicherheitstechniken wie die durchgängige Prüfung kritischer Bedrohungsszenarien, Datenschutz, Fehlerbehandlung, Monitoring oder Selbsttest im Rahmen von Informationssicherheit noch stringenter anzuwenden als bei der funktionalen Sicherheit. Informationssicherheit müssen die Entwickler für das gesamte Fahrzeug adressieren. Maßnahmen zur Informationssicherheit verlangen ein system- und lebenszyklusübergreifendes Konzept – vor allem, Automobil ElEktronik 03-04/2016

39

8/11

Sicherheit Security

Ursache

Im Produkt

Im Prozess

Im Feld

Nicht-Wissen

• Architektur unterstützt IS nicht • Komponenten sind einzeln gehärtet, aber nicht das System, in dem sie eingesetzt werden

• Fehlende Anforderungen zu IS • Unzureichende Prüfungen im Lebenszyklus • Unzureichende Checklisten und Design-Richtlinien

• Änderungen werden nicht hinreichend rigoros getestet. • Die Folgen auf das ISKonzeptes durch den Austausch einer Komponente für eine neuere Version werden nicht berücksichtigt

Nicht-Wollen

• Erfahrungen aus anderen Produkten oder Branchen werden nicht berücksichtigt • IS wird nur auf Basis von Firewalls, Gateways und Komponentenschutz angestrebt

• Fehlende Kommunikation zwischen Entwicklern und IS-Experten • Entwicklungsprozesse auf Systemebene ohne ISVorgaben

• Neue Entwicklungsstände werden in der Produktion und After-Sales eingesetzt ohne dass die ISFreigabeprozesse eingehalten werden

Nicht-Können

• Unzureichende Ausbildung für IS in der SW- und Systementwicklung • Unbekannte Bedrohungsszenarien • Angreifbare Bussysteme sind trotz abgeschalteter Zündung aktiv

• Unbekannter Stand der Technik bei Verifikationswerkzeugen und Testmethoden für IS • Fehlende Anforderungen und Kriterien zur IS • Nichtproprietäre oder offene Komponenten werden ohne IS-Strategie und Prüfung der IS eingesetzt

• Nicht freigegebene Software oder Medien werden genutzt • Nicht zugelassene Nachrüstgeräte werden eingebaut ohne dabei die Konsequenzen für andere Systeme zu kennen (z.B: Überlastung des Netzwerks)

Tabelle 1: Ursachen und Beispiele für Risiken in der Informationssicherheit im Lebenszyklus.

Zustand

Funktion

Gebrauchsszenario

Missbrauchsszenario

Zündung aktiviert

Fenster öffnen (Normalfall)

Öffne Fenster bei aktivierter Zündung und betätigtem Fensterheber

Öffne Fenster bei aktivierter Zündung, ohne Betätigung des Fensterhebers

Zündung deaktiviert

Fenster öffnen (Notfall)

Öffne Fenster bei deaktivierter Zündung und betätigtem Fensterheber, wenn Personen im Auto sind

Öffne Fenster bei deaktivierter Zündung, ohne dass Personen im Auto sind

Tabelle 2: Sicherheitsanalyse am Beispiel einer Fenstersteuerung (Ausschnitt).

wenn deren Wirksamkeit zu einem späteren Zeitpunkt aus rechtlichen Gründen nachzuweisen ist. Wie Fachleute bereits in der Kommunikationstechnik vor einigen Jahren erkannten, reichen isolierte Mechanismen wie die Aufteilung in proprietäre Teilsysteme, der Schutz einzelner Komponenten, Gateways und Firewalls zwischen den Komponenten und das Testen kritischer Funktionen allein nicht aus. Doch wie werden Autos sicher? Wie härtet man Fahrzeug-IT ab? Eines der sichersten bekannten Fahrzeuge hat eine komplette Trennung der drahtlosen Kommunikationssysteme von Rechnern und Netzen, die die wesentlichen AutomotiveAktivitäten kontrollieren. Wichtig für Security Engineering sind zwei Aspekte: Bedrohungsszenarien gehen über Einzelfunktionen hinaus, und sie greifen ein System im Zusammenspiel aller seiner Funktionen und Komponenten an. Informationssicherheit ist aufgrund absichtlich eingeschleuster Fehlerursa8/12

40

Automobil ElEktronik 03-04/2016

chen viel schwieriger zu gewährleisten als die Vermeidung von Fehlfunktionen einzelner Komponenten, wie man sie bei funktionaler Sicherheit betrachtet. Das Problem besteht darin, dass handelsübliche Technologien und offene Schnittstellen gemeinsam mit einer kaum beherrschten Komplexität und einer Architektur, die Sicherheit nur auf Komponentenebene unterstützt, Angreifer und Zufälle geradezu einladen. Korrekturen, Upgrades und nachträgliche Softwareverbesserungen lassen sich in solchen Konfigurationen nicht mehr hinreichend sicher verteilen.

Security: anders als in der IT Cybersecurity im Automobil ist nicht mit den aus der IT bekannten Techniken wie Firewalls mit Gateways gleichzusetzen. Firewalls können die Übertragung unerlaubter Signale von einem (unsicheren) Netzwerk in ein anderes verhindern. Realistische Bedrohungsszenarien sind jedoch subtiler. Beispielsweise kann ein Angreifer

eine Funktion dazu bringen, zulässige, aber trotzdem bezüglich Inhalt, Häufigkeit oder Zeitpunkt falsche Informationen an andere Komponenten weiterzuleiten und dabei eine Störung zu verursachen. Startpunkt für die Gewährleistung von Informationssicherheit im Produkt ist die Technik der Bedrohungsszenarien, Misuse Cases und Negativmodelle. Tabelle 2 zeigt das Vorgehen anhand einer Fenstersteuerung im Fahrzeug. Man beginnt mit einem funktionalen Modell des Produkts, also Zustände, gewünschte Funktionen und Gebrauchsszenarien. Parallel zu diesem funktionalen Modell erstellt man ein Negativmodell, das gezielt Missbrauchszenarien beschreibt. Zum Beispiel das Szenario „Fensteröffner wird bei abgeschalteter Zündung bedient“. Diese Missbrauchszenarien korreliert man dann mit weiteren funktionalen Szenarien, zum Beispiel „Fenster muss für versehentlich eingeschlossene Personen zu öffnen sein“. Aus diesen Bedrohungsszenarien erfolgt die Ableitung und Umsetzung konkreter Systemanforderungen. Dies ist zum Beispiel der Ausschluss aller nicht explizit erlaubten Szenarien, die zum Öffnen des Fensters führen können. Schließlich erfolgen Prüfungen auf Komponenten-, System- und Netzwerkebene, vor allem mittels Codeanalyse, SzenarioReviews und Angriffstests. Bezüglich der Informationssicherheit im Produkt sollten Ingenieure Informationssicherheit bereits in die Architektur ihrer Komponenten oder Netze einbauen (Design for Security). Beispiele sind ROM und Flashspeicher, bei denen eine Prüfung des Schlüssels zur Laufzeit erfolgt, sowie Algorithmen und Steuergeräte, die sich zur Laufzeit authentifizieren müssen. Außerdem sollten Netze physikalisch getrennt sein und Lockkeeper-Techniken bei der Übermittlung von Signalen oder Upgrades zum Einsatz kommen. Niederwertige oder offene Netze dürfen keinesfalls direkt Botschaften in sicherheitskritische Netze senden. Das Kommunikationssystem Sync etwa, das in den USA Verkaufszahlen von rund drei Mio. Stück erreicht hat, ist von der sicherheitsrelevanten Elektronik komplett abgekoppelt. In Gateways und bei externen Schnittstellen sollten Intrusion-Detection- und -Prevention-Systeme zum Einsatz komwww.automobil-elektronik.de

men, die gezielt den Datenstrom auf Unregelmäßigkeiten (Denial of Service, Überlast, Fehlersignale) prüfen und gegebenenfalls unterbrechen oder indirekt die Regeln der Firewalls im Gateway anpassen. Zu beachten ist, dass viele Protokolle und damit Netze keine verlässliche QoS liefern. Informationen von Systemen, die potentiell nicht verlässlich sind, dürfen für sicherheitskritische Funktionen nur als Zusatzkriterium dienen. Die Entscheidungsbefugnis ist maßgeblich durch verlässliche Sensoren zu erzeugen. Beispielsweise sind Informationen über Funkverbindungen wie Mobilfunk oder Car2x über Straßenzustand und Verkehrslage an einer stark befahrenen Straße, ein darauf basierender Kollisionsschutz ist jedoch damit nicht gewährleistet. Authentifizierung und Informationszugriff von einem externen Netz oder von Car2x-Kommunikation darf weder Voraussetzung für Schutz sein, noch dürfen relevante Informationen für sicherheitskritische Assistenzsysteme ausschließlich von außen kommen. Ferner ist die Ablage kritischer Parameter oder die Kommunikation auf Bussystemen in Klartext zu vermeiden. Derart abgelegt Parameter laden zur Manipulation ein. Authentizität und Integrität der Daten sollte man über MAC (Message Authentication Codes) sichern. Desweiteren sollten Ingenieure kritische Informationen verschlüsseln und Prüfsummen anwenden. Dabei spielt es keine Rolle, ob es um eine Datenübertragung auf den CAN-Bus oder die Ablage von Konfigurationsparametern geht. In jedem Fall sollten die eingesetzten Bussysteme gegenüber üblichen Fehlern wie zum Beispiel Überlast, Denial of Service, Adress- und Paketstörungen gehärtet sein. Alle äußeren Schnittstellen zu Standardbussystemen sollten gleichermaßen mechanisch, elektrisch und kryptografisch abgesichert sein. Zudem sind alle Schnittstellen (wie USB im Auto oder Diagnose im Motorraum) sowie Bussysteme mit möglichem externen Zugriff bei abgezogenem Zündschlüssel zu deaktivieren.

wesentliche Unterschied ist, dass man bei Informationssicherheit zudem mit dem schlimmsten anzunehmenden Fehlverhalten zur exakt falschen Zeit rechnen muss, da ein Angreifer bewusst und intelligent Fehlverhalten induzieren will. Qualitätsmanagement im Entwicklungsprozess muss alle prozessualen Anforderungen an Cybersecurity und deren durchgängige Umsetzung sicherstellen. Dies beginnt bereits in der Spezifikationsphase, wo Kriterien wie Sicherheitsanforderungen, Misuse Cases, Umgebungsanalyse, Security-Risikoanalyse, Common Criteria und Bedrohungsmodelle zu berücksichtigen sind, und setzt sich in der Implementierung und Integration fort. In dieser Phase geht es auch um sichere Architekturen, Komponentenauswahl und -verifikation, Design- und Coderichtlinien, Verwundbarkeitsanalyse, Codeanalyse und Sicherheitstests. Die Bestätigung erfolgt durch eine unabhängige Evaluierung auf Prozess- und Produktebene. Das schafft mehr Effizienz, da sich die Maßnahmen nicht unnötig überlappen oder gar Lücken haben. Zudem sollte in einem Schadensfall die systematische Umsetzung im Lebenszyklus nachgewiesen und analysiert werden können.

Security-Kultur Zur Implementierung einer wirkungsvollen Informationssicherheit gehört ein gesteigertes Bewusstsein für diese Thematik in der Entwicklung. Detaillierte Infos zur Umsetzung sowie über Security-Kultur, Maßnahmen zur Informationssicherheit im Entwicklungsprozess, Absicherung im Feld (bei Wartung und After-Sales) und Maßnahmen zur Cybersecurity im Feld erfahren Sie in der Langversion dieses Beitrags per infoDIREKT. (hb/av) ■

autoren Dr. Christof Ebert Vector Consulting Services GmbH, Stuttgart. Dr. Nico Adler Vector Informatik GmbH, Stuttgart.

Systematische Umsetzung Prozesse zur nachvollziehbaren Umsetzung von Security müssen, ähnlich wie die Safety-Prozesse, den gesamten ProduktLebenszyklus systematisch betrachten. Der www.automobil-elektronik.de

infoDIREKt

311ael0416 Automobil ElEktronik hue_image_Woerter_blau_56x257mm.indd 1

03-0423.02.2016 /2016 41 17:06:07 8/13

8/14

8/15

8/16

8/17

8/18

8/19

Safety & Security bewusste Fehler wie „Hintereingänge“ und „Master-Codes“. Unternehmen müssen die gesamte Lieferkette absichern und dabei auch immer wieder die Perspektive wechseln. Es braucht die Fähigkeit, wie ein Angreifer zu denken, um darauf aufbauend präventiv als Ingenieur oder Führungskraft zu handeln. Diese Absicherung muss immer funktionieren, vor allem auch bei kurzfristigen Änderungen kurz vor Liefertermin oder bei Regressionen in Varianten eines Produkts Jahre nach der ursprünglichen Freigabe.

(Bild: Vector Informatik)

Ganzheitlicher Ansatz

Praxis-Erfahrungen zur Anwendung von Cyber Security:

Risiko-orientierte Methodik Die zunehmende Komplexität von Systemen weit über das Fahrzeug hinaus und offene Schnittstellen erfordern konsequentes Risikomanagement, durchgängige Qualitätssicherung und einen systematischen Entwicklungsprozess. Daher hat Vector bewährte Verfahren zum Thema „Automotive Cyber Security“ zusammengefasst. Von Dr. Christof Ebert und Dr. Eduard Metzker

C

yber Security ist in allen Unternehmen als wesentliche Herausforderung angekommen.“ So fasst Dr. Thomas Beck, Geschäftsführer der Vector Informatik, seine Erfahrungen mit Unternehmen weltweit zusammen. Als die Vector-Gruppe in 2007 im Rahmen einer VDI-Veranstaltung in Baden-Baden erstmals auf die wachsende Relevanz gerade im Zusammenhang mit funktionaler Sicherheit mit einem Praxisbeitrag hinwies und eigene Lösungen vorstellte, waren viele Unternehmen der Meinung, dass Security

bereits ausreichend beherrscht wird. Diese Einstellung hat sich komplett gewandelt, wie auch das Vector-Symposium 2016 kürzlich zeigte.

Es gibt keine absolute Sicherheit Absolute Sicherheit wird es nicht geben, weil jedes komplexe System Fehler hat. Jedes Unternehmen muss für seine Produkte, Prozesse und Lieferkette ein risiko-orientiertes Cyber Security Management aufstellen, das über den gesamten Lebenszyklus und die ganze

aus Elektronik automotive Sonderausgabe Software 2016 8/20

Lieferkette verlässlich und nachvollziehbar funktioniert. Erfahrungen bei Vector zeigen, dass sich Security häufig auf organisch gewachsene Einzelmaßnahmen wie Verschlüsselung beschränken. Kryptolösungen, Key Management, Code-Analyse, Fuzz Testing und Firewalls sind zwar notwendig, aber sie bringen nicht viel, wenn Einfallstore bewusst oder unbewusst offen bleiben. Über 90  Prozent aller sicherheitsrelevanten Störungen gehen nach den Erfahrungen von Vector und Umfragen bei Kunden auf menschliche Fehler zurück. Abhilfe schaff t eine Risiko-orientierte Kultur, in der funktionsübergreifend Security spezifiziert, entwickelt und durchgängig verifiziert und validiert wird. Bild 1 zeigt diese Wertschöpfungskette und betont insbesondere auch die Gefahren von innen und außen. Es wäre naiv anzunehmen, dass Angriffe nur von außen erfolgen. Verwundbarkeiten entstehen durch nachlässige Entwicklungsprozesse, unsystematische Freigaben, aber auch gezielt durch

Cyber Security ist branchenübergreifend ein hohes Geschäftsrisiko geworden, weil es keinen absoluten Schutz gegen Hacker und Missbrauch gibt. Lorenz Slansky von Daimler unterstreicht, dass Cyber Security zunehmend wichtig für eine Marke ist und demzufolge einen Wettbewerbsvorteil darstellt. Bei kritischen Systemen wie im Fahrzeug besitzt die Informationssicherheit eine hohe Relevanz und darf nicht durch eine eingeschränkte Benutzbarkeit kompromittiert werden. Kernpunkte bei der Entwicklung von Schutzsystemen sind die richtige Identifizierung von Sicherheitsanforderungen, die systematische Realisierung von Sicherheitsfunktionen und eine Sicherheitsüberprüfung mit dem Ziel des durchgängigen Nachweises, dass alle relevanten Sicherheitsanforderungen erfüllt sind. Security-Richtlinien wie SAE J3061 helfen dabei, von anderen Branchen zu lernen und wesentliche Aspekte schnell umzusetzen. Lorenz Slansky weiß, dass proprietäre Lösungen häufig nur vermeintliche Sicherheit vorgaukeln, und stellt klar: „Security by Obscurity hindert Hacker nicht, aber verzögert gute Lösungen.“ Dr. Christian Meineck von Porsche ergänzt: „Security-Konzepte müssen das Fahrzeug und die IT-Netze im und außerhalb des Fahrzeugs betrachten.“ Bild 2 zeigt einen Ausschnitt von Angriffsszenarien, wie sie bei Herstellern evaluiert werden. Die Zeiten einzelner funktionaler Einheiten sind vorbei; das komplexe System Fahrzeug braucht Lösungen, wie sie heute in komplexen IT-Systemen bereits gelebt werden, beispielsweise ständige Software Upgrades – in kürzester Zeit und

Defense in Depth zu erzielen.“ Bild  3 zeigt am Beispiel Cooperative Adaptive Cruise Control (CACC), wie verschiedene Maßnahmen im Signalweg gegen Bedrohungen schützen. Katharina Lohmann von Hella sieht gerade bei Verifikation und Validierung großen Handl u n g s b e d a r f. Während Prozess- Rahmen Security by Design Security im Netz wie SPICE genutzt werden, um proaktiv FehEntwicklung Services ler im Engineering und in der interne externe Security-Überwachung Bedrohungen Bedrohungen Security in der Lieferkette Wartung zu vermeiden, muss die FehlerentdeProduktion Betrieb ckung flächendeckend geBild 1. Risiko-orientierte Security muss den gesamten Lebenszyklus bestärkt werden, (Bild: Vector Consulting Services) trachten. beispielsweise durch systematitereinander und durch zunehmend sche Scans der Software sowie durch offene Schnittstellen nach außen ist neue Testverfahren wie Fuzz Testing nicht nur die einzelne Funktion betrofund Penetrationstests. Dr. Günther fen, sondern auch weitere Systeme, die Heling von Vector unterstreicht aus eidem Systemverbund angehören und gener Erfahrung in der Entwicklung und mit dieser Einzelfunktion interagieren. Lieferung modernster Basis-Software, Das schließt auch nichtelektrische Merkdass hier nur eine automatische Liefermale mit ein. Beispielsweise könnte kette mit rigoros gelebten Freigabekridurch einen funktionalen Eingriff auf terien die nötige Qualität schafft. einem Bussystem eine Warnung bei mechanischem Verschleiß nicht mehr Kryptografie als Lösung funktionieren. Masahiro Goto und Martin Prisching von Denso zeigten hierKryptografische Methoden sind heute durch auf, dass Safety- und Securityein wesentlicher Bestandteil von SecuAspekte letztlich gemeinsam betrachtet rity-Lösungen. Klaus Schmeh von Crypwerden müssen. Dazu wird die Angriffstovision geht davon aus, dass beispielsbaumanalyse (ATA) um die Fehlerbaumweise das Verschlüsselungsverfahren analyse (FTA) ergänzt, um systematisch AES mit 1038 möglichen Schlüsseln in beide sicherheitskritische Bereiche absehbarer Zukunft auch mit Quantenabzudecken. Klar ist ebenfalls für sie: computern nicht zu knacken sein wird. „Alle Schichten der Security-Architektur Eine wichtige Herausforderung besteht darin, dieses und andere Verfahren auf sind zur durchgängigen Absicherung sinnvolle Weise in Fahrzeug-IT-Systeme nötig, um das bekannte Konzept der natürlich „Over the Air“ (OTA). Mit Standards kann man rasch von der IT lernen und verhindern, dass Fehler und Fehlentwicklungen in jeder Branche aufs Neue wiederholt werden. Durch den hohen Grad der Vernetzung von Funktionen im Fahrzeug un-

www (MNO)

SchlüsselManipulieren duplikate/ Lauschen MotorWiedergeben steuerung Autodiebstahl Injizieren unterbrechen Chip-Tuning Manipulieren Lauschen Wiedergeben Injizieren

Fälschung von Bauteilen Ablenkung des Fahrers

falsche Warnungen Sensoren

IP-Verlust Datenverlust FahrerassistenzKommunikation systeme fälschen manipulieren

Bild 2. Angriffsszenarien auf ein Fahrzeug.

Privatsphäre Airbag- verletzen Steuerung (Bild: Porsche)

aus Elektronik automotive Sonderausgabe Software 2016 8/21

Risiko-orientierte Methodik

Safety & Security

Cloud

Smartphone

LTE

V2XKommunukation

EVSE

Fahrzeug

TCU

Bluetooth Wi-Fi

Fahrzeug GW

Bluetooth Wi-Fi

ADAS

ADAS Antriebsstrang

ITS

Chassis

PLC

Standleitung

H/U

Multimedia

Body

Diagnose

Standleitung

CACC

V2V

Layer 1

Layer 2

V2V

Protokoll

GW

CACC

Key Server

GPS Radar

Geschwindigkeit

ECU

Positionsanzeiger ... AT

...

EPS

Bremse

...

A/C

Tür

...

Torque Motor

VLC SHE

Bremse

MAC Bremspedal

CRC

Bild 3. Alle Security-Schichten sind zur durchgängigen Absicherung nötig. zu integrieren. Dem entgegen steht die Anforderung nach hoher Performanz, wie Dr. Andre Weimerskirch von der University of Michigan betont. Er hat im weltweit größten Feldversuch Public Key Infrastructure (PKI) für Vehicle-toVehicle- (V2V) und Vehicle-to-Infrastructure- (V2I) Kommunikation umgesetzt, die Performanz und Datenschutz kombiniert. Seine Logik ist einfach: „Priorität eins ist funktionale Sicherheit und Pri-

Diagnoseschnittstelle

Antriebsstrang DC

Central Gateway

...

Layer 4

Beschleunigung

Geschwindigkeitssensoren

Bedrohung

...

ENG

Layer 3 Beschleunigungsanforderung MaxGuar

Datenzentrale

Safety &Safety Security & Security

(Bild: Denso Automotive)

orität zwei ist Datenschutz.“ Dietmar Hilke von Thales Deutschland entwickelt Lösungen für höchste Security-Anforderungen. Design for Security ist für ihn ein wichtiges Werkzeug; er holt Anleihen bei der Immunologie in der Medizin. Genauso, wie es multiresistente Keime gibt, werden auch die Angriffe immer wieder neue Muster entwickeln. Hier hilft nur eine systemische Resilienz, in der die Widerstandsfähigkeit konti-

Kombiinstrument

Head Unit

VerbindungsGateway

Chassis DC

DSRC

4G LTE

CU

Laptop Tablet

Body DC

Smartphone ADAS DC

intelligentes Laden

Firewall

Monitoring/Logging

sichere Onboard-Kommunikation

sicheres Flashen/Booten

Schlüsselinfrastruktur kryptografische Primitiven

Hypervisor

sichere Offboard-Kommunikation

ID/IP

Download Manager

sicherer synchroner Time-Manager

Bild 4. Security durch Design in der Praxis: Verschiedene Subnetze sollten weitestgehend separiert werden. (Bild: Vector Informatik)

nuierlich erweitert wird. Security beginnt im Design, ist aber eine Aufgabe für den gesamten Lebenszyklus – egal wie lang der ist. Die Unternehmen sind sich einig, dass durchgängige Risiko-orientierte Security nicht allein durch Patches auf Steuergeräte- und Netzwerkebene erreichbar ist. Security muss die gesamte Architektur adressieren. Bild 4 zeigt das Referenzmodell von Vector mit klarer Separierung der Subnetze. Zwischen den Subnetzen sind Firewalls sowie Intrusion-Detection-Systeme platziert. Derartige verteilte Security-Architekturen gelten in den aktuellen Projekten des Werkzeug-Herstellers als Königsweg, weil sie schrittweise umgesetzt werden können. Voraussetzung dafür ist eine geschichtete Security-Architektur, wie sie auch von Denso und anderen Tier-1-Lieferanten propagiert wird. Beginnend mit einem Hardware-basierten Anker und AUTOSAR mit den aktuellen Krypto-Lösungen, werden die einzelnen Komponenten individuell abgehärtet. Dr. Achim Fahrner von ZF betont in dieser Schichtung die Bedeutung eines Krypto-Koprozessors und Hardware Security Module (HSM), um Resilienz und Robustheit von unten her aufzubauen. Die Kommunikation zu sicherheitskritischen Subsystemen wie Lenkung und Bremsen sollte keinerlei direkte Verbindung zu Infotainment und anderen verwundbaren Systemen aufweisen. Das gilt insbesondere auch bei Over-the-Air Upgrades, die zunehmend zum Einsatz kommen. Axel Freiwald von Infineon unterstreicht, dass OTA zwar die Anzahl der Rückrufe drastisch reduziert, aber auch sorgfältig abgesichert werden muss, bevor es in vorhandenen Netzen zum Einsatz kommt. Nicht nur die IT-Anforderungen wachsen, beispielsweise Rollback und Verfügbarkeit, sondern vor allem auch die abgesicherte Verteilung der Software auf die Steuergeräte. Unternehmen müssen die Kompetenzen in den Bereichen Security sowie System- und IT-Architektur ausbauen, um die organisch gewachsene Architektur schrittweise zu modularisieren. Gleichzeitig sollten sie eine Strategie zur nachhaltigen Unterstützung verschiedener Organisationseinheiten umsetzen. Operativ kann das durch einen Security Manager gelenkt wer-

den, der die Freigabe von Architekturen und Komponenten-Releases verantwortet. Die üblichen Change Control Boards müssen dazu fachlich, aber auch prozessual gestärkt werden, um anhand definierter Kriterien die Bedrohungen zu evaluieren und verschiedene Lösungsansätze vor der Umsetzung zu vergleichen. Regelmäßige Architektur-Reviews sowie die Anpassung der Teststrategie mit Fokus auf Security vertiefen das Verständnis bei den Entwicklern und Führungskräften, dass Security-Maßnahmen kein Strohfeuer sind, sondern in jedem Projekt gelebt werden müssen. Derartige Konzepte lassen sich natürlich nicht einfach überstülpen und sie brauchen starke Ankerpunkte in der Organisation. In den von Vector betreuten Projekten zeigt sich, dass Security damit nachhaltig wird, denn die Teams haben eine greifbare, klare Verantwortung.

Security braucht durchgängige Systematik Fazit aus den Security-Projekten bei Vector: Der Grat zwischen systematischer Umsetzung von Automotive Cyber Security und wirkungslosen Einzelmaßnahmen ist schmal und benötigt professionelle Unterstützung. Security-Angriffe haben ein gemeinsames Muster, in dem nicht Stärke Schwäche ausnutzt, sondern Intelligenz Leichtsinnigkeit. Dabei geht es um Fehler in der Konfiguration von Firewalls und Gateways, nicht abgestimmten kurzfristigen Software-Änderungen sowie komplizierten Benutzerschnittstellen, sodass die Security-Maßnahmen im DefaultStatus und damit leicht angreifbar bleiben. Auf Basis von Bedrohungsanalysen, der Bereitstellung von Infrastrukturkomponenten und Werkzeugen für Verifikation und Monitoring bis hin zur Architekturbewertung und Security Consulting unterstützt Vector durchgängig. Nur eine durchgängige Systematik schafft Cyber Security: von der initialen Gefährdungsanalyse über Architekturentscheidungen und Verifikation bis zu Regressionstests bei jeder Neulieferung und Änderung. Nachhaltige Security, die über ein Strohfeuer hinausgehen soll, braucht Durchgängigkeit und die Zusammenarbeit mit Profis. eck

Dr. Christof Ebert studierte Elektrotechnik und Informatik an der Universität Stuttgart und promovierte dort. Er ist seit 2006 Geschäftsführer der Vector Consulting Services GmbH und Professor an der Universität Stuttgart. [email protected]

Dr. Eduard Metzker studierte Informatik an der Universität Ulm und promovierte am Daimler-Forschungszentrum in Ulm. Seit 2008 ist er als Produktmanager bei der Vector Informatik GmbH und seit 2015 als Manager der Cyber Security Solution bereichsübergreifend verantwortlich. [email protected]

aus Elektronik automotive Sonderausgabe Software 2016 8/22

8/23

26

Energie + Antriebe

emobility tec

Induktives Laden

04/2015

emobility tec

04/2015

Energie + Antriebe

Induktives Laden

27

Induktives Laden für E-Fahrzeuge ISO/IEC-15118-Standardisierung das induktive Laden gewinnt in Diskussionen und Berichten rund um die Elektromobilität zunehmend an Bedeutung. Diese Technologie bietet – neben dem vordergründigen Komfortgewinn – eine Reihe wesentlicher Vorteile, die langfristig gar nicht hoch genug einzuschätzen sind. Insbesondere lassen sich durch induktives Laden die Reichweiten der Elektrofahrzeuge bequem erweitern und die teuren Batterien kleiner auslegen. Dieser Beitrag vermittelt einen Überblick über aktuelle Fragen zur Technik und Normung des induktiven Ladens, wie sie unter anderem auf dem Vector E-Mobility Engineering Day Autor: Dirk Großmann 2015 in Stuttgart von Automobilherstellern und Zulieferern erörtert worden sind.

induktives Laden / wPt / iSo / ieC-15118 So wie Fahrzeuge mit Verbrennungsmotor regelmäßig zur Tankstelle fahren, beziehen Elektroautos ihre Energie quasi aus der Steckdose. Sei es, dass man den Wagen über Nacht in der heimischen Garage an das Stromnetz anschließt oder die Batterie unterwegs an öffentlich zugänglichen Ladesäulen nachlädt. Bislang führt kein standardisierter Weg an einer leitungsgebundenen Energieübertragung vorbei, die stets verbunden ist mit manuellen Aktionen zum Koppeln von Stecker und Ladebuchse.

trend -teChnoLogie Das wird sich ändern, denn die Elektromobilität bietet als Alternative und Ergänzung zum leitungsgebundenen Laden die Möglichkeit des induktiven Ladens. Hierbei wird unterschieden zwischen stationärem und dynamischem Laden. Das heißt, neben dem üblichen Laden im Stillstand ist auch ein dynamisches Laden während der Fahrt auf speziell präparierten Fahrbahnen technologisch realisierbar. Zahlreiche Unternehmen, Institutionen und Forschungsprojekte arbeiten bereits daran, die Technologie des induktiven Ladens zur Marktreife zu bringen und gleichzeitig eine globale Standardisierung zu erreichen. Das Laden ohne 9/0 2

Kabelverbindung verleiht dem Alltag von Verkehrsteilnehmern mit elektrisch angetriebenen Fahrzeugen einen spürbaren Komfortgewinn. Darüber hinaus bietet es etliche weitere Vorteile: Defekte an Steckverbindungen und Leitungen aufgrund von Alterung, Verschleiß, Korrosion oder Kabelbruch sind ausgeschlossen, was zu einem insgesamt geringeren Wartungsaufwand führt. Im öffentlichen Bereich sind mangels Angriffsflächen zudem deutlich weniger Schäden durch Vandalismus zu erwarten.

BenutzerSChnittSteLLe In herkömmlichen Ladesäulen (Bild 1) ist neben der Ladetechnik und dem Ladekabel in der Regel eine Benutzerschnittstelle untergebracht, die beispielsweise aus einem Anzeigemodul, Bedienelementen für Benutzereingaben sowie einem Kreditkartenlesegerät besteht. Beim induktiven Laden hingegen entfällt nicht nur das Ladekabel, sondern es ist auch die stationäre Benutzerschnittstelle in dieser Form nicht mehr notwendig, da hier eine prinzipiell andere Bedienphilosophie vorherrschen wird. Der Fahrer entscheidet vom Fahrzeug aus, ob er unterwegs Energie beziehen will und programmiert die fahrzeugseitige Elektronik entsprechend seiner Vorstellungen. Der Informationsaustausch zwischen Fahrzeug und induktiver Ladeinfrastruktur verläuft automatisiert. Bei der Fahrt in ein Parkhaus zum Beispiel führt ein Leitsystem zu einem freien Parkplatz mit stationärer Lademöglichkeit, während beim Fah-

ren das dynamische Laden automatisch startet, wenn man eine dafür vorgesehene Fahrbahn passiert.

PiLotProJek te Die Recherche im Internet zeigt, dass das induktive Laden keineswegs neu ist; vielmehr existieren seit Jahren Pilotprojekte sowie Einsatzbeispiele in einigen speziellen Anwendungsbereichen. Interessant sind fahrerlose Transportsysteme, die seit vielen Jahren das Bild in Fabrik- und Lagerhallen prägen sowie die öffentlichen Elektrobusse in Turin und Genua. In den beiden italienischen Städten verkehren schon seit dem Jahr 2002 rund 30 Elektrobusse, die in der Lage sind, bei Stopps an Haltestellen per Schnellladung Energie aus induktiven Ladevorrichtungen im Fahrbahnboden zu „tanken“ (Bild 2). Mit diesem Konzept bewältigen die Busse problemlos ihr Tagespensum, ohne zwischendurch explizit nachzuladen oder zu Batteriewechselstationen zu fahren. Da die Fahrzeuge nicht die Energie für den gesamten Tag mit sich führen, konnten die Entwickler die Batteriekapazität und damit deren Gewicht und Größe deutlich kleiner auslegen, was zu einer geringeren bewegten Masse führt und der Wirtschaftlichkeit zugutekommt. Vergleichbare Projekte mit induktiver Ladetechnik gibt es im öffentlichen Nahverkehr inzwischen weltweit in etlichen Städten – in Deutschland beispielsweise in Augsburg, Braunschweig, Mannheim und ab Sommer 2015 auch in Berlin.

In Analogie zum Laden an Haltestellen wäre für private Elektrofahrzeuge ein Nachladen beim Halten vor roten Ampeln denkbar, zumindest im städtischen Umfeld. Bevor ein solches Szenario möglich ist, sind sowohl in punkto Technologie als auch bei der Standardisierung noch etliche Herausforderungen zu meistern. Das induktive Laden basiert auf der Kopplung zweier Spulen, wie es vom klassischen Transformator her seit langem bekannt ist. Da ein hoher Wirkungsgrad zu den wesentlichen Erfolgsfaktoren zählt, kommt es bei der Umsetzung zum einen auf einen geringen Abstand von der Primärspule im Fahrbahnboden zur Sekundärspule im Fahrzeug an. Zum anderen ist für minimale Streuverluste eine exakte Positionierung des Fahrzeugs notwendig. Assistenzsysteme zur Feinpositionierung können hier künftig wertvolle Dienste leisten.

teChniSChe herauSforderungen Weitere technische Fragen betreffen die Auswahl geeigneter Frequenzbereiche sowie die möglichen Ladestromstärken und Spulenspannungen. Über diese und etliche weitere Parameter definieren sich die maximalen Ladeleistungen, Wirkungsgrade, zulässigen Erwärmungen und vieles mehr. Außerdem sind diverse physikalische Effekte, parasitäre Kapazitäten, Isolationsverluste und vieles mehr zu berücksichtigen. Trotz aller Herausforderungen erreichen die bekannten Projekte beim induktiven Laden Wirkungsgrade von rund 90 %. Während die 2002 ins-

Bild: Vector Informatik

K EY WORDS

9/1

28

Energie + Antriebe

emobility tec

Induktives Laden

1

04/2015

emobility tec

04/2015

2

Energie + Antriebe

Induktives Laden

29

3 Bild 1: Bislang übliches Laden via Ladesäule und Kabel. Bild 2: Induktives Schnellladen eines Elektrobusses in Turin. Markierungen erleichtern die genaue Positionierung über der Ladevorrichtung im Fahrbahnboden.

Bild: IPT Technology

Bild: Vector Informatik

Bild: Vector Informatik

Bild 3: VT7870 ist das Smart-ChargeCommunication-Modul von Vector für ISO/IEC-15118-konforme Tests der Ladekommunikation.

tallierten italienischen Pilotprojekte mit einer Ladeleistung von 60 kW arbeiten, beziehen die 2014 in Betrieb genommenen Elektrobusse in Braunschweig ihre Energie bereits mit einer Leistung von 200 kW; beide Systeme nutzen eine Frequenz von 20 kHz.

Ladekommunik ation via iSo/ieC 15118 Ohne sichere Kommunikation zwischen Fahrzeug und Ladeinfrastruktur ist jede Form des (öffentlichen) induktiven Ladens undenkbar. Nur damit lassen sich die zentralen Fragen beantworten, nämlich wer, wann und wo wieviel Energie zu welchen Konditionen bezogen hat. Auf dieser Basis entstehen dann auch die korrekten rechtsgültigen Abrechnungen. Auch Betrug und Missbrauch lässt sich damit ausschließen. Dasselbe trifft sinngemäß auch für das Laden über Kabel an Ladesäulen zu. Für das leitungsgebundene Laden (AC und DC) gibt es bereits die ISO/ IEC-Norm 15118, die seit Frühjahr 2015 vollständig verabschiedet ist. Zusätzlich existiert für das Gleichstrom-Laden die DIN SPEC 70121:2014. Gemeinsam sind sie Bestandteil des Combined Charging Systems (CCS – Kombiniertes Ladesystem), das in Europa Standard für AC/DC-Ladesysteme ist. Die ISO/IEC 15118 regelt alle Details der Ladekommunikation für das intelligente Laden oder auch Smart Charging. Dazu gehören neben Verbindungsaufbau und Authentifikation, das Aushandeln von Tarifen, das automatische Bezahlen, das Lade-Management oder auch das zukünftige Berücksichtigen von Smart-GridAnforderungen. Letzteres kann bei Energieknappheit bedeuten, dass das E-Fahrzeug auch temporär Energie zurück ins Netz speist. Als Physical Layer für die Datenkommunikation ist von der ISO/IEC 15118 „HomePlug Green PHY“ vorgesehen. Beim induktiven Laden kann naturgemäß nicht auf eine leitungsbasierte Kommunikationstechnik zurückgegriffen werden, sodass ein anderer Physical Layer (ISO/OSI-Schicht 1) erforderlich ist. Zusätzlich sind Anpassungen in der Anwendungsschicht (ISO/OSI-Schicht 7) notwendig. Diesen Aufgaben widmen sich 9/2

derzeit etliche Projektteams der ISO/IEC, die die Norm ISO/IEC 15118 für Wireless Power Transfer (WPT) weiterentwickeln. Bei den Erweiterungen der ISO/IEC 15118 für WPT handelt es sich im Einzelnen um die Normteile ISO/IEC 15118-6, -7 und -8. Während der Entwurf für Teil 6 der Norm allgemeine Informationen zum drahtlosen Kommunizieren bei WPT behandelt sowie Anwendungsfälle definiert, geht es in Teil 7 um Protokollanforderungen. Die ISO/IEC 15118-8 schließlich befasst sich mit dem Physical Layer sowie mit dem Data Link Layer. Neben der ISO/IEC arbeiten auch andere Standardisierungsorganisationen, insbesondere die SAE, an Kommunikationslösungen für WPT, sodass zu jedem Teil der ISO/IEC 15118 ein vergleichbarer SAE-Normteil existiert. China wiederum hat bisher keinen nationalen GB-Standard (GB: Guobiao) zum Themenkreis WPT angekündigt. Um eine weltweite Kompatibilität der Ladetechnik und Ladekommunikation zu schaffen, ist allerdings eine Harmonisierung aller nationalen und internationalen Standards notwendig. Mit SAE und ISO/IEC sind die für Nordamerika und Europa relevanten Organisationen dabei, einen gemeinsamen Standard für Wireless Power Transfer zu schaffen; zusätzlich gilt es, Asien und vor allem China mit ins Boot zu holen. Für ISO/IEC 15118-6 liegt der Draft International Standard (DIS) seit Frühjahr 2015 vor; DIS Teil 7 und DIS Teil 8 sollen bis Ende 2015/Anfang 2016 folgen. Ein vollständiger Final Draft International Standard (FDIS) ist für Anfang 2017 vorgesehen.

LöSungen und teStwerk zeuge für iSo/ieC-15118 Bis dahin müssen Automobilhersteller, Zulieferer und Unternehmen für die Ladeinfrastruktur jedoch nicht mit den Entwicklungen warten. Da das induktive Laden gemäß ISO/IEC 15118-6ff zu großen Teilen identisch ist zum leitungsgebundenen Laden, empfiehlt sich eine schrittweise Vorgehensweise. Von Vector Informatik etwa sind schon heute fertige und erprobte Embedded-Lösungen für ISO/IEC 15118 erhältlich, mit denen die Her-

steller Seriensteuergeräte zum intelligenten Laden über ein Ladekabel entwickeln können. Während das Produkt MICROSAR.V2G zum Entwickeln von Ladesteuergeräten im Fahrzeug dient, lässt sich mit dem Produkt vEVSE die entsprechend ISO/ IEC-15118-konforme Kommunikation für Ladesäulen verwirklichen. Die Lösungen unterstützen sämtliche Software-Anforderungen der ISO/IEC 15118, inklusive der Hardware-Anbindung (Homeplug Green PHY) und SLAC-Ablauf (Signal Level Attenuation Characterization).

SChrittweiSe umSteLLen Die Migration zum induktiven Laden geschieht in einem zweiten Schritt sobald der ISO-Standard alle notwendigen Spezifikationen für induktive Ladesysteme festgeschrieben hat. Da Vector in den ISO-Gremien vertreten ist und aktiv die Standardisierung begleitet, ist der Stuttgarter Spezialist in der Lage, zeitnahe Lösungen oder Erweiterungen für WPT anzubieten. Gleiches gilt für die Testwerkzeuge von Vector, mit denen sich Ladesysteme testen lassen. So bietet das Unternehmen für den HiL-Tester VT System eine spezielle Einschubkarte VT7900 mit Adapter VT7870 (Bild 3) an, die alle für die Smart Charging Communication (SCC) notwendigen Mechanismen unterstützt. Dazu zählen unter anderem die HomePlug GreenPhy-Kommunikation mit SLAC, PWM-Ansteuerung (IEC61851) und entsprechende Widerstände zur Simulation von Steckverbindungen. Das VT System kann sowohl zum Simulieren von Elektrofahrzeugen als auch zur Simulation von Ladesäulen dienen. Für den Durchbruch der Elektromobilität und das Erschließen des Massenmarkts ist die globale Standardisierung überaus wichtig, was für konduktives und induktives Laden gleichermaßen zutrifft. Ein einheitlicher globaler Markt erlaubt der Automobilindustrie und den Herstellern der Ladeinfrastruktur einen länderübergreifenden Vertrieb ihrer Produkte. Sie müssen nicht für jeden Teil der Welt kostentreibend Sonderlösungen imple-

mentieren. Gleichzeitig wächst die Bereitschaft für weitere Investitionen in die Elektromobilität und verleiht Sicherheit, dass sich die enormen Entwicklungskosten auszahlen. Lassen sich Elektrofahrzeuge länderübergreifend einsetzen und steht auch für das drahtlose Laden eine flächendeckende genormte Ladeinfrastruktur zur Verfügung, wird sich das positiv auf die Akzeptanz der Nutzer auswirken. Die leitungsgebundene und die induktive Ladetechnik werden sich vermutlich in der Praxis ergänzen. Wichtig ist zunächst eine nationale flächendeckende Grundversorgung für das leitungsgebundene Laden. Das induktive Laden bietet hingegen viel Potenzial für die Zukunft, erfordert aber andererseits erhebliche bauliche Maßnahmen. Nach Abschluss der internationalen Harmonisierung wird sich zeigen, wie hoch die Bereitschaft für Investitionen in induktive Ladeinfrastrukturprojekte ist.

dynamiSCh Laden Mit Lösungen zum dynamischen Laden können Elektrofahrzeuge während der Fahrt auf speziell dafür ausgelegten Straßenabschnitten drahtlos Energie beziehen. Dies ist langfristig nicht hoch genug einzuschätzen. Schließlich lassen sich so die derzeit noch begrenzten Reichweiten von Elektroautos signifikant erweitern, wenn zum Beispiel auf Autobahnen oder Überlandstraßen in regelmäßigen Abständen Ladestrecken integriert sind. Schon heute finden sich in Deutschland an vielen Stellen nahe an Autobahnen Windkraftanlagen, die Straßenabschnitte mit induktiver Lademöglichkeit bei überschaubarem Kostenaufwand speisen könnten. (av) ∕∕

Autor dirk großmann Gruppenleiter im Bereich Embedded Software bei Vector Informatik. 9/3

Test + Validierung

Ladesäulen testen

emobility tec

04/2014

Smart-Testing für Smart-Charging Durchgängige Testfallabdeckung Mit der wachsenden Vielfalt an Elektrofahrzeugen und Ladesäulensystemen spielen die Themen Interopera­ bilität zwischen den Komponenten und Normkonformität eine immer wichtigere Rolle. Um dies abzuprüfen und Ursachen für Ladeabbrüche aufzuzeigen, aber auch um Zuverlässigkeit und Robustheit bei diversen Stör­ einflüssen testen zu können, ist eine durchgängige Testfallabdeckung mit offener Testumgebung notwendig. Autoren: Dr. Kiriakos Athanasas, Dr. Heiner Hild

k ey worDS IEC 61851 / IEC/ISO 15118 / Smart-Charging / Test / EVSE / Ladestation Die Norm IEC 61851 definiert vier Modi für das konduktive Laden von Elektrofahrzeugen: Im Mode 1 erfolgt das Laden des Fahrzeugs einphasig bis 16 A ohne Pilotsignal, im Mode 2 ein- bis dreiphasig bis 32 A mit Pilotsignal. Im Mode 3 findet der Ladevorgang ebenfalls ein- bis dreiphasig statt, allerdings mit Ladeströmen bis 63 A mit einem Pilotsignal, das eine

Ladestation bereitstellt. Der Mode 4 schließlich beschreibt das DC-Laden mit beispielsweise 400 V / 125 A. Während der Ladevorgang gemäß Mode 1 ohne Kommunikation zwischen Fahrzeug und Ladeinfrastruktur auskommt, findet in den Modi 2, 3 und 4 in jedem Fall eine auf Pulsbreitenmodulation (PWM) basierende Low-Level-Kommunikation über die Control-Pilot-Verbindung (CP) statt. Falls Fahrzeug und Ladesäule eine High-Level-Kommunikation unterstützen, wird das entsprechende Signal, basierend auf dem Homeplug-Green-PHYStandard, auf das PWM-Signal des CP aufmoduliert. Diese sogenannte Powerline-Communication (PLC) ist nur in den Modi 3

emobility tec

04/2014

Bild: Vector Informatik

Ladesäulen testen

1

35

2

3

1 / Zusammenspiel von Ladesäule (EVSE) und Ladesteuergerät (OBC, Onboard Charger). 2 / Mögliche Komponententests. 3 / Mögliche Modi eines „Man-in-the-middle“-Betriebs für Interoperabilitätstests.

und 4 möglich und in der Norm IEC/ISO15118 beschrieben. Grundsätzlich geht jeder PLC-basierten Ladekommunikation eine PWM-basierte Kommunikation voraus. Daher muss ein vollständiges Testsystem beide Kommunikationsmodi beherrschen. Die Funktionalität der Ladesäule besteht aus der Fahrzeugperspektive gesehen im Wesentlichen aus den in Tabelle 1 beschriebenen Teilen. Tabelle 2 beschreibt die Funktionalität des Fahrzeugs aus Sicht der Ladesäule.

LadEkOMMunIk aTIOn TESTEn Um eine ordnungsgemäße Ladefunktion auf allen Ebenen nachzuweisen, bedarf es einer speziellen Mess- und Prüftechnik, die in der Lage ist, sowohl den Lastkreis wie auch die Kommunikationssignale wie Control Pilot und PLC-Signal zu analysieren und zu emulieren. Zusätzlich muss die Möglichkeit gegeben sein, die Botschaftsinhalte der PLC zu erzeugen, auszulesen und anzuzeigen und gegebenenfalls zu manipulieren. Komplettiert wird das Testsystem durch die Möglichkeit, Fehler auf die elektrischen Signale aufzuprägen. Dies umfasst sowohl Kurzschlüsse gegeneinander und gegen Batteriespannung beziehungsweise Masse als auch Variationen der an der CP-Kommunikation beteiligten Widerstände in Fahrzeug und in der Ladesäule. Nicht zuletzt muss bei einem vollständigen Testsystem auch der Lastkreis (AC oder DC) in Strom und Spannung gemessen, analysiert und definiert gestört werden können.

TESTMOdI und anfOrdErungEn

9/4

Test + Validierung

Bilder: Vector Informatik / Comemso

34

Sowohl für Komponententests wie auch für Robustheitsuntersuchungen muss ein Testsystem der jeweils zu testenden Komponente alle Schnittstellengrößen normgerecht und mit definiert aufgeprägten Fehlern bereitstellen. Bild 1 zeigt, was dies für die Ladekommunikationskanäle bedeutet: So muss geklärt werden, was passiert, wenn das Control-Pilot-Signal ein fehlerhaftes Verhalten auf dem PWM-Teil (zum Beispiel Fehler bei Pegel, Widerstandswerten, Tastverhältnissen, zeitlichen Abläufen) und auf dem PLC-Teil (beispielsweise Fehler bei Aufbau der Kommunikation, normgerechte Kommunikation und definiert gestörte Botschaften) aufweist. Zusätzlich ist zu prüfen, ob die zu testende Komponente einen

fehlerhaften Codierungswiderstand beim Proximity Pilot richtig erkennt oder ob dadurch eventuell eine Gefahrensituation entsteht. Für den Komponenten- beziehungsweise Robustheitstest eines EV-Ladesteuergeräts (EV-ECU) mit simulierter EVSE (EV Supply Equipment, Ladestation für EVs, Bild 2) muss das Testsystem zusätzlich folgendes bereitstellen: ⁄ Fahrzeug-Bordspannung mit Über-/Unterspannung, Rampenverläufen, unregelmäßige Störungen. ⁄ Fahrzeug-Kommunikation (zum Beispiel CAN) mit Botschafts- und elektrischen Fehlern. ⁄ Lastsignal AC oder DC mit Spannungsstörungen aller Art. ⁄ Netzemulator zur Nachbildung verschiedener weltweiter Netze (diverse Spannungen, Frequenzen, Netze mit Störungen und mehr). ⁄ Gegebenenfalls Abnahme der DC-Ladeleistung.

Tabelle 1: Funktionalität der Ladesäule, die das Fahrzeug direkt oder indirekt erfährt Funktionalität Ladesäule

Realisiert durch

Kommunikationssignal auf dem CP

Frequenzsignal, das auf Pulsweitenmodulation (PWM) basiert. Auf das PWM-Signal ist gegebenenfalls das PLC-Signal aufmoduliert.

Maximal mögliche Belastung der Ladeleitung

Sogenanntes Proximity-Signal (PP), das über einen vom Leitungsquerschnitt abhängigen Widerstand zwischen PP und PE im Stecker codiert ist.

Bereitgestellter Strom

Codierung über das Tastverhältnis (Duty Cycle) des PWM-Signals.

Fähigkeit zur HighLevel-Kommunikation

Tastverhältnis von 5 %. Das Tastverhältnis im Bereich 3...7 % ist ausschließlich für diesen Zweck reserviert.

Teilnehmer bei PLCKommunikation

Mitteilung komplexerer Informationen, zum Beispiel Ladeprofile, Abrechnungsmodelle, Authentifizierung und mehr.

Leistung

1- bis 3-phasiger AC-Kreis, je nach Land zwischen 100 V und 240 VAC. Alternativ dazu: DC-Spannung über separate Leitungen.

Quelle: Vector Informatik/comemso

9/5

36

Test + Validierung

emobility tec

Ladesäulen testen

04/2014

emobility tec

04/2014

Test + Validierung

Ladesäulen testen

37

Tabelle 2: Funktionalität des Fahrzeugs, welche für die Ladestation sichtbar ist

19”-Rackversion des LSA von Comemso.

Bild 5: Testsystem-Komponenten für SCC-Tests bezüglich IEC61851 und IEC/ISO15118.

Bilder: Vector Informatik / Comemso

Bild 4: Gesamtsystem zum automatisierten Test von Ladesteuergerät und Ladesäule in realer bis hin zu vollständig simulierter Umgebung.

Smart-Charging-Modul VT7870 des VT Systems von Vector.

Funktionalität Fahrzeug

Realisiert durch

Anzeige der Steckverbindung

Widerstand zwischen CP und PE, der den CP-Pegel von 12 V auf 9 V absenkt.

Anzeige der SteckerVerriegelung

Weiterer Widerstand zwischen CP und PE, der das PWM-Signal von 9 V auf 6 V absenkt.

Anzeige erforderliche Kühlung

Widerstand zwischen CP und PE, der das PWM-Signal von 6 V auf 3 V absenkt.

Teilnehmer bei PLC-Kommunikation

Mitteilung komplexerer Informationen, zum Beispiel Ladewunsch, Kontodaten, Authentifizierung und andere.

Leistungsabnahme

Vereinbarung eines Profils über Lowoder High-Level-Kommunikation.

Quelle: Vector Informatik / Comemso

Bild 6: TestsystemKombination für den mobilen Einsatz.

Für einen EVSE-Test simuliert das Testsystem ein Fahrzeug mit allen Grenzwerten (Bild 2). Hierzu ist auf der Infrastrukturseite zusätzlich die Anbindung an ein reales oder emuliertes EVU-Netz (Netzemulator) sowie gegebenenfalls die Simulation des webbasierten Bezahlsystems erforderlich (Bild 1).

InTErOpErabILITäTSTESTS Für Interoperabilitätstests wird das Testsystem zwischen Ladestation und Fahrzeug geschaltet (Bild 3), wobei dieser Betrieb auf zwei unterschiedliche Arten erfolgen kann: Im reinen Mithör-Modus lassen sich lediglich Messungen an den elektrischen Signalen von CP, PP und Lastkreis durchführen. Zur gezielten Analyse und Manipulation der PLC-Botschaften im HighLevel-Kommunikationsmodus ist im echten Gateway-Modus die Auftrennung der CP-Leitung erforderlich, da bei etablierter Fahrzeug-Ladesäule-Verbindung ein Austausch verschlüsselter Botschaften erfolgt. Neben der Messung und Beeinflussung der Kommunikations- und Lastkanäle muss ein Testsystem eine Ausführungs-, Aufzeichnungs- und Kontrolleinheit sowie idealerweise eine Authoring- und Verwaltungseinheit für Testfälle besitzen. Bereits heute existiert ein großer Bedarf nach systematischen Tests. Um dem Rechnung zu tragen, wird die Norm IEC/ ISO15118 für standardisierte Testfälle künftig die noch in Arbeit befindlichen Teile 4 und 5 bereit stellen.

gESaMTTESTSySTEM Zur Beherrschung der komplexen Anforderungen an ein Gesamttestsystem wählte Vector Informatik eine modulare Testsystem-Architektur, die einerseits alle geforderten Anfor9/6

derungen erfüllt, andererseits durch gezielte Reduktion auch die Realisierung von Teilaufgaben ermöglicht (Bild 4). Das zentrale Software-Element bildet das Tool CANoe von Vector Informatik mit der Option Ethernet. CANoe übernimmt dabei die Aufgaben Testausführung, Simulation der PLC-Kommunikation, Bereitstellung der Mess- und Analysedaten der Fahrzeug- und Ladekommunikation und aller elektrischen Kenngrößen sowie die Steuerung der beteiligten HardwareKomponenten. Damit ist es möglich, alle relevanten Messungen und Signale mit einheitlicher Zeitstempelung zu versehen, zu bearbeiten, auszuwerten und zu speichern. Die Erstellung und Verwaltung der Testfälle, seien es selbst erzeugte oder standardisierte, deckt hier Vteststudio von Vector Informatik ab. Durch die dargestellten Verschaltungsoptionen ist es möglich, aus dieser Architektur Teilsysteme für Teilaufgaben abzuleiten. Zur Abbildung der Umgebung von Ladesteuergerät und/oder Ladesäule kommt im vorgestellten System eine Kombination aus dem Ladesystem-Analysators / Simulators (LSA) von Comemso und dem VT-System von Vector Informatik zum Einsatz. Sowohl der LSA wie auch das VT-System sind in der Lage, das PLC-Signal der High-Level-Kommunikation vom CP-Signal abzukoppeln und CANoe über Ethernet zuzuführen. In CANoe stehen mithilfe des Smart-Charging-Communication-Addons (SCC) alle erforderlichen Analyse- und Manipulationsmöglichkeiten zur Verfügung.

gEMEInSaM STark Sowohl der LSA wie auch das VT7870-Modul des VT-Systems stellen die nach IEC61851-1 geforderten Beschaltungen für CP und PP einschließlich der Möglichkeit, Fehler aufzuprägen,

bereit (Bild 5). Das VT-System fungiert zusätzlich als Interface für die Fahrzeugkommunikation und ermöglicht die Simulation des Fahrzeug-Bordnetzes sowie gegebenenfalls die Steuerung einer elektronischen Last beziehungsweise einer externen Leistungsversorgung. Der LSA von Comemso ist darüber hinaus in der Lage, alle auftretenden Störungen der komplexen CP- und Last-Signale in Echtzeit zu erfassen und dazu zeitsynchron auch Störquellen zu detektieren. Da das CP-Signal gemeinsam mit dem aufmodulierten PLCSignal die Normvorgaben für das CP-Signal verletzen kann, sind speziell entwickelte analoge Filterschaltungen notwendig, um das hochfrequente PLC-Signal wechselwirkungsfrei vom Pilotsignal zu trennen. Der LSA verwendet zur Analyse des CP-Signals ein speziell entwickeltes Messverfahren, mit dem sich pro Periode bis zu 150 verschiedene Fehler und deren Permutationen daraus erfassen lassen. Auch den Lastkreis erfasst der LSA präzise als echten Effektivwert (True-RMS) auf allen drei Phasen sowohl im Strom als auch in der Spannung. Durch zusätzliche Netzanalyse für jede der drei Phasen und jede Sinusperiode zeigt das System unsymmetrische Netzauslastungen, aber auch Netzstörungen auf, die elektromagnetische Störungen auf dem Kommunikationssignal verursachen können. Während die High-Level-Ladekommunikation auf Ethernet-Basis erfolgt, leitet ein separater CAN-Kanal alle mit dem LSA gemessenen Größen an CANoe weiter. Erst durch die gemeinsame und zeitsynchrone Erfassung und Visualisierung von Lastkreis, CP-Signal und PLC-Signal können zusammenhängende Störungen sowie gegebenenfalls auch Ursache und Wirkung aufgezeigt werden.

Für den Feldeinsatz kommt der Ladesystem-Analysator / Simulator von Comemso als mobile Variante in Kombination mit den Vector-Produkten CANoe.Ethernet und vTESTstudio zum Einsatz (Bild 6). Dadurch ist die Testfalldurchgängigkeit vom Prototypenstadium bis hin zum Serienprodukt sowohl im Labor als auch im Feld gegeben.

MaXIMaLE TESTTIEfE Die in diesem Artikel vorgestellte Testsystemarchitektur ermöglicht es, die am konduktiven Laden nach IEC61851-1 und IEC/ ISO15118 beteiligten Komponenten systematisch auf Robustheit, Normkonformität sowie Interoperabilität zu testen. Die offene vTESTstudio- und CANoe-Testumgebung bietet die elementare Transparenz und Nachvollziehbarkeit der Testabläufe. Die modulare Architektur ermöglicht es in der Kombination aus Comemso- und Vector-Tools, zwischen Betrieb mit realer Umgebung bis hin zu voll simulierter Umgebung jede beliebige Zwischenstufe zu realisieren und in einem automatisierten Durchlauf zu betreiben. Dieser analytische Zugang auf allen Ebenen ermöglicht eine maximale Testtiefe: der Grundstein für robuste und harmonierende Komponenten und damit letztendlich für zufriedene Elektromobilitätskunden. (av) ∕∕

Autoren dr. kiriakos athanasas Geschäftsführer der Comemso GmbH. dr. Heiner Hild Gruppenleiter und Produktmanager im Bereich VT System bei Vector Informatik. 9/7

LADEKOMMUNIKATION

LADEKOMMUNIKATION

chend teurer zu bezahlen sein. Weil beim Laden von Elektrofahrzeugen vergleichsweise große Leistungen nötig sind, kann das bei einem hohen Gleichzeitigkeitsfaktor, zum Beispiel in einem Parkhaus, zu erheblichem Leistungsbedarf führen. Intelligente Ladeprozesse berücksichtigen das und gewähren den Stromlieferanten und dem intelligenten Stromnetz die benötigte Zeit, um sich auf die wechselnden Belastungssituationen einzustellen. Netzzusammenbrüche in Spitzenlastzeiten lassen sich so sicher ausschließen.

Gemeinsame Leitung für Energie und Daten

(Bild: Vector Informatik)

Smart Charging – ein Schlüssel zur erfolgreichen Elektromobilität Das Laden von Elektrofahrzeugen mit Wechselstrom regelt weltweit die seit Frühjahr 2014 vollständig verabschiedete ISO/IEC-Norm 15118. Für das Gleichstrom-Laden hat sich die Branche auf ein entsprechendes Subset geeinigt, das in der Vornorm DIN SPEC 70121 beschrieben ist. Dieser Beitrag beleuchtet einige Details beider Normen und zeigt Wege auf, wie Hersteller von Elektrofahrzeugen und Ladestationen zügig zur neuen Norm konforme Produkte entwickeln und diese effizient testen können. Von Dirk Großmann und Heiner Hild

W

ährend das Betanken eines Fahrzeugs mit Verbrennungsmotor wenig spektakulär und nach wenigen Minuten abgeschlossen ist, verläuft dieser Vorgang bei Elektrofahrzeugen deutlich anders: das Organisieren und Optimieren des Ladevorgangs der Batterie gehört zu den elementaren Aufgaben der Fahrzeug- und Ladesäulenhersteller. Im Kontext der

9/8

Energiewende und zukünftiger intelligenter Stromnetze (Smart Grid) ist der Ladevorgang wesentlich vielschichtiger, als es auf den ersten Blick erscheinen mag. Es gilt nicht nur, elementare Informationen wie die verfügbare Leistung der Ladesäule, den Batteriezustand und den Ladebedarf zu berücksichtigen. Auch komplexere Informationen, zum Beispiel die zum Ladezeitpunkt verfüg-

aus Elektronik automotive Sonderausgabe Elektromobilität 2014

baren Energieressourcen, sind zu beachten. Daneben sind Aspekte der Kostenoptimierung, der Bezahl-/Abrechnungsmodalitäten und Sicherheit sowie weitere Fragen von Bedeutung: Wie authentifiziert sich der Benutzer? Benötigt das Fahrzeug in kurzer Zeit möglichst viel elektrische Energie oder darf sich der Ladevorgang über etliche Stunden erstrecken, bis nach Dienstschluss oder zum Ende einer ausgedehnten Einkaufstour? Das intelligente Laden gemäß ISO/ IEC 15118 bietet die Chance, diese Problemstellungen im Sinne der Fahrzeughalter, Energieversorger, Ladesäulenhersteller und nicht zuletzt der Umwelt bestmöglich zu lösen. Die Zeiten ungeregelter Ladeprozesse, bei denen der Nutzer sein Fahrzeug einfach mit dem vorhandenen Stromnetz koppelt, um es sofort mit maximal möglicher Leistung aufzuladen, neigen sich dem Ende zu beziehungsweise werden entspre-

Eine der Grundvoraussetzungen für intelligentes Laden ist ein zuverlässiger Informationsaustausch zwischen Fahrzeug und Ladestation. ISO/IEC 15118 sieht hierfür HomePlug Green PHY als Physical Layer vor. Das ist ein von HomePlug AV abgeleitetes Powerline-Communication-Verfahren (PLC). Letztgenanntes ist im Heimbereich weit verbreitet und dient zum Vernetzen von Computern und Audio-Video-Komponenten (AV) über das Stromnetz. Darauf aufbauend kommen die aus der IT-Welt bekannten Internet-Protokolle wie TCP, UDP, IPv6, DNS, DHCP, TLS zur Anwendung. Nachfolgend wird genauer auf den initialen Verbindungsaufbau der PLC-Kommunikation eingegangen.

SLAC sorgt für sicheren Verbindungsaufbau Im Rahmen der ISO/IEC-15118-HighLevel-Kommunikation ist der initiale Verbindungsaufbau zwischen Fahrzeug und Ladesäule ein essenzielles Ereignis. Sobald ein Fahrer sein Fahrzeug mit einer Ladesäule verbindet, besteht das Ziel zunächst darin, einem gesicherten AV Logical Network (AVLN) beizutreten. Jedes AVLN wird durch eine Network ID (NID) repräsentiert. Des Weiteren benötigt jeder Teilnehmer eines AVLN zur verschlüsselten Kommunikation einen zur NID passenden Network Membership Key. Zu Beginn des Kommunikationsaufbaus sendet das Fahrzeug eine Ethernet-Broadcast-Botschaft an alle möglichen Netzteilnehmer. Alle Ladesäulen, die dieses Signal empfangen, reagieren darauf mit einer Ethernet-Unicast-Bestätigung. Weil an einer physikalischen

Versorgungsleitung mehrere Ladesäulen angeschlosOn-Board Charger ECU sen sein können, ist das ProRuntime Environment tokoll dafür zuständig, die betreffende Ladesäule zu EXI Smart Charge Customer JSON/EXI identifizieren, mit der das XML Security Communication functions DNS Fahrzeug verbunden ist. AufV2GTP HTTP grund unerwünschter EinTLS kopplungen können auch weitere Ladesäulen, die Eth SM TCP/IPv6 nicht physikalisch mit dem Ethernet-Schnittstelle Fahrzeug verbunden sind, Ethernet-Treiber angesprochen werden. Für Ethernet-Transceiver-Treiber einen korrekten und sicheren Ablauf des VerbindungsPowerline Communication aufbaus sorgt daher bei Charge Spot HomePlug Green PHY der sogenannte Signal-LevelLegend: Attenuation-CharacterizatiMICROSAR V2G DNS: Domain Name System modules for SCC Eth SM: Ethernet State Manager on-Mechanismus (SLAC). EXI: Efficient XML Interchange SLAC arbeitet nach der ReJSON: Java Script Object Notation SCC: Smart Charge Communication quest-Response-Methode, TLS: Transport Layer Security wobei die Anfrage stets vom V2GTP: Vehicle to Grid Transport Protocol Elektrofahrzeug ausgeht. Gleichzeitig einigen sich das Bild 1. Microsar V2G enthält die Software-Module für die VeFahrzeug und die Ladestati(Quelle: Vector Informatik) hicle-to-Grid-Kommunikation. on auf eine RunID, ein eindeutiges Identifikationsmerkmal, das Lösungen, wie Microsar V2G (Vehiclealle nachfolgenden Botschaften derselto-Grid) von Vector Informatik, zurückben SLAC-Session enthalten müssen. greifen. Microsar V2G (Bild  1) ist ein Der Verbindungsaufbau via SLAC Cluster von Basis-Software-Modulen durchläuft nacheinander verschiedene und Teil einer AUTOSAR-kompatiblen Produktreihe, die es erlaubt, ein exakt Stufen wie „Sounding Phase“, „Attenuation Characterization Phase“, „Validatiauf seine Anforderungen zugeschnitteon Phase“, „Matching Phase“ sowie die nes Steuergeräte-Software-Paket zusammenzustellen. Microsar V2G deckt „Amplitude Map Exchange Phase“. Andabei alle Technologien sowie Protohand verschieden starker Signaldämpfungen ist das Fahrzeug mit Hilfe des kolle auf den verschiedenen ISO-OSISLAC-Mechanismus somit in der Lage, Schichten ab, die für das Laden mit aus der Vielzahl antwortender LadesäuWechsel- und Gleichstrom gemäß ISO/ len diejenige zu identifizieren, mit der IEC 15118 und DIN 70121 erforderlich das Fahrzeug physikalisch verbunden sind. Dazu gehören passende Hardist. Am Ende dieses Prozesses bilden ware-Unterstützung für HomePlug Elektrofahrzeug und Ladesäule ein geGreen PHY ebenso wie die Implemenmeinsames AVLN, über das die höheren tierung eines zukunftsfähigen TCP/IP Protokollschichten ihre Informationen Dual Stack für IPv6 und IPv4. Das entverschlüsselt austauschen. sprechende Pendant zur Smart-Charge

Embedded-Systeme für die Ladesteuerung Für die Automobilindustrie auf der einen und die Hersteller der Ladeinfrastruktur auf der anderen Seite besteht eine wesentliche Herausforderung darin, ihre Produkte konform zur ISO/IEC 15118 zu gestalten. Am schnellsten kommen Automobilhersteller bei der Entwicklung des Ladesteuergeräts zu funktionstüchtigen Ergebnissen, wenn sie auf fertige und erprobte Embedded-

Funktionen des HardwareModuls VT7870 ➜ Simulation von Ladesäule oder Fahrzeug ➜ PWM Control Pilot (CP) Communication ➜ High-Level Powerline Communication (PLC) ➜ Fehlersimulation auf Control Pilot ➜ Simulation von Bauteiltoleranzen ➜ Anschluss und Messung des Proximity Contact

Elektronik automotive Sonderausgabe Elektromobilität 2014

35

9/9

LADEKOMMUNIKATION

Communication für Hersteller von Ladesäulen heißt vEVSE und enthält auf Basis von Embedded Linux sämtliche ISO/IEC-15118/DIN-70121-relevanten Komponenten (SLAC, EXI und Botschaftsablauf). Besondere Aufmerksamkeit erfordert das Testen der Smart- ChargeEntwicklungen. Ein Ladesteuergerät nach ISO/IEC 15118 und DIN 70121 muss sich nicht nur fehlerlos in die eigene Fahrzeugelektronik integrieren, sondern ist nach außen hin quasi offen, wo es mit einer wechselnden Ladeinfrastruktur verschiedener Stromanbieter und Hersteller konfrontiert wird. Patt-Situationen an Ladesäulen aufgrund nicht vollständig kompatibler Systeme wären in hohem Maße kontraproduktiv und würden zu herben Rückschlagen für die Akzeptanz der Elektromobilität führen. Um alle denkbaren Fehler und Inkompatibilitäten aufzuspüren, ist eine hohe Testabdeckung und hohe Testtiefe erforderlich. Das lässt sich nur über systematische und automatisierte Testläufe erreichen, beispielsweise mit leistungsfähigen Hardware-in-the-Loop-Systemen (HiL).

fähiges HiL-System ist in der Lage, für das zu prüfende System (SUT) die Umgebung vollständig und realitätsnah zu simulieren. Neben den PLC- und SCC(Smart Charging Communication) Verfahren sind digitale und analoge Größen von Sensoren und Aktoren nachzubilden, damit die Ladesäulen- oder Fahrzeugseite spezifikationsgemäß betrieben werden kann. Eine leistungsfähige Restbussimulation generiert zudem das Geschehen auf Fahrzeugbussen wie CAN, samt der dahinterstehenden Steuergerätelogik. Zum Testen von ISO/IEC-15118- und DIN-70121-Entwicklungen stellt Vector für seinen HiL-Tester VT System eine spezielle SCC-Einschubkarte zur Verfügung. Das VT7870 Board (Bild 2) bietet zwei Betriebsmodi und eignet sich sowohl zum Testen von Elektrofahrzeugen als auch zum Testen von Ladesäulen. Beim Test von Fahrzeugen simuliert das HiL-System damit die Ladesäule und beim Test von Ladesäulen die Fahrzeugelektronik. Auf dem Board befindet sich ein Devolo-dLAN-GreenPHY-Modul mit QCA7000-Chipsatz, mit dem sich das auf den Control Pilot Neue Testanforderungen meistern aufmodulierte Signal der Powerline Communication nicht nur empfangen, Allerdings sind beim Smart Charging sondern auch erzeugen lässt (Bild  2, einige neue Technologien im Einsatz, Textkasten 1). Das VT System ist modudie das Testsystem zu beherrschen hat. lar aufgebaut, flexibel skalierbar und Es muss sämtliche in der Norm ISO/IEC kann Fehlersituationen, Leitungsbrü15118 verwendeten Verfahren hinsichtche und Kurzschlüsse simulieren. Für lich Hard- und Software unterstützen Ladetests mit realen Stromstärken und und die in diesem Kontext notwendigen Spannungen sind auch steuerbare Testfälle abdecken. Das erstreckt sich Stromversorgungen und elektronische über alle ISO-OSI-Schichten von der Lasten anschließbar. Zur Konfiguration physikalischen Ebene des bei Powerline von Testskripten, zur Testablaufsteueund HomePlug Green PHY aufmodurung, Reporterstellung und Ergebnislierten PWM-Signals (Control Pilot) über analyse dient ein PC mit der Software Mechanismen wie SLAC bis zu InternetCANoe.Ethernet und dem SCC-Add-onund Ethernet-Techniken. Ein leistungsPaket. Falls erforderlich, übernimmt CANoe auch die Restbussimulation. Die automatisch ablaufenden Test-Design und Authoring Testfälle lassen sich mit mit vTESTstudio vTESTstudio definieren, Simulation der Ladesäule Testautomatisierung einem mächtigen TestPLC auf CANoe. VT System Design- und AutorenCP-Signal SUT Ethernet On-Board Charger Werkzeug (Bild 3). SCC over Steuerung Ethernet Der erwartete Anstieg sowohl an ElektLade- Optional: rofahrzeugen als auch leistung Bereitstellung realer Leistung mittels steuerbarer an LadesäulensysteLeistungsversorgung men bei gleichzeitig wachsender DurchdrinBild 3. Exemplarischer automatisierter Testaufbau für Onboardgungsrate der HighLevel-Kommunikation Charger-Steuergeräte mit simulierter Lade-säule. (Quelle: Vector Informatik)

9/10

aus Elektronik automotive Sonderausgabe Elektromobilität 2014

Bild 2. VT7870 ist das Smart-Charge-Communication-Modul für ISO/IEC-15118-konforme Tests (Quelle: Vector Informatik) der Ladekommunikation. führt zu einer stark anwachsenden kombinatorischen Komplexität. Daraus ergeben sich Herausforderungen an die Interoperabilität von Ladesäulen und Fahrzeugen sowie an die Konformität zu den geltenden Normen. Um diese sicher zu beherrschen, ist eine zuverlässige und ausgereifte Produkt- und Teststrategie sowie aufeinander abgestimmte und erprobte Komponenten und Werkzeuge notwendig. Das vorgestellte Portfolio der Vector Informatik GmbH stellt einen durchgängigen Ansatz dar, um die erfolgreiche Verbreitung der Elektromobilität zu gewährleisten. eck

Dirk Großmann ist Gruppenleiter im Bereich Embedded Software bei Vector Informatik. Dort ist er unter anderem verantwortlich für die Entwicklung von MICROSAR V2G und vEVSE. Nach dem Studium der Elektrotechnik an der Universität Stuttgart sowie sechs Jahren Automotive-Entwicklung im Bereich Steuergeräte-Software kam er 2003 zur Vector Informatik GmbH.

Dr. Heiner Hild ist Gruppenleiter und Produktmanager im Bereich VT System bei Vector Informatik. Dort ist er zuständig für die Entwicklung des VT System und weiterer I/O-Test-Hardware sowie deren Anbindung an CANoe. Nach dem Studium der Physik an der Universität Stuttgart und einer Promotion im Bereich Bildverarbeitung und Geoinformatik sowie über zehn Jahren Automotive-Entwicklung im Bereich Fahrerassistenzsysteme kam er 2014 zur Vector Informatik GmbH.

Messen/Testen/Tools Elektromobilität

Messen/Testen/Tools Elektromobilität

Steuergerätetest für E-Fahrzeuge Intelligentes Messen der dynamischen Stromaufnahme Die neuen elektrisch angetriebenen Fahrzeuge stellen Testsysteme vor besondere Herausforderungen: Insbesondere der effiziente Umgang der Steuergeräte mit elektrischer Energie muss in der Entwicklung und im Test beherrscht werden. Hierzu ist die Stromaufnahme der Steuergeräte abhängig von den Zuständen der Software zu messen, denn nur so ist die geforderte Energieeffizienz erreichbar. Autor: Dr. Stefan Krauß

I

n den Forschungs-, Vorentwicklungs- und Entwicklungsabteilungen der Automobilhersteller und -zulieferer wird unübersehbar an elektrisch angetriebenen Fahrzeugen und entsprechenden Mobilitätskonzepten gearbeitet. Manche Produkte haben das Experimentierstadium bereits verlassen, viele andere schicken sich an, diesen in Kürze zu folgen. Damit rückt auch der systematische Test der Fahrzeugelektronik in den Blickpunkt der verantwortlichen Testabteilungen. In den ersten Konzept- und Prototypenphasen wurde vielfach auf bestehende Komponenten von konventionellen Fahrzeugen zurückgegriffen, während der elektrische Antriebsstrang und innovative Funktionen im Fokus

standen. Mit der Serienentwicklung der ersten Elektro- und Hybridfahrzeuge gilt es nun, die wichtigen Erfahrungen der vergangenen Dekade bezüglich der Absicherung der E/E-Architektur auf die neuen E-Fahrzeuge zu übertragen. Was ändert sich aber für den Test der Fahrzeugelektronik bei elektrisch angetriebenen Fahrzeugen? Wie müssen die etablierten Teststrategien verändert, ergänzt oder gar ersetzt werden?

Neue Herausforderungen im E-Fahrzeug Die auffälligste Neuerung in der Bordelektronik sind die neuen Steuergeräte für die elektrischen Antriebskomponenten und die

Bild 1: Neu im E-Fahrzeug sind die Steuergeräte rund um den elektrischen Antriebsstrang sowie der obligatorische Einsatz von Stromspartechniken auf allen Ebenen.

Batterie (Bild 1). In einem vollelektrischen Fahrzeug ist das Motorsteuergerät durch eines für E-Motoren ersetzt. Das Getriebesteuergerät entfällt. Jedoch umsorgt ein Batterie-Management-System die Akku-Zellen und ein On-Board-Ladegerät ermöglicht das „Tanken“. Die Testabteilungen können die bestehenden Testmethoden auf diese Steuergeräte übertragen. Allerdings müssen dazu die passenden Umgebungssimulationen – insbesondere für die Batterien und Elektromotoren – in die Prüfstände integriert werden. Bei genauer Betrachtung entpuppt sich dies als eine große Herausforderung, da die im elektrischen Antriebsstrang verwendeten hohen Spannungen einen großen Einfluss auf die Prüfstandstechnik haben. Die Herausforderung besteht im Wesentlichen darin, unter diesen Bedingungen für die neuen Systeme die gleiche Prüftiefe und den gleichen Testautomatisierungsgrad wie für die bekannten Elektronikkomponenten zu erreichen. Mit dem elektrischen Laden zieht auch eine neue Kommunikationsschnittstelle ins Fahrzeug ein: die Kommunikation zwischen Ladesäule und Fahrzeug. Solange es nur darum geht, den eigentlichen Ladevorgang zu steuern und abzusichern, genügen einige einfache elektrische Signale. Für weiter gehende Funktionen wird jedoch eine komplexe Kommunikation benötigt. Solche Funktionen sind beispielsweise das automatische Abrechnen des Aufladens oder das Integrieren des Fahrzeugs in ein „Smart-Grid“ – also eine Kosten-Nutzen-optimierte Ladung des temporär an die Infrastruktur angeschlossenen Fahrzeugs. Rund um den Globus beschäftigen sich verschiedene Entwicklungsgruppen und Standardisierungsgremien mit diesen Themen.

AC-Laden gemäß ISO 15118

Alle Bilder: Vector Informatik GmbH

Eine zentrale Rolle nimmt sicher die ISO 15118 ein, die das intelligente Laden mit Wechselstrom beschreibt. Die Kommunikation erfolgt über die leistungsführende Leitung (Power Line Communication), nutzt das Internet-Protokoll IP und basiert auf typischen Internettechniken (TCP/UDP, DHCP, XML, JSON, um nur einige zu nennen). Diese Techniken sind zwar weit verbreitet – jeder PC beherrscht die meisten davon – eine Implementierung mit den beschränkten Ressourcen eines Automotive-Steuergeräts ist jedoch neu. Neuen Herausforderungen sehen sich auch die Tester gegenüber, die nun diese Protokolle analysieren und entsprechende Testumgebungen bauen müssen. Ein weiterer Aspekt: Während bisher die Kommunikation im Fahrzeug zwischen bekannten Steuergeräten abläuft, findet nun eine komplexe Kommunikation zwischen Fahrzeug und einer wechselnden Infrastruktur statt. Um einen reibungslosen Betrieb

9/12

60

Automobil ElEktronik 03/2011

www.automobil-elektronik.de

www.automobil-elektronik.de

im Feld zu gewährleisten, ist ein breit aufgestellter Test der Fahrzeugschnittstelle notwendig. Dasselbe gilt für die Ladesäulen. In Zukunft wird vielleicht ein vereinheitlichter Testumfang vereinbart werden können (Stichwort: Conformance Test). Es ist diesbezüglich sicher noch einiges im Fluss; trotzdem müssen für die bereits laufenden Fahrzeugprojekte ausreichende Tests entwickelt werden. Stromspartechnologien spielen bei der Entwicklung elektrisch betriebener Fahrzeuge eine zentrale Rolle. Im Spannungsfeld zwischen Reichweite, verfügbaren Batterietechnologien und Systemkosten ist elektrische Energie ein extrem knappes Gut. Jedoch werden auch in Fahrzeugen mit Verbrennungsmotoren energiesparende Systeme diskutiert – Treiber sind hier die Ziele und Verpflichtungen zur Reduktion der CO2-Emission. Jedes Fahrzeug soll deshalb auf der Ebene der Steuergeräte und Netzwerke so wenig Energie wie möglich verbrauchen.

Energiesparen im Steuergerätenetzwerk In der Entwicklung von Steuergeräten und Netzwerken werden aktuell verschiedene Ideen verfolgt. Nicht alle Ansätze sind neu, sie werden inzwischen aber mit viel Nachdruck angegangen und finden Eingang in die Standardisierung (insbesondere Autosar). ■ Im Teilnetzbetreib (Partial Networking) werden logische Netzwerke gebildet, die nicht mit den physikalischen übereinstimmen müssen. Die energiesparenden Schlafzustände werden auf den logischen Teilnetzen definiert. Sie sind so effektiver einsetzbar, weil in vielen Betriebszuständen weniger Steuergeräte den Schlafzustand verlassen müssen. ■ Beim Pretended Networking sind einzelne Steuergeräte so konstruiert, dass sie dem Kommunikationsnetz gegenüber aktiv erscheinen, selbst aber weitest gehend in einen Schlafmodus gehen können. Dies kommt immer dann zur Anwendung, wenn die eigentliche Steuergerätefunktionalität nicht erforderlich ist. Erweiterungen in der Steuergeräte-Hardware sorgen dafür, dass zyklische Botschaften weiterhin versandt werden und der Steuergerätekern unter bestimmten Bedingungen wieder geweckt wird. ■ Unter dem Stichwort ECU Degradation sind alle Maßnahmen zusammengefasst, bei denen nicht benötigte Teile des Steuergeräts abgeschaltet werden. Dies reicht von einfachem Abschalten elektrischer Treiberstufen bis zum feingranularen Steuern chip-interner Logikeinheiten. ■ Das Zusammenfassen von verschiedenen Funktionen in wenigen Steuergeräten senkt nicht nur den gesamten Energiebedarf, sondern bietet auch ein Einsparpotential bei den HardwareKosten. Die Autosar-Methodik unterstützt diesen Ansatz bereits Automobil ElEktronik 03/2011

61

9/13

Messen/Testen/Tools Elektromobilität

CANoe Sicherheitsrelevante LifecycleValidierung von Batteriesystemen Bild 2: Das Stromversorgungsmodul des VT System ermittelt den Strombedarf des Prüflings mit hoher Messgenauigkeit und Zeitauflösung.

Case Study ZSW Labor für Batterietechnologie (eLaB)

Bild 3: In CANoe sind Stromaufnahme und Steuergerätezustand übersichtlich dargestellt und analysierbar.

Stromaufnahme differenziert prüfen Im Test spielt die Stromaufnahme der Steuergeräte eine wichtige Rolle. Bisher wurde die Stromaufnahme als durchschnittliche Gesamtgröße erfasst oder war von relativ statischen Betriebsmodi – Stichwort Schlafmodus – abhängig. In verbrauchsoptimierten Systemen muss sie jedoch dynamisch in Beziehung zu den Softwarezuständen der Steuergeräte bestimmt werden. Da sich das Einsparpotential aus einer Vielzahl von Einzeloptimierungen ergibt, muss der Tester sehr genau prüfen, ob die Stromaufnahme in den einzelnen Steuergerätezuständen den Erwartungen entspricht. Dasselbe gilt in der Entwicklung: Der Entwickler muss die Leistungsaufnahme bezogen auf den aktuellen Zustand der Software beurteilen können. Leistungsfähige Testsysteme wie beispielsweise das VT System (Bild 2) von Vector ermöglichen deshalb das präzise Erfassen der Stromaufnahme der zu testenden Steuergeräte und erlauben das Zuordnen zu den Systemzuständen. Die modulare Test-Hardware VT System simuliert die Sensoren und Lasten, stimuliert die Eingänge und misst die Ausgangssignale, erzeugt elektrische Fehler wie Kurzschlüsse und Leitungsbrüche und ermöglicht das Umschalten zwischen den intern simulierten und extern angeschlossenen Sensoren und Lasten. Außerdem steuert das VT System die Versorgungsspannung und ermittelt den aufgenommenen Strom (Bild 2). Eine schnelle automatische Bereichsumschaltung sorgt dafür, dass sowohl sehr hohe Ströme im Lastbetrieb als auch minimale Ströme in Stromspar- und Schlafmodi mit hoher Auflösung gemessen werden. Das Automatisieren dieser Tests übernimmt beim VT System CANoe. Diese Software ermöglicht gleichzeitig das Simulieren der restlichen Netzwerkteilnehmer (Restbussimulation) und bedient die Software-Zugänge zum Steuergerät. Außerdem enthält sie um-

fassende Analysefunktionalitäten, so dass Entwickler das System beispielsweise zum Testen wie zur Fehlersuche verwenden können. CANoe wurde insbesondere für die Analyse, Simulation und den Test von Steuergeräten und -netzwerken entwickelt und ist daher in der Lage, eine Gegenstelle für die verschiedenen LadesäulenSchnittstellen zu schaffen. Beim Test eines Ladesteuergeräts wird also die Ladesäule simuliert – und umgekehrt. Für den Test und die Analyse müssen die Systemzustände der Steuergeräte und Netzwerke aus verschiedenen Signalen ermittelt werden. Das können Bussignale sein, aber auch Hardware-Signale oder Informationen, die über die Diagnose- oder Kalibrierschnittstellen aus dem Steuergerät ausgelesen werden. So könnte zum Beispiel ein via XCP gelesener Wert über den internen Zustand des Steuergeräts Auskunft geben. Wichtig ist, dass alle Werte wie in CANoe direkt und mit gleicher Zeitbasis zur Verfügung stehen. Mit entsprechender Werkzeugunterstützung ist damit eine Beurteilung des Steuergeräteverhaltens leicht möglich (Bild 3). Dies ist insbesondere in den Entwicklungsphasen und während der Fehlersuche notwendig. Auf derselben Basis lassen sich auch leicht Testprogramme formulieren und die Tests automatisieren. Die Testabteilungen erreichen damit auch im E-Fahrzeug den hohen Automatisierungsgrad, der sich in den letzten Jahren als wichtiger Bestandteil der Absicherungsstrategie bewährt hat. (av) ■

Der Kunde

Die Vorteile

Das ZSW Labor für Batterietechnologie (eLaB) in Ulm ist ein

Langzeitlogging, Datenverwaltung und durch die Visuali-

unabhängiges Entwicklungs- und Testzentrum für Batte-

sierung jederzeit alles „auf einen Blick“ > Langzeittests von Batterie und BMS sind sehr realitäts-

rien. Es ist international anerkannt für das Prüfen von Zellen, Modulen und Batteriekomplettsystemen inklusive des Batteriemanagements. Die Forscher verfügen über 25 Jahre Erfahrung mit Batterien und Superkondensatoren. Die Kunden kommen aus der Industrie und Forschung weltweit.

nah > Non-Stop-Betrieb des Prüfstands von über einem halben Jahr sorgt für reibungslosen Testablauf > Transparenz durch eindeutige Zuordnung der Logfiles zu Fahrzyklen und Leistungsprofilen – sowohl während

Die Herausforderung Sicherheitsrelevante Lifecycle-Validierung von automotive

des Betriebs als auch offline > Vielfältige Loggingstrategien durch wahlfrei definierbare

Monatelange Dauertests bilden eine Grundlage für ein ver-

Triggerbedingungen > Die wichtigsten Batterieparameter sind kontinuierlich

lässliches Funktionieren des Batterie-Management-Sys-

durch grafische Visualisierung auf einen Blick sofort

tems (BMS) und für eine lange KFZ-Batterielebensdauer.

erkennbar

Batteriesystemen bei steigender Variantenvielfalt

Die Tests beinhalten reale und synthetische Leistungsprofile, wie Notabschaltung und Ladezyklen. Ein möglichst

> Zielführende Offline-Analysemöglichkeiten durch vielfältige und komfortable Suchfunktionen

vollautomatisierter Ablauf der Tests, das Handling der großen Variantenvielfalt von Tests und Datenmenge sind die Herausforderungen. Allein an CAN-Kommunikationsdaten

PC 1

PC 2

fallen Terabytes an.

Testprog.

Logdatei

Die Lösung Kombination von aktivem Leistungssteller und CANoe zu

SUT

einem leistungsfähigen Langzeit-Batterieprüfstand Alle Leistungs- und Kommunikationsschnittstellen des Sys-

Der Autor: Dr. Stefan Krauß ist Gruppenleiter bei der Vector Informatik GmbH in Stuttgart und als Produktmanager für das VT System verantwortlich.

tem Under Test (SUT), bestehend aus Batterie-Management-System (BMS) und Batterie sind im Batterieprüfwirkt wahlweise als Gleichstromquelle oder -senke. Die Ablaufsteuerung in PC1 fährt Leistungsprofile vollautomatisiert ab. CAN- und LIN-Netzwerke werden über eine Rest-

Leistungsfähige Testsysteme wie beispielsweise das VT System ermöglichen das präzise Erfassen der Stromaufnahme der zu testenden Steuergeräte und erlauben das Zuordnen zu den Systemzuständen. Die modulare Test-Hardware VT System simuliert die Sensoren und Lasten, stimuliert die Eingänge und misst die Ausgangssignale, erzeugt elektrische Fehler wie Kurzschlüsse und Leitungsbrüche und ermöglicht das Umschalten zwischen den intern simulierten und extern angeschlossenen Sensoren und Lasten.

Batterie BMS ECU

stand nachgebildet (s. Bild). Ein aktiver Leistungssteller

Auf einen Blick VT System

infoDIREKT www.all-electronics.de

Leistungssteller

CANoe ...

CAN

bussimulation des Testwerkzeugs CANoe auf dem separaten PC2 modelliert. Beide Systeme kommunizieren direkt über den ohnehin vorhandenen Fahrzeugbus. Die Visualisierung des Testfortschritts erfolgt über CANoe Panels zum kontinuierlichen Monitoring. Die Messergebnisse werden von CANoe CAN-gesteuert in binärische Logfiles von handhabbarer Größe portioniert und verwaltet. Sie lassen sich

V2.0 | 2014-10

durch die ausgeprägte Funktionssicht. Auch sind leistungsfähige Mehrkernprozessoren energieeffizienter als entsprechende Einzelprozessoren in eigenen Steuergeräten. ■ Die Entwicklung könnte sogar noch einen Schritt weitergehen und mehrere logische Steuergeräte über eine Virtualisierungsschicht in einem physikalischen Steuergerät zusammenfassen. Dem Einsparpotential steht jedoch die Gefahr unerkannter gegenseitiger Abhängigkeiten entgegen. Die ausgefeilten Techniken zur Energieeinsparung erhöhen allerdings die Komplexität der Steuergeräte und Netzwerke. Systematische, bereits in den Entwicklungsphasen durchgeführte Tests sind daher wichtiger denn je.

jederzeit dem zugehörigen Dauertest zuordnen.

312AEL0311

Erschienen in Automobil Elektronik, 8/2011 9/14

62

Automobil ElEktronik 03/2011

www.automobil-elektronik.de

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

9/15

24

l

AUTOMOTIVE

3-4. 2 0 11

l

ENGINEERING TOOLS

ENGINEERING TOOLS

SCHNITTSTELLENLÖSUNG MIT INTEGRIERTEM ECHTZEITKERN

Neue Bus-Schnittstellen für die Elektro-/HybridFahrzeugentwicklung E i n e i d e a l e H a rd wa re - S c h n i t t s t e l l e f ü r d i e E V- / H E V- E n t w i ck l u n g z e i c h n e t s i c h d u rc h h o h e E c h t z e i t f ä h i g ke i t , e i n e e i n fa c h e H a n d h a b u n g , E r we i t e r b a rke i t u n d m ö g l i c h s t f l ex i b l e E i n s at z m ö g l i c h ke i t e n a u s . D i e s e t e i l we i s e ko n t r ä re n A n fo rd e r u n g e n l i e ß e n s i c h m i t b i s h e r i g e n Ko n z e p t e n n i c h t e r f ü l l e n . Ve c t o r h at n u n s e i n e S c h n i t t s t e l l e n - Fa m i l i e u m e i n m o d u l a re s I n t e r fa c e m i t i n t e g r i e r t e m E c h t z e i t re c h n e r e r we i t e r t . D i e s e E c h t z e i t f ä h i g ke i t s o rg t f ü r k u r z e d e t e r m i n i s t i s c h e Z y k l u s - u n d A n t wo r t z e i t e n u n d e r m ö g l i c h t d e n f l ex i b l e n E i n s at z i m B e re i c h E V- / H E V- E n t w i ck l u n g .

D

ie Vielzahl verschiedener Bussysteme bringt herkömmliche Hardware-Schnittstellen bei der Entwicklung von Elektro-/Hybrid-Fahrzeugen (EV/HEV) an ihre Leistungsgrenzen. Die Testtiefe, Analysequalität und Simulationsmöglichkeiten sind dabei entscheidend vom Echtzeitgrad des Datenaustauschs geprägt. Vorrangig ist hierbei die Kommunikation zwischen Fahrzeugnetzwerken und den Test- und Simulationswerkzeugen. Bei der Entwicklung der neusten Schnittstellengeneration hat Vector deshalb den Weg in Richtung einer aktiven Hardware-Architektur mit integrierter CPU eingeschlagen. Durch diesen Lösungsansatz werden bewährte Anwendungsfälle abgedeckt, wie beispielsweise Busanalyse, Restbussimulationen, lesitungsfähiges Messen und Verstellen über CCP und XCP, Ausführen von Gateway-Routings, schnelles Flashen sowie komplexe Diagnose-Serviceausführungen. Durch die Vielfalt der Schnittstellen und den leistungsfähigen Rechenkern des mit VN8900 bezeichneten Systems, können Restbussimulation und Gateway-

9/16

Bild 1: Gegenüberstellung: Einsatzbereich von herkömmlicher Schnittstellen-Hardware und dem erweiterten Einsatzbereich von VN8900-Systemen. © automotive

l

AUTOMOTIVE

3-4. 2 0 11

l 25

optimale Integration in eine entsprechende Umgebung auch automatisierbar.

Bild 2: Datenflussdiagramm der Bypass-Lösung.

© automotive

Anwendungen in Echtzeit ausgeführt werden. Darüber hinaus ergeben sich in der Steuergeräteentwicklung neue Einsatzmöglichkeiten, die insbesondere den hohen Anforderungen bei der Elektro-/Hybrid-Fahrzeug-Entwicklung gerecht werden. Hervorzuheben ist die Unterstützung von Rapid-Prototyping- Anforderungen (Prototypensteuergeräte und Bypassing), die weiter vorne im Entwicklungsprozess (links im V-Diagramm) angesiedelt sind. Dies wird im Weiteren noch näher ausgeführt. Während des Steuergeräteentwicklungsprozesses wird dabei ein deutlich größerer Zeitraum abgedeckt, als beim Einsatz herkömmlicher Schnittstellen-Hardware (Bild 1). Echtzeitausführung von Restbussimulationen und Gateway-Anwendungen Eine große Herausforderung stellt die Anforderung von Echtzeitfähigkeit mit sehr schnellen Reaktionszeiten, einfacher Plug & Play-Anbindung über USB, sowie die vollständige Wiederverwendung der Vector-Tools wie CANalyzer/CANoe und CANape dar. Dies wird durch die Arbeitsteilung zwischen dem Bedien-PC und der intelligenten Schnittstellen-Hardware erreicht. Nur relevante Tasks werden direkt auf der echtzeitfähigen HardwareSchnittstelle ausgeführt, während andere Standardaufgaben wie Datenaufbereitung, Speicherung und Visualisierung wie gewohnt auf dem Bedien-PC ablaufen. Benötigt man keine Benutzerinteraktionen, lassen sich Restbussimulationen und Gateway-Anwendungen autark auf der Schnittstellen-Hardware ausführen. Wenn noch nicht alle Steuergeräte für das gesamte Elektro- oder Hybridfahrzeug verfügbar sind, ist eine Restbussimulation zwingend notwendig, um einzelne Steuergeräte entwickeln und testen zu können. Die Restbussimulationen oder das Gateway-Routing erstellt der Anwender mit CANoe auf Basis der passenden OEM-Erweiterung mit wenigen Mausklicks und lädt sie auf die Schnittstellen-Hardware. Um Standalone-Applikationen in andere Systeme zu integrieren, steht die auf Ethernet/UDP basierende Schnittstelle mit der Bezeichnung FDX (Fast Data Exchange) zur Verfügung. Sie ermöglicht schnelle Schreib- und Lesezugriffe auf Bussignale und Systemvariablen. Über einen Manager werden vorbereitete CANoe/CANalyzer StandAlone-Konfigurationen von einem beliebigen PC aus in das Schnittstellenmodul geladen. Dieser Vorgang ist für eine

EV/HEV-Rapid-Prototyping: Durchgängige Bypassing-Lösung Die Bypassing-Lösung von Vector erlaubt es, Teile der Steuergeräte-Software außerhalb des Steuergerätes mit deterministischen Antwortzeiten auf dem VN8900 auszuführen. Dies ist insbesondere für die EV/HEV-Entwicklung sinnvoll, wenn: ■ Funktionen schnell geändert werden müssen, ohne dass der komplette Steuergeräte-Codegenerierungs- und Flash-Prozess durchlaufen werden muss, ■ Funktionen für Vergleichsmessungen einfach umgeschaltet werden sollen, ■ neue Funktionen nicht mit der existierenden Steuergeräte-Hardware ausgeführt werden können, zum Beispiel, wenn nicht ausreichend Speicher oder CPUPerformance zur Verfügung steht. Im Steuergerät muss dazu die zu bypassende Funktion „freigeschnitten“, dass heißt, nicht mehr ausgeführt werden. Die Ein- und Ausgangsparameter der Bypass-Funktion liegen typischerweise im RAM des Steuergerätes und müssen möglichst schnell zum Bypass-Rechner übertragen werden. Für die Übertragung bieten sich die standardisier-

Bild 3: Messen und Verstellen von VN8900-Prototypensteuergeräten.

© automotive

ten Protokolle CCP, XCPonCAN, XCPonFlexRay und XCPonEthernet an (Bild 2). Das Mess- und Kalibriersystem VX1000 von Vector ermöglicht einen besonders schnellen Zugang zum Steuergeräte RAM. Dazu wird ein POD (PlugOnDevice) über Daten-Trace oder Debug-Interfaces, wie beispielsweise Nexus, JTAG oder DAP, an das Steuergerät angebunden, im VX1000-Basismodul auf das XCPonEthernet-Protokoll umgesetzt und zum VN8900 übertragen. Messungen zeigen hier eine bis zu hundertmal höhere Messdatenrate wie es beispielsweise mit CAN möglich ist. Für das Messen der bis zu 50 kHz schnellen Ansteuersignale der Elektromotoren ist das VX1000-System bei 9/17

26

l

AUTOMOTIVE

3-4. 2 0 11

l

ENGINEERING TOOLS

Bild 4: Unter Verwendung des CANape Simulink Modell Explorers kann das Modell visualisiert und interne Modellparameter angezeigt und verstellt werden.

Elektro-/Hybrid-Fahrzeugprojekten schon häufig im Einsatz, welches dann einfach durch die VN8900-Hardware zu einer Bypass-Komplettlösung erweitert werden kann. Eine optional steckbare I/O-Platine im VN8900 erlaubt der Bypass-Laufzeitumgebung den Zugriff auf digitale und analoge Signale. VN8900 als PrototypenhardwareSchnittstelle bei Batteriesteuergeräten Dieser Anwendungsfall ist insbesondere dann interessant, wenn noch keine Steuergeräte-Ziel-Hardware verfügbar ist. Das ist aktuell bei EV-/HEV-Batteriesteuergeräten häufig der Fall, weil nicht auf bestehende Vorgängersteuergeräte zurückgegriffen werden kann und die Steuergeräte in den meisten Fällen komplett neu für Elektro-/Hybrid-Fahrzeuge entwickelt werden müssen. In der CANoe-Stand-Alone-Laufzeitumgebung wird für diesen Anwendungsfall die Steuergerätesoftware in Form von Simulink oder „C“-Executables auf dem VN8900 unter Echtzeitbedingungen ausgeführt. Die Kommunikation mit weiteren Busteilnehmern erfolgt dabei über CAN-, LINoder FlexRay-Busschnittstellen. Zusätzlich ist die Anbindung beispielsweise von Sensorik über die digitale und analoge I/O-Schnittstelle möglich. Im Vergleich zu bestehenden Lösungen für Steuergeräteprototypen wird beim VN8900-Ansatz kein Cross-Compiler eingesetzt. Somit sind alle bekannten und bewährten Funktionen von CANoe, wie beispielsweise Network-Management, Interaction-Layer, Transportprotokolle (zum Beispiel für Diagnose), direkt für die Steuergerätesimulation verwendbar. Bei der Executable-Generierung aus Simulink-Modellen über ein spezielles CANoe-Target kann ein XCP-Treiber in das Executable kompiliert werden. Damit kann die VN8900-Prototypenlaufzeitumgebung über XCPonEthernet problemlos mit einen Kalibriertool wie CANape gemes9/18

© automotive

sen und verstellt werden (Bild 3). Zahlreiche Kunden des VN8900 entwickeln teilweise von selbst immer wieder neue Anwendungsfälle. Beispielsweise ermöglicht die Stand-Alone-Betriebsart mit dem integrierten 2-Gbit-Flashspeicher (ca. 1 Gbit frei) beziehungsweise externen USB-Anschlüssen für Massenspeicher auch eine Nutzung für Datenaufzeichnungen ohne Bedien-PC. Fazit Mit bis zu sieben CAN-, LIN- und FlexRay-Kanälen sowie optional erweiterbarer I/O-Hardware profitiert der Anwender bei der Steuergeräteentwicklung von Elektro-/HybridFahrzeugen von der Flexibilität der VN8900-Schnittstellenlösung. Der integrierte Echtzeitkern ermöglicht kurze und deterministische Antwortzeiten. Der Einsatz als Rapid-Prototyping-Hardware und für Stand-Alone-Anwendungen bietet eine weitreichende Nutzung des VN8900 über einen Großteil der Projektlaufzeit. Nicht zuletzt tragen die zahlreichen Anwendungsfälle mit ein und derselben Hardware und den damit einhergehenden Produktionsstückzahlen dazu bei, dass das VN8900 auch eine kosteneffiziente Lösung besonders für die Entwicklung von EV-/HEV-Fahrzeugnetzen darstellt. (oe)

Dipl.-Ing. (FH) Alfred Kless war nach seinem Studiums der Elektrotechnik an der FH Esslingen zunächst bei ALCATEL unter anderem als Teamleiter für die Softwareentwicklung und Business Development von Testsystemen tätig. Seit Mai 2004 arbeitet er bei Vector Informatik in Stuttgart als Business Development Manager für die Produktlinien „Measurement & Calibration“ sowie „Network Interfaces“.

@

Vector Informatik www.vector.com

Entwicklung + Test

llll Antrieb

Elektromobilität auf dem Vormarsch

(Bild: Hochschule Offenburg)

626,6 Kilometer unter Realbedingungen mit einer Batterieladung Zahlreiche Forschungsprojekte konzentrieren sich auf Themen rund um die Elektromobilität. Als kritischer Punkt wird noch immer der Aktionsradius von Elektrofahrzeugen angesehen. Besonders interessant ist in diesem Zusammenhang das „Schluckspecht“-Projekt, dessen gleichnamiges Fahrzeug auf der Solar Challenge 2010 in Südafrika mit 626,6 km die längste Strecke zurückgelegt hat, die von einem Elektroauto im öffentlichen Straßenverkehr mit einer einzigen Batterieladung erreicht worden ist. Von Heiko Ruth und Jochen Neuffer

U

m ein Elektroauto mit großer Reichweite zu bauen, sind Optimierungen in allen relevanten Disziplinen notwendig. Benötigt werden ein Antrieb mit hohem Wirkungsgrad, leichte und kompakte Batterien mit hoher Energiedichte, passende Leistungselektronik, ausgefeilte Steuerungs- und Regelungsalgorithmen sowie eine effiziente Netzwerkkommunikation. Eine entscheidende Rolle spielt natürlich das Fahrzeuggewicht, das heißt, der mechanische Auf bau von Fahrgestell und Karosserie muss leicht und trotzdem stabil sein, und nicht zuletzt sind Sicherheitsaspekte und insbesondere ein wirkungsvolles Bremssystem nicht zu vernachlässigen.

ˆ Hochschulprojekt mit langer Tradition Auch die Hochschule Offenburg beschäftigt sich mit diesem Thema und kann hier mit ihrem studentischen Projekt „Schluckspecht“ bereits auf mehr als zehn Jahre Erfahrung in der Elektromobilität zurückblicken. Seit 1998 nimmt das Team Schluckspecht z.B. am europäischen Shell Eco-Marathon teil, einem Wettbewerb, bei dem das energieeffizienteste Fahrzeug ausgezeichnet wird. Mit einem niedrigen Äquivalenzdurchschnittsverbrauch von lediglich 0,032 l Superbenzin auf 100 km konnte das Konzeptfahrzeug Schluckspecht III plus im Jahr 2008 in der Brennstoffzellenkategorie den ersten Platz belegen; das

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/20

Entwicklung + Test

Antrieb llll

entspricht einer gefahrenen Strecke von über 3.100 km/l. Alle relevanten Teile von Motor, Karosserie und Radaufhängung bis zur Fahrzeugelektronik hat das Team mit Forschungspartnern selbst entwickelt. Ermutigt durch diesen und andere Erfolge fiel die Entscheidung für eine Teilnahme an der South African Solar Challenge, einem Wettbewerb für alternativ betriebene Fahrzeuge. Er findet auf öffentlichen Straßen rund um die Republik Südafrika statt, wobei auch etliche Steigungen zu bewältigen sind. Da es sich beim Schluckspecht IV E (Bild 1) um ein rein batteriegetriebenes Fahrzeug auf Basis von Lithium-Ionen-Batterien handelt, nimmt das Team außer Konkurrenz, aber unter offizieller Aufsicht der FIA (Fédération Internationale de l´Automobile) teil. Ziel ist es, die Öffentlichkeit auf die Leistungsfähigkeit des beim Schluckspecht umgesetzten Direktantriebs aufmerksam zu machen. Offiziell dokumentiert wurde schließlich eine Fahrstrecke von 626,6 km mit einer einzigen Batterieladung, soviel, wie zuvor noch nie mit einem Elektroauto unter vergleichbaren Bedingungen auf öffentlichen Straßen zurückgelegt worden ist.

ˆ Radnaben-Direktantrieb mit eisenfreien Erregerwicklungen Das Erfolgsgeheimnis des Schluckspecht IV E, einer Variante der vierwww.elektroniknet.de

ten Versuchsfahrzeuggeneration, basiert auf einem Antriebskonzept mit Radnabenmotoren, das die Hochschule Offenburg in Zusammenarbeit mit der Stuttgarter Ingenieurgesellschaft Evomotiv entwickelt hat. Inklusive der zwölf Lithium-IonenAkkupacks wiegt das Fahrzeug rund 320 kg und wird über zwei Radnabenmotoren mit jeweils 42 Polen und 2 kW Spitzenleistung angetrieben. Es ist als Weiterentwicklung aus der Fahrzeugvariante Schluckspecht City hervorgegangen und im Hinblick auf einen hohen Wirkungsgrad mit bürstenlosen Gleichstrommotoren ausgestattet. Bei diesem Motortyp trägt der Rotor Permanentmagnete, während sich auf dem Stator die Erregerwicklungen befinden. Eine Besonderheit des Schluckspecht-Motors ist der eisenfreie Aufbau von Stator und Erregerspulen. Bei dieser Variante gibt es keinerlei Rastmomente, wie sie bei einem konventionellen, nicht eisenfreien Aufbau auftreten würden. Periodische Rastmomente führen zu mechanischen Schwingungen sowie Drehzahlschwankungen und verschlechtern den Wirkungsgrad. Ein entscheidender Vorteil – neben einem höheren Anlaufmoment und einem geräuschärmeren Betrieb – ist jedoch, dass das Rad im stromlosen erregungsfreien Motorzustand nahezu verzögerungsfrei dreht und auf eine Trennkupplung samt Getriebe, Differenzial usw. verzichtet werden kann. Da die Direktantriebe den Vortrieb exakt dort erzeugen, wo er benötigt wird, erreicht das System einen Wirkungsgrad bis zu 98 Prozent. Dieses Motorkonzept ist im Jahr 2006 mit dem Bosch-Innovationspreis ausgezeichnet worden.

ˆ Optimierte Kommutierungsstrategie mit PWMAnsteuerung Durch das bürstenlose Wirkprinzip arbeiten die Radnabenantriebe nahezu verschleißfrei, ebenso wie umrichtergesteuerte Drehstrom-Asynchronmaschinen, der Quasistandard der industriellen Antriebstechnik. Zwingend notwendig ist dafür allerdings eine elektronische Kommutierung, die dafür sorgt, dass die Richtung der Magnetfelder in den Spulen zum richwww.elektroniknet.de

l Bild 1. Schluckspecht IV E bei der Solar Challenge in Südafrika.

tigen Zeitpunkt abwechselnd anziehend und abstoßend auf die Dauermagnete wirkt, entsprechend dem Grundprinzip jedes Elektromotors. Voraussetzung hierfür, insbesondere für die Startkommutierung, ist eine genaue Kenntnis der Rotorlage. Mehrere Hall-Sensoren erfassen die Position der Dauermagnete. Daraus generiert eine Auswerteeinheit über ein Quadratursignal (Bild 2) vier Spuren (A, B, Strobe, Index), die einem nachgeschalteten digitalen Signalprozessor vom Typ Texas Instruments TMS320 alle notwendigen Informationen über die Drehrichtung und die Rotorlage liefern (Bild 3). Der Signalprozessor, der unter anderem über zwei CAN-Module zur Anbindung an die Bordnetzarchitektur verfügt, erzeugt zwei um 180° phasenverschobene PWM-Signale (Bild 4) zur Ansteuerung der Leistungselektronik. So lässt sich über die Brückenschaltung jede Erregerwicklung auf die positive (T1, T5, T3) oder negative (T4, T6, T2) Zwischenkreisspannung schalten und die Richtung des Stromflusses bzw. des Magnetfeldes steuern. Um die geringe Induktivität des Motors zu kompensieren, verwenden die Ingenieure und Studenten eine relativ hohe PWM-Frequenz. Aus Sicht der Spule schaltet diese vier Mal pro PWM-Zyklus. Weiterhin ist das System durch die Änderung des Tastverhältnisses umschaltbar zwischen motorischem und generatorischem Betrieb, so dass beim Bremsen eine Energierückgewinnung möglich ist. Das Besondere

(Bild: Evomotiv GmbH)

hierbei ist, dass durch die vier wechselnden Zustände der optimierten Kommutierungsstrategie mit der halben PWM-Frequenz gearbeitet werden kann. Zu Mess- und Testzwecken sowie zur Kalibrierung der Motorparameter unabhängig vom eigentlichen Fahrzeug haben Evomotiv so-

A B 0 1 2 3 4 5 6 7 8 9 a b Index Strobe

l Bild 2. Quadratursignal.

(Bild: Evomotiv GmbH)

Hall-Sensor-Platine A, B, Strobe, Index 4 Quadraturmodul PWM TMS320 C2000 6 T1-T6 T1

T5

T3

T4

T6

T2

+

Sensoren

l Bild 3. Systembild Motor / Umrichterbrücke / Prozessor. (Bild: Evomotiv GmbH)

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/21

Entwicklung + Test

llll Antrieb

T = 1/30 kHz PWM1

Kanal Hi Kanal Lo

PWM2

Kanal Hi Kanal Lo

l Bild 4. PWM-Signale zur Kommutierung. (Bild: Evomotiv GmbH)

Antrieb llll

hören ebenso das Synchronisieren der antreibenden Räder bei Kurvenfahrten, da ja kein mechanisches Differenzial vorhanden ist, sowie eine Schlupfüberwachung. Die elektronische Kommunikation verteilt sich auf die Busse CAN1, CAN2 und CAN3. Während CAN1 das HMI mit dem Zentralsteuergerät verbindet, ist CAN2 für die Batteriesteuerung verantwortlich. Weil diese beiden Bereiche nicht zeitkritisch sind, arbeiten sie mit der Low-Speed-Übertragungsrate von 125 Kbit/s. CAN3 hingegen ist als High-Speed-CAN mit 1 Mbit/s ausgeführt, da dieser die Motorsteuergeräte vernetzt.

ˆ Restbussimulation ermöglicht parallele Steuergeräteentwicklung

l Bild 5. Motorprüfstand der Evomotiv GmbH.

(Bild: Evomotiv GmbH)

wie die Hochschule Offenburg eigens einen Motorprüfstand eingerichtet (Bild 5).

ˆ Vernetzte Elektronik im Dienst der Elektromobilität Das Elektronikkonzept des Schluckspecht IV E besteht im Wesentlichen aus einem Zentralsteuergerät, dem HMI-Steuergerät (Human-MachineInterface) sowie mehreren Batteriesteuergeräten. Letztere überwachen permanent die Spannung und die Temperatur der Batterien. Das Zentralsteuergerät regelt den Verbund der Radnabenmotoren in Abhängigkeit der Fahreraktivitäten bzw. des HMI und fungiert auch als Master für die Batteriesteuergeräte. In der Rolle des Masters kann das Hauptsteuergerät durch eine Unterbrechung der Energiezufuhr in Notsituationen das Gesamtsystem schnell abschalten. Weiterhin dient dieses Steuergerät als zentrales Gateway für die drei CAN-Busse des Fahrzeugs (Bild 6). In den Verantwortungsbereich der Fahrzeugregelung gehören sowohl sicherheitstechnische Aufgaben als auch das Steuern der Fahrdynamik. Dazu verfügt jeder der Radnabenmotoren über ein eigenes Motorsteuergerät. Zur Fahrdynamikregelung ge-

Während des Entwicklungsprozesses der Steuergeräte und der Software wurden auch die Beteiligten in der Hochschule Offenburg und beim Partner Evomotiv mit den typischen Problemen konfrontiert, die bei komplexen Kommunikationsstrukturen verteilter Systeme auftreten. In der Regel befinden sich einige der Entwicklungen noch im Anfangs- bzw. Prototypenstadium, während andere bereits weiter fortgeschritten sind. Um die fertigen Systeme reali-

ˆ Von der Simulation zum realen Steuergerät Mehr als die Hälfte der Steuergeräte haben die Entwickler zu Anfang auf diese Weise im Schluckspecht simuliert. Die mit der CANoe-eigenen Programmiersprache CAPL erstellten Steuergeräteapplikationen sorgen auf Basis der Restbussimulation so auch ohne Fahrzeug für eine große Testtie-

HMI-Steuergerät Motorsteuergerät

CAN1 125 Kbit/s

CAN3 1 Mbit/s

Motorsteuergerät

CAN3 1 Mbit/s

Zentralsteuergerät Zentralfunktionen Schlupfregler Batteriesteuerung CAN2 125 Kbit/s Batteriesteuergerät CAN3 1 Mbit/s Motorsteuergerät l Bild 6. Systemübersicht des Gesamtfahrzeugs.

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/22

tätsnah zu testen, sind Entwickler jedoch auf die Funktionen der noch nicht existierenden Systeme angewiesen – zumindest auf wesentliche Teile davon. Die Lösung liefert eine Restbussimulation, bei der eine geeignete Software die noch nicht real vorhandenen Steuergeräte auf einem Rechner simuliert. Beim Schluckspecht-Projekt kam als Standard-Werkzeug für diesen Anwendungsfall CANoe von Vector Informatik als Analyse- und Simulationssystem zum Einsatz. Die Restbussimulation lässt sich mit der Windows-Software erstellen, sobald die Verantwortlichen die Datenbasis für das Netzwerk einmal vollständig und korrekt parametriert haben. Der Vector Interaction Layer sorgt dann automatisch dafür, dass jede Botschaft mit ihrer in der Datenbasis spezifizierten Sendeart verschickt wird.

tente Darstellung auf der Empfangsseite. Der umgekehrte Weg ist ebenfalls möglich, und die Techniker können das Netzwerk des Versuchsfahrzeuges vom Begleitfahrzeug aus stimulieren. Dabei haben die Stimuli aus dem Bedien-Panel im Begleitfahrzeug eine höhere Priorität als die Eingriffe des Fahrers auf das System. Im Extremfall lässt sich das Fahrzeug sogar komplett fernsteuern.

ˆ FlexRay kommt ins Elektrofahrzeug

l Bild 7. CANoe als Analyse- und Überwachungswerkzeug.

fe. Zum Testen des zentralen Gateways erschien es beispielsweise sinnvoll, eine spezielle Simulationsoberfläche zu implementieren. Werden nun die einzelnen Steuergeräte im weiteren Entwicklungsverlauf nach und nach fertig, lässt sich der betreffende Teil der Restbussimulation einfach abschalten. Am Ende ist das vollständige Netzwerk real vorhanden, und CANoe arbeitet als reines Analyse- und Überwachungs-Werkzeug (Bild 7). Dieselbe Konfiguration, die in der frühen Entwicklungsphase die Restbussimulation bereitstellt, dient auf den Testfahrten des Schluckspecht IV E zum Überwachen und gegebenenfalls zum Eingreifen in das fahrzeuginterne Geschehen. Alle Knoten im Simulationsaufbau der CANoe-Konfiguration sind abgeschaltet, da sämtliche Steuergeräte nun real vorhanden sind. Auf der Wettbewerbsfahrt in Südafrika überwachten die Ingenieure und angehenden Ingenieure so zum Beispiel die Temperatur, die Spannung und den Strom der Batterien und sind in der Lage, verschiedene Antriebsmomente über Fahrstufen vorzugeben. Das HMI-Panel erlaubt darüber hinaus die Anzeige und die Stimulation von Bremse und Blinker.

ˆ Fernüberwachung bei Versuchsfahrten

CAN3 1 Mbit/s Motorsteuergerät (Bild: Evomotiv GmbH)

www.elektroniknet.de

Entwicklung + Test

Interessant ist weiterhin, dass bei der Solar Challenge alle Überwachungsund Steuerungsaktivitäten von eiwww.elektroniknet.de

(Bild: Vector Informatik GmbH)

nem Begleitfahrzeug aus vorgenommen werden. Die Herausforderung ist dabei das drahtlose Übermitteln der Kommunikationsdaten des Fahrzeugnetzwerks an den Analyserechner im Begleitfahrzeug. Spezielle CAN-/WLAN-Schnittstellenmodule mit einer Reichweite bis zu 500 m spiegeln hierzu den gesamten CANVerkehr des Versuchsfahrzeug über WLAN in das entfernte Netzwerk auf dem Begleitfahrzeug. Dieser Vorgang ist für CANoe völlig transparent, so dass sich das Werkzeug wie gewohnt zum Anzeigen und Auswerten der Systemparameter im Wettbewerbsfahrzeug nutzen lässt. Die Zeitstempel der CAN-Botschaften, die bei der Übertragung erhalten bleiben, erlauben eine (zeit-)konsis-

Dipl.-Ing. (FH) Jochen Neuffer studierte Nachrichtentechnik an der Fachhochschule Esslingen. Seit 2002 arbeitet er bei Vector Informatik und ist dort als Product Management Engineer im Bereich Tools for Network and Distributed Systems tätig.

Die in den Wettbewerben gewonnenen Erkenntnisse fließen im Rahmen des Wissenstransfers zeitnah in Weiterentwicklungen der Industriepartner oder in eigene Projekte ein. Evomotiv arbeitet zusammen mit den Wissenschaftlern aus Offenburg an einem verbesserten Radnabenmotor für eine Straßenversion des Elektromobils. Im Fokus stehen dabei eine deutliche Erhöhung der Motorleistung von 2 kW auf 15 kW sowie Vierrad- statt Zweirad-Antrieb. Für die sicherheitsrelevanten Komponenten, wie beispielsweise die Bremse, sind diverse TÜV-Zulassungen unverzichtbar. Angedacht ist auch eine Spannung von 400 V statt der derzeitigen 48 V zum Speisen der Motoren. Weiterhin ist der Einsatz von FlexRay für die zeitkritische Kommunikation zwischen Steuergeräten, Motoren und Bremssystem und zur Realisierung der zugehörigen Regelkreise vorgesehen. sj

Dipl.-Ing. (FH) Heiko Ruth studierte an der Fachhochschule Esslingen Informationstechnik und arbeitet seit 2008 bei der Evomotiv GmbH. Seit 2009 ist er Systemingenieur des Gemeinschaftsprojekts zwischen Evomotiv und der Hochschule Offenburg. Hierfür entwickelt er die Motorsteuerung sowie die Längsregelung des Prototyps.

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/23

llll Intelligentes Laden

Intelligentes Laden llll

Komfortables Laden Intelligentes Laden mit Microsar IP ermöglicht flexible Ladevorgänge und einfache Bezahlung Im Unterschied zu konventionell angetriebenen Fahrzeugen haben Elektrofahrzeuge aufgrund der geringen Energiedichte von Batterien eine deutlich geringere Reichweite. Für eine erfolgreiche Markteinführung von E-Fahrzeugen ist eine weit verbreitete und einfach zu bedienende Lade-Infrastruktur wichtig, und standardisierte Ladeverfahren müssen verfügbar sein. Dieser Artikel beschreibt das intelligente Laden (Smart Charging) und dessen Standardisierung in der Norm ISO 15118, die bis Mitte 2012 freigegeben werden soll. Zusätzlich zum Stromanschluss baut das Fahrzeug dabei eine Kommunikation zur Ladesäule auf. Von Thorsten Albers

D

as Laden der Elektrofahrzeuge erfolgt heute meist zuhause. Im öffentlichen Raum sind bisher, im Rahmen von Modellversuchen abgesehen, nur wenige Ladesäulen verfügbar. Da Fahrzeuge häufig stehen, wie beispielsweise beim Einkaufen und am Arbeitsplatz, könnten sie in dieser Zeit geladen werden. Dazu wird in Zu-

kunft eine weitläufige und standardisierte Infrastruktur in-stalliert. Diese muss sowohl standardisierte Mechanismen zum Laden der Batterien anbieten als auch eine ein-fache Bezahlung der Energie unterstützen. Deshalb soll das Abrechnen der Beträge bequem durch eine automatisierte elektronische Rechnung erfolgen.

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/24

Der flächendeckende Aufbau einer Lade-Infrastruktur kann nur funktionieren, wenn hierbei alle Aspekte des Ladens herstellerübergreifend standardisiert werden. Sowohl Stecker und Kabel als auch die Ladekommunikation müssen für alle Fahrzeuge und Ladesäulen normiert sein. In Europa ist die Ladekommunikation im Rahmen der ISO 15118 beschrieben. Dasselbe geschieht in den USA in der SAE (Tabelle). In Japan gibt es bereits den Standard CHAdeMO und ein Ladesäulennetz mit mehr als 250 Stationen.

ˆ Bereitstellen der Energie Das Laden von E-Fahrzeugen kann das Stromnetz lokal stark belasten. Heutige Stromnetze brauchen einige Zeit, um auf solche Belastungsänderungen zu reagieren. Versuchen mehrere Fahrzeuge an einem Ort, z.B. in einem Parkhaus, gleichzeitig mit hoher Leistung zu laden, kann dies zur Netzüberlastung und zu einem Netzausfall führen. Bisher wird beim Laden keine Rücksicht auf den gesamten Leistungsbedarf im Netz genommen. Sobald der www.elektroniknet.de

Fahrer das Ladekabel eines Fahrzeugs einsteckt, beginnt das Laden mit dem maximal möglichen Strom, und das Netz wird entsprechend belastet. Dies entspricht dem Modell des Tankens an einer normalen Tankstelle, wo Energie in Form von Benzin immer vorrätig und leicht abrufbar ist. Mit der elektrischen Energie verhält es sich aber anders. Diese kann man nicht beliebig speichern und wieder abgeben. Durch das Einführen eines intelligenten Stromnetzes (Smart Grid) und durch intelligentes Laden kann man eine Überlastung oder einen Ausfall des Netzes verhindern. Bei einem Smart Grid werden Daten zum Leistungsbedarf ausgetauscht und so das Stromnetz optimiert. Die für einen Ladevorgang benötigte Leistung liegt in der Größenordnung zwischen 3 kW und 20 kW oder sogar bis über 100 kW, je nach verfügbarem Stromanschluss und Ladeprofil. Zum Vergleich: In Deutschland verbraucht der durchschnittliche Bürger je nach Haushaltsgröße täglich 3 bis 5 kWh an elektrischer Energie. Um das Netz stabil zu betreiben, benötigt der Energielieferant Zeit zum Bereitstellen der Ladeenergie. Diese Zeit kann er gewinnen, indem der Start des Ladevorgangs um einige zehn Sekunden verzögert wird.

ˆ Ladeverfahren für Gleich- oder Wechselstrom Beim Laden der Batterien kann man grundsätzlich zwischen zwei Ladeverfahren unterscheiden (Bild 1). Zum einen klässt sich die Batterie über Wechselstrom laden, so wie er im Stromnetz ein- oder dreiphasig verfügbar ist. Hierbei ist das Laden an nahezu jeder Steckdose möglich. Dafür muss aber das Ladegerät im Fahrzeug verbaut sein, was wiederum zusätzliches Gewicht bedeutet. In der zweiten Variante kann über Gleichstrom geladen werden. Dabei befindet sich das Ladegerät außerhalb des Fahrzeugs in der Ladesäule und erzeugt die Gleichspannung zum Laden der Batterien. Das Gewicht des Ladegeräts spielt in diesem Fall keine Rolle, jedoch sind die Kosten für eine solche Gleichstromladesäule höher. Da beide Ladeverfahren ihre Vor- und Nachteile haben, werden sie parallel zum Einsatz kommen. www.elektroniknet.de

ˆ Kommunikation zwischen Fahrzeug, Ladesäule und Energieversorger Müsste das Fahrzeug zum Laden nur mit der Ladesäule kommunizieren, wäre man sehr frei in der Wahl von Übertragungsmedium und -protokoll. Die Ladesäule und das Fahrzeug sollen jedoch auch mit verschiedenen Servern im Internet kommunizieren (Bild 2). Daher bietet es sich an, auch für die Kommunikation zwischen Elektroauto und Ladesäule die gängigen Protokolle aus IP-basierten Netzwerken zu verwenden. Da neben dem Kabel für den Ladestrom keine weiteren Leitungen zur Kommunikation verwendet werden sollen, erfolgt die Kommunikation direkt über das Ladekabel (Bild 3). Dazu bietet sich die PLC-Technologie an (Power Line Communication). Bei diesem System wird der Datenstrom auf die Stromleitung aufmoduliert. Bekannt ist dieses System unter den Namen Homeplug AV oder IP over Powerline aus dem Heimanwenderbereich, um private Computer-Netzwerke über die Stromleitungen eines Gebäudes aufzubauen. Im Ladesteuergerät des Fahrzeugs wird für die Kommunikation ein TCP/ IP-Stack verwendet. Dieser stellt eine Socket-Kommunikation über IP (Internet Protocol) und TCP (Transmission Control Protocol) beziehungsweise UDP (User Datagram Protocol) zur Verfügung. Darauf aufgesetzt sind einige Anwendungen und Protokolle wie:  DNS (Domain Name System) zur Namensauflösung  TLS (Transport Layer Security) zum Verschlüsseln der Daten auf Transportebene  V2GTP (Vehicle To Grid Transport Protocol), ein neues Protokoll für die Verbindungskontrolle und den Datentransfer Außerdem wird noch ein Modul benötigt, in dem die intelligenten Ladefunktionen aus der ISO 15118 enthalten sind. Dafür hat Vector ein eigenes Standardmodul mit dem Namen SCC (Smart Charge Communication) entwickelt. Es stellt die Verbindung zur Ladesäule her und tauscht darüber die Parameter des Ladevor-

Energie-Management

Definition of vehicle to grid communication interface ISO/OSI Layer

Europe

7 Application

ISO/IEC 15118 Part 1

SAE J2836

USA

General information and use case definition

Content

7 Application 6 Presentation 5 Session 4 Transport 3 Network

ISO/IEC 15118 Part 2

SAE J2847

Technical protocol description and OSI layer requirements

2 Data Link 1 Physical

ISO/IEC 15118 Part 3

SAE J2931

Wired physical and data link layer requirements

l Die Ladekommunikation ist in ISO- und SAE-Normen festgelegt.

Laden mit Wechselstrom +

-

Ladestation Ladegerät

Laden mit Gleichstrom +

Ladestation

-

Ladegerät

l Bild 1. Zum Laden der Batterien werden zwei unterschiedliche Verfahren zum Einsatz kommen.

gangs aus. Das Modul ist durch Konfigurationsoptionen auf die Anforderungen von Fahrzeugherstellern und -zulieferern anpassbar. Derzeit erfolgt die Datenübertragung im Internet meistens noch über das Protokoll IPv4. Um der zunehmenden Adressknappheit im Internet zu entgehen, fordert die ISO von den Fahrzeugen und Ladesäulen die Unterstützung von IPv6. Insgesamt wird so im Fahrzeug ein System geschaffen, das sehr komplex und ressourcen-intensiv, dafür aber auch sehr mächtig ist. Eine bereits verfügbare Implementie- l Bild 2. Das Fahrrung existiert auf Basis des Microsar-IP- zeug nutzt das Stacks von Vector (Bild 4), die speziell Internet Profür Kraftfahrzeuge optimiert ist und tocol zum Komdem AUTOSAR-Standard entspricht. munizieren mit Zusätzlich zum TCP/IP-Stack be- der Ladesäule nötigt das Ladesteuergerät einen und Servern im CAN-Stack zur Anbindung an das Internet. Stromversorger

Stromkabel mit IP over Powerline Intelligentes Laden mit Microsar IP +

-

Batterie-Ladeeinheit

Ladestation

Energie-Management

Internet OEM

Elektronik automotive Sonderausgabe Elektromobilität 2011 9/25

Energie-Management

llll Intelligentes Laden

l Bild 3. Beispiel für einen Ladestecker, wie er für die Normung vorgeschlagen ist. (Bild: Mennekes Elektrotechnik GmbH & Co. KG)

Microsar IP SCC (enthält u.a. V2GTP) TLS

DNS

TCP/IP (enthält u.a. TCP, IPv4, UDP und DHCP) ETHIF (Ethernet Interface) ETHDRV (Ethernet Treiber) IP over Powerline AUTOSAR-Module IP-spezifische Erweiterungen

l Bild 4. Der Microsar-IP-Stack von Vector enthält die Module für die Kommunikation über das Internet Protocol.

vorhandene Fahrzeugnetzwerk. Darüber wird beispielsweise die Kommunikation mit dem Energie-Management sowie dem Bedien-Terminal realisiert (Bild 5).

ˆ Ablauf eines Ladevorgangs

desäule her. Dann erhält das Fahrzeug per DHCP eine IP-Adresse, woraufhin das SCC-Modul über einen Broadcast (ChargePointDiscovery) anfragt, welche IP-Adresse die Ladesäule hat. Nun baut das Fahrzeug eine TCP- und darüber eine TLS-Verbindung auf, wobei sich sowohl die Ladesäule als auch das Fahrzeug über Zertifikate authentifizieren. Über diese verschlüsselte Verbindung werden sowohl Dienste-Informationen, Tariftabellen und Ladeprofile ausgetauscht und ausgewählt als auch die Zahlungsmodalitäten geklärt. Nun wird das Kabel physikalisch verriegelt, damit es während des Ladevorgangs nicht abgezogen werden kann – unter anderem, um Stromdiebstahl zu verhindern. Zuletzt schaltet die Ladesäule den Strom ein, und das eigentliche Laden beginnt. Dabei tauschen Fahrzeug und Ladesäule regelmäßig ihren Status und Stromzählerstände aus und das Fahrzeug quittiert die Abnahme der Energie. Während des Ladens kann sich das Fahrzeug in einen Ruhezustand versetzen, um damit den eigenen Energieverbrauch zu reduzieren. Aus diesem Ruhezustand erwacht es periodisch, um eine Statusaktualisierung durchzuführen. Das Laden selbst wird dabei kontinuierlich fortgeführt. Am Ende schaltet die Ladesäule den Strom ab und löst die Steckerverriegelung. Der letzte quittierte Zählerstand wird zur Abrechnung über das Internet an den Energieversorger übermittelt.

ˆ Bezahlen per Micropayment Elektrofahrzeuge haben aufgrund der beschränkten Ladekapazität der verwendeten Batterien eine nur geringe Reichweite. Um trotzdem für ungeplante oder längere Fahrten gerüstet

Bei aktuellen Elektrofahrzeugen ist das Laden einfach: Man steckt den Stecker in die Ladesäule oder die SteckElektrofahrzeug Ladesäule dose, und schon startet der Ladevorgang. Bedien-Terminal Ladesteuergerät Beim intelligenten SCC Laden gemäß ISO 15118 ist der LadeCAN-Stack CAN-Stack IP-Stack IP-Stack vorgang aufwendiger. Mikrocontroller Mikrocontroller Mikrocontroller Nach dem Einstecken des Ladekabels stellt CAN Ethernet/IP das Fahrzeug zunächst über PLC eine Kommunikationsver- l Bild 5. Das Ladesteuergerät benötigt neben dem IP-Stack noch bindung mit der Laeinen CAN-Stack zur Kommunikation mit dem Bedien-Terminal. Elektronik automotive Sonderausgabe Elektromobilität 2011 9/26

zu sein, versucht man, die Batterien so oft wie möglich oder in kurzer Zeit zu laden. Soll beispielsweise eine typische 20-kWh-Batterie geladen werden, kostet das komplette Laden aufgrund verschiedener Tarife zwischen drei und zehn Euro. Häufig ist der Betrag deutlich geringer, da die Batterie selten von ganz leer auf ganz voll geladen wird. Um die vielen, teilweise recht kurzen Ladevorgänge nicht alle einzeln bezahlen zu müssen, bedarf es eines einfachen Bezahlsystems. Für das Bezahlen des Ladestroms gibt es prinzipiell verschiedene Möglichkeiten: Barzahlung, Kartenzahlung mit PIN oder ein automatisiertes Abrechnungsverfahren. Dieses kann zum Beispiel auf einer elektronischen Authentifizierung und einem zugehörigen Abrechnungsvertrag mit einem Energieversorger basieren – ähnlich wie ein Mobilfunkvertrag. Letzteres ist für die kleinen und ungeraden Beträge am sinnvollsten. Nebenbei kann so auch das Risiko von Vandalismus an den Ladesäulen im öffentlichen Raum reduziert werden, da an der Ladesäule nur noch eine Steckdose und eine kleine Anzeige benötigt werden. Der Preis für die Aufladung eines Elektroautos kann nicht pauschal angegeben werden, zu dessen Bestimmung werden dem Fahrzeug Preistabellen übermittelt. In der Kombination aus Preistabelle, Ladeprofil und der verfügbaren Leistung an der Ladesäule ergeben sich einige Varianten für Preis und Dauer der Ladung. Die Auswahl der zu nutzenden Variante findet durch eine Vorkonfiguration im Fahrzeug statt, damit die Ladung automatisch starten kann. sj

Dipl.-Ing. Thorsten Albers arbeitet seit 2005 als Software-Entwickler für Embedded-Systeme bei Vector Informatik. Seit drei Jahren ist er maßgeblich an der Entwicklung des Microsar-IP-Stacks für den Einsatz im Fahrzeug beteiligt.

www.elektroniknet.de

Entwicklung + Test

J1939-Vernetzung IIII

IIII J1939-Vernetzung

europäischen und dem amerikanischen Nutzfahrzeugmarkt ausgeprägte Unterschiede gibt. So schreiben die NfzKäufer in den USA den OEMs in der Regel vor, welche Komponenten sie in den jeweiligen Fahrzeugen zu verbauen haben. In Europa hingegen bestimmen die OEMs vollständig das Design des kompletten Fahrzeugs einschließlich der Komponenten und deren Konfiguration. Wichtig neben der Kommunikation über einheitlich definierte Signale und Datenformate ist natürlich, dass die Empfänger wissen, wie die Informationen jeweils zu interpretieren sind. Im Idealfall lassen sich die einzelnen J1939-Komponenten dann nach dem Plug-and-Play-Schema „zusammenstecken“. Trotz aller Vereinheitlichungen bietet J1939 genügend Freiheit für eine herstellerspezifische Erweiterung der Kommunikation. Das ist insbesondere für Innovationen wichtig, weil kein Hersteller diese vor der Implementierung zuvor in Gremien ausbreiten und diskutieren möchte.

Entwickeln mit J1939 Steuergeräte-Vernetzung in Nutzfahrzeugen Bei der Vernetzung von Steuergeräten im Nutzfahrzeug spielt das J1939-Protokoll eine zentrale Rolle, was aber einige Herausforderungen mit sich bringt. Geeignete Tools helfen jedoch bei der Entwicklung mit dieser Netzwerk-Architektur. Von Peter Fellmeth und Thomas Löffler

Wesentliche Einzeldokumente des J1939-Standards J1939

Generelle Beschreibung des Netzwerks

J1939/0X Beschreibung der Anwendung J1939/01 Nutzfahrzeuge (Truck und Bus) J1939/02 Landwirtschaft (Agricultural Equipment) J1939/7X Application Layer J1939/71 Fahrzeug J1939/73 Diagnose

Elektronik automotive 6.2008 10/0 2

J1939/31 Bridge, Router, Gateway, Filter J1939/21 Data Link Layer (Transportprotokolle, Acknowledge, ...) J1939/1X Beschreibung Physical Layer J1939/11 250 kbit/s, Twisted pair, geschirmt J1939/12 250 kbit/s, Twisted quad J1939/13 Diagnose-Stecker

D

ie J1939-Netzwerke basieren auf dem CAN-Bus (CANHighspeed nach ISO 11898) und finden in Antriebsstrang- und Fahrgestellkomponenten bevorzugten Einsatz. Das Protokoll schafft eine einheitliche Grundlage für die Kommunikation zwischen den elektronischen Steuergeräten und arbeitet nach dem Plug-and-Play-Prinzip. Für Entwicklungen auf Basis dieses Protokolls gibt es spezielle J1939-Tools und SoftwareKomponenten, die den Ingenieur von der detaillierten Einarbeitung in das J1939-Protokoll befreien und die Qualität des Entwicklungsprozesses steigern.

 Warum J1939 sinnvoll ist Das aus den USA stammende und von der Society of Automotive Engineers (SAE) definierte J1939-Protokoll dient vor allem dem Ziel, eine einheitliche Behandlung der gebräuchlichen Fahrzeugkomponenten bei verschiedenen Fahrzeugtypen bzw. Herstellern sicherzustellen. In diesem Zusammenhang ist interessant, dass es zwischen dem www.elektroniknet.de

 ISO-Schichtmodell entkoppelt Applikation von Übertragungsphysik Aus Sicht des ISO/OSI-Schichtmodells baut J1939 im Wesentlichen auf dem Application Layer (Schicht 7), dem Network Layer (Schicht 3), dem Data Link Layer (Schicht 2) und dem Physical Layer (Schicht 1) auf (Bild 1). Dies erlaubt den Entwicklern, nur mit Signalsequenzen arbeiten zu können, ohne sich auf Applikationsebene um Details der Kommunikation wie beispielsweise die Transportprotokolle kümmern zu müssen. Auch die Dokumentation/Definition von J1939 orientiert sich an den einzelnen Schichten, was sich in der Bezeichnung der insgesamt 14 Werke des Standards ausdrückt. So behandeln die Dokumente des 7er-Nummernkreises wie z.B. J1939/71 den Application Layer, das Dokument 21 den Data Link Layer usw. (einige Details hierzu im Kasten).

 Das CAN-Botschaftsformat bei J1939 J1939 nutzt zwar normale 29-bit-CANBotschaften mit bis zu 8 byte Daten, jedoch wird über den CAN-Identifier www.elektroniknet.de

Application (7) Network (3) Data Link (2) Physical (1) Phys. Übertragungsschicht

I Bild 1. Das J1939-Protokoll baut im Wesentlichen auf dem Application Layer (Schicht 7), dem Network Layer (Schicht 3), dem Data Link Layer (Schicht 2) und dem Physical Layer (Schicht 1) auf, so dass man sich auf der Applikationsebene nicht mehr mit den Details der Kommunikation beschäftigen muss. (Quelle der Grafiken: Vector Informatik)

quasi die Maske eines einheitlichen J1939-Schemas gelegt (Bild 2). Dies ist aufgrund der Plug-and-Play-Eigenschaften notwendig. So enthält der CAN-Identifier neben der Identifizierung der Nutzdaten mit Hilfe der Parameter Group Number (PGN) auch die J1939-Steuergeräte-Adressen des Senders und gegebenenfalls auch des Empfängers. Außerdem sind die drei höchstwertigen Bits des CAN-Identifier als Prioritätsfeld reserviert, die zwar nicht die im CAN-Protokoll implizite Pri-

Entwicklung + Test

orität ersetzen, jedoch die Zuordnung der Parameter Groups in bis zu acht J1939-spezifische Prioritätsstufen ermöglichen. Mit Hilfe dieser Prioritäten kann zum Zeitpunkt der Übertragung der Parameter Group oder während einer optionalen Konfigurationsphase des Steuergeräts die Priorität an die aktuellen Anforderungen der Anwendung angepasst werden. Dies ermöglicht eine feine Abstimmung der Kommunikation auf die Anwendung, ohne dass die SAE zum Zeitpunkt der Definition der Parameter Group die Priorität festlegt.

 Nomen est omen: die J1939-Gerätenamen J1939 definiert Gerätenamen, die jeweils durch eine 64-bit-Zahl repräsentiert sind. Schaltet man ein Steuergerät im Plug-and-Play-Netzwerk aktiv, dient der Gerätename zur Identifikation des Geräts und seiner Funktion. Der Gerätename unterteilt sich in verschiedene Elemente, zwischen denen teilweise Abhängigkeiten bestehen. Zu den unabhängigen Feldern gehören unter anderem die Industry Group und der Manufacturer Code. Über die Industriegruppe legt man die im

29 bit CAN-Identifier 28 ... 26 25 ... 8 7 ... 0 Parameter Group QuellPriorität Number (PGN) adresse

Data 0 ... 8 byte Protocol Data Unit (PDU)

Parameter Group Number (PGN) 25 24 23 ... 16 15 ... 8 erweiterte PDU Format Zieladresse/ Data Page Data Page (PF) Group Extension PDU Format 1 (specific) 23 ... 16 15 ... 8 00h ... EFh Zieladresse (DA) PDU Format 2 (global) 23 ... 16 15 ... 8 F0h ... FFh Group Extension (GE) I Bild 2. Aufgrund der Plug&Play-Fähigkeit bedarf das auf normalen 29-bit-CAN-Botschaften aufbauende J1939-Botschaftsformat einiger Ergänzungen. Über den CAN-Identifier wird quasi die Maske eines einheitlichen J1939-Schemas gelegt. Elektronik automotive 6.2008 10/1

Entwicklung + Test

J1939-Vernetzung IIII

IIII J1939-Vernetzung

Stichleitung

Bridges

ECU #H

ECU #G

Bus ECU #A ECU #B

ECU #C

ECU #C'

ECU #D

Zum nächsten Anhänger

250 kbit/s

I Bild 3. Hinsichtlich der Netzwerk-Topologie erlaubt J1939 eine flexible Gestaltung der Kabelbäume. Einzelne Steuergeräte lassen sich mit Stichleitungen von bis zu 3 m Länge anschließen, und Bridges ermöglichen es, separate Netzwerke auf Zugmaschinen und Anhänger zu realisieren.

Aktoren/ Sensoren VT-System

CANoe ECUSimulation

TestModul

CAN, LIN, MOST...

ECU (SUT)

ECUs CAN Stress

Stromversorgung (optional) IOCab

Multimeter Oszilloskop (DMM)

GPIB, RS 232, USB, IOCab I Bild 4. Durch entwicklungsbegleitende Tests mit Hilfe von Simulationen lassen sich in allen Entwicklungsphasen Fehler frühzeitig detektieren und beseitigen. Das „CANoe Test Feature Set“ stellt umfangreiche Test- und Analysemöglichkeiten zur Verfügung.

Netzwerk benötigten Funktionen fest, da das J1939-Protokoll nicht nur in herkömmlichen Nutzfahrzeugen zum Einsatz kommt, sondern auch in der Landtechnik oder im Maritim-Bereich. Jedes Steuergerät trägt einen von der SAE zugewiesenen Hersteller-Code, der dort zu beantragen ist. Da jedes Gerät zusätzlich eine Seriennummer hat, ist der gesamte Name weltweit eindeutig: Es kommen keine Überschneidungen vor. Da die Adressierbarkeit der Geräte über den 64 bit langen Gerätenamen in der Praxis mit CAN ineffizient ist, sind den einzelnen Fahrzeugkomponenten im Nutzfahrzeug-Umfeld durch die SAE feste 8-bit-Adressen zugewiesen; diese ändern sich in der Regel zur Laufzeit nie. Für die Landtechnik und den Maritim-Bereich trifft dies nicht zu, dort werden die Adressen beim Start unter Berücksichtigung des Gerätenamens dynamisch ausgehandelt. Die Adressen 0 bis 127 sind den gängigsten Steuergeräten wie Motor, Getriebe, Elektronik automotive 6.2008 10/2

Retarder, Bremsen usw. zugeordnet, während der Bereich von 128 bis 247 für Landtechnik, Schifffahrt, Baumaschinen usw. reserviert ist. WerkstattTools, OBD-Scanner usw. belegen die Adressen von 248 bis 253. Übrig bleiben als Sonderadressen die 254, mit der man Geräte kennzeichnet, die keine eigene Adresse haben, sowie die 255 als globale Adresse zur Adressierung von Broadcast Messages.

 Kommunikationsarten, Netzwerk-Topologie und Timing Das J1939-Protokoll unterstützt zwei Kommunkationsarten. Punkt-zu-PunktÜbertragungen (1:1) richten sich genau an eine Zieladresse, man verwendet sie beispielsweise zur Gerätekonfiguration oder für Steuergerätekommandos. Broadcast-Botschaften (1:n) hingegen sind an sämtliche Busteilnehmer gleichzeitig adressiert, was praktisch ist

für den Versand von Messwerten, zur Fehlerbehandlung und für Diagnosezwecke. J1939 arbeitet mit einem passiven Bus, der an beiden Enden mit dem Wellenwiderstand von 120 Ω abgeschlossen ist. Das hat den Vorteil, dass man einzelne Steuergeräte über Stichleitungen mit einer Länge von 1 bis 3 m anschließen kann. Kabelbäume lassen sich somit flexibel gestalten, solange man eine Gesamtbuslänge von 40 m nicht überschreitet. Je nach physikalischer Übertragungsschicht sind zwischen zehn und maximal 30 Knoten an das Netzwerk anschließbar. Für Werkstatt-Tester und OnBoard-Diagnosen stellt J1939 einen einheitlichen Diagnosezugang zur Verfügung. Gesetzliche Vorgaben verlangen, dass hierfür eine Stichleitung mit bis zu 5 m Länge möglich ist, etwa für Straßenkontrollen des Abgassystems. Mit Bridges lassen sich J1939-Netzwerke außerdem auf Anhänger erweitern, um dort ein separates Netz zu realisieren (Bild 3). In der EU hat sich für diesen Zweck die ISO 11992 durchgesetzt, während in den USA „Power Line Carrier“ Stand der Technik ist. Beim Design von J1939-Steuergeräten ist zu beachten, dass keine Botschaft durch Hardware- oder Design-Einschränkungen verlorengehen darf. Bei einer Übertragungsrate von 250 kbit/s dauert die Übertragung eines Bits 4 ms. Mit acht Datenbytes erhält man eine typische Botschaftslänge von ungefähr 128 bit, was zu einer Übertragungszeit von etwa 500 ms pro CAN-Botschaft führt. Die kürzeste Botschaftslänge liegt jedoch bei 64 bit, d.h., man muss in der Lage sein, Botschaften im Abstand von 250 ms zu empfangen und entsprechend schnell zu verarbeiten. Dies führt in der Praxis aufgrund der oft limitierten CAN-Identifier-Filtereigenschaften der CAN-Controller zu einer hohen Interrupt-Last. Zudem muss die Filterung deshalb meist in der Software realisiert werden.

 Test und Diagnose von J1939Komponenten und -Systemen Angesichts der steigenden Zahl von J1939-Steuergeräten und komplexer www.elektroniknet.de

werdenden Software-Architekturen im Nutzfahrzeug gewinnt eine systematische Test- und Diagnosestrategie auch im J1939-Umfeld immer größere Bedeutung. Tests sind in allen Entwicklungsphasen von Funktionstests über Integrationstests bis hin zur Fahr-Erprobung im Gesamtfahrzeug unverzichtbar. Je später Fehler detektiert werden, desto aufwendiger und teurer ist bekanntlich deren Beseitigung. Allerdings sind Steuergeräte in der Regel erst dann umfassend testbar, nachdem sie in den Netzwerkverbund integriert wurden. So offenbaren sich die Schwachstellen erst sehr spät, es sei denn, man setzt von Anfang an auf die Unterstützung durch bewährte Software-Werkzeuge. Vor diesem Hintergrund können sicherlich spezialisierte Tools den Entwicklern bei Test- und DiagnoseAufgaben wesentliche Erleichterungen bringen. Mit einer praxisgerechten Werkzeugpalette für alle J1939-Vorhaben, wie sie im Programm von Vector Informatik zu finden ist, lassen sich beispielsweise die Aufgaben bei der Vernetzung und Kommunikation im Nutzfahrzeugbereich effizient lösen [1]. Neben Entwicklungs-, Test- und Analyse-Tools sind auf die speziellen Anforderungen J1939-basierter Anwendungen zugeschnittene EmbeddedSoftware-Komponenten verfügbar, zusätzlich auch individuelle Projektarbeit und Schulungen. Für das verbreitete Entwicklungsund Testwerkzeug CANoe ist z.B. eine J1939-Erweiterung erhältlich, die den Nfz-Entwicklern die detaillierte Einarbeitung in das J1939-Protokoll erspart. Diese Erweiterung stockt die Funktionen der Basis-Software um alle notwendigen protokollspezifischen Besonderheiten auf. So dienen die in der Designphase damit erstellten Modelle und Datenbasen nicht nur als Grundlage für die Simulation während der Entwicklung, sondern auch für sämtliche entwicklungsbegleitenden Tests bis hin zu späteren Diagnose-Aufgaben (Bild 4). Somit können mit Hilfe simulierter Knoten frühzeitig Tests für das zu entwickelnde Steuergerät aufgesetzt und durchgeführt werden. Die Tests werden während der Entwicklung weiter verfeinert und bei der Verifikation des Gesamtsystems eingesetzt. www.elektroniknet.de

 Umfangreiche J1939 Test Library Das „CANoe Test Feature Set“ umfasst CAPL-Testmodule, XML-Testmodule und .NET-Testmodule. Je nach Komplexität der Testaufgabe lassen sich damit die Herausforderungen von einfachen bis schwierigen Testfällen abdecken. Während die C-ähnliche Skriptsprache CAPL zum Erstellen umfangreicher Testszenarien prädestiniert ist, stehen bei XML eine einfache Parametrierung von Testpattern und eine einfache Generierung von Testabläufen im Vordergrund. Das bietet die Möglichkeit, anwendungsspezifische Testmodule (Funktionsbibliotheken) in CAPL zu implementieren und anschließend die Teststeuerung individuell passend zur Konfiguration des Steuergeräts generieren zu lassen. Die J1939-spezifischen Erweiterungen in den Test Service Libraries ermöglichen dem System die Reaktion auf Parameter Groups (PG) anstatt der typischen CAN-Identifier, außerdem bieten sie Testmuster für J1939-Protokoll-Funktionen und Checks (Hintergrundüberwachungen) auf Protokollverletzungen. Somit lässt sich beispielsweise prüfen, ob das Steuergerät bei hoher Buslast in der Lage ist, alle Parameter Groups mit

Entwicklung + Test

der konfigurierten Zykluszeit zu senden. Ferner können die Transportprotokolle BAM (Broadcast Announce Message) und CMDT (Connection Mode Data Transfer) für Testzwecke auch fehlerhaft gesendet werden. Zur Erstellung der Testmodule ist neben dem J1939 Test Module Manager und dem komfortablen Test Automation Editor die Option „DiVa“ nützlich. Sie schafft eine Verbindung zwischen CANoe und dem Diagnosespezifikations-Tool „CANdelaStudio“, so dass dort erstellte Spezifikationen für steuergerätespezifische DiagnoseTests weiterverwendbar sind. Zu den weiteren Funktionen des Test Feature Sets gehören eine Testablaufsteuerung und die automatische Reportgenerierung einschließlich statistischer Informationen im XML- oder HTML-Format nach individuellen Vorgaben. Weitergehende Optionen zur Automatisierung der Testvorgänge eröffnet die COM-Schnittstelle, zum Beispiel hinsichtlich Ablaufsteuerung, Parameteränderungen oder Statusabfragen. Die CANoe-Option J1939 stellt für Diagnose-Zwecke auch Trace-Fenster, einen J1939-Diagnose-Monitor und den J1939-Diagnose-Speicherzugriff bereit. Der Diagnose-Monitor unterstützt die verschiedenen J1939-Diagnose-

I Bild 5. CANoe ist nicht nur in der Lage, Funktionsmodelle von Steuergeräten entlang des Entwicklungsprozesses zu simulieren und dabei mit Matlab/Simulink erstellte Modelle in die Szenarien einzubinden, sondern dient hier gleichzeitig als komfortable Benutzerschnittstelle. (Bild: Renault Trucks) Elektronik automotive 6.2008 10/3

Entwicklung + Test

IIII J1939-Vernetzung

Änderungen

Erstellt durch OEM

Datenbasis

Die Datenbasis wird an die Zulieferer verteilt Zulieferer 1 (Appl, GENy DatenCANbedded) basis Basis für ECU 1

Zulieferer 2 (Appl, GENy DatenCANbedded) basis Basis für ECU 2

ECU1

Zulieferer 3 (Appl, GENy DatenCANbedded) basis Basis für ECU 3

Zulieferer 4 (Appl, GENy DatenCANbedded) basis Basis für ECU 4

ECU3 CANoe

CAN ECU2

Test, Kompatibilität auf dem CAN-Bus aufgrund einer unmissverständlichen Signalinterpretation und Integrität sowie auch Flexibilität im J1939-Kommunikations-Stack. Unterstützt werden alle relevanten Mikrocontroller bei geringem Bedarf an ROM- und RAMKapazität sowie mit hoher Laufzeiteffizienz. ha Links [1] J1939-Lösungen der Vector Informatik GmbH: www.j1939-solutions.de

ECU4

I Bild 6. Die Standard-Software-Komponenten des CANbedded-J1939-Pakets führen rasch zu Entwicklungsergebnissen, ohne dass sich Entwickler mit allen Details des J1939-Standards befassen müssen. Eine zentral verwaltete Datenbank vermeidet Mehrfachentwicklungen und erlaubt die Arbeitsteilung.

Messages, wie beispielsweise DM1 und DM2, und dient zur Anzeige und zum Löschen von aktiven Fehlern. Möglich ist darüber hinaus ein Zugriff auf Speicherbereiche, Objekte und Parameter sowie eine zyklische Objektaktualisierung für Monitoring-Zwecke.

 Matlab/Simulink-Modelle in J1939-NetzwerkSimulationen einbinden Normalerweise werden während der verschiedenen Nutzfahrzeug-Entwicklungsphasen verschiedene Funktionsmodelle für mechanische Komponenten wie Getriebe, Antriebsstrang oder sogar das komplette Fahrzeug erstellt. Steuergeräte-Architekturen bildet man zunächst in virtuellen Funktionsmodellen ab und realisiert sie Schritt für Schritt auf der endgültigen HardwareZielplattform. CANoe.J1939 integriert auch Matlab/Simulink-Modelle in die Steuergeräte- und Netzwerk-Simulationen (Bild 5). Hierzu erzeugt der Anwender mit dem Real-Time Workshop von Mathworks eine *.DLL für CANoe, so dass Variablen-Namen und Units kompatibel sind. Entlang der verschiedenen Stufen des V-Entwicklungsmodells sind nun Einzeltests und Teilsystemtests möglich, bis hin zur endgültigen Verifikation des Gesamtsystems. So lassen sich Fehler frühzeitig aufspüren und beseitigen. Wird ein Fehler gefunden, könElektronik automotive 6.2008 10/4

nen die automatisierten Tests jederzeit erneut gestartet werden und minimieren das Risiko auf Seiteneffekte bei der Fehlerbehebung. Die Entwicklung ist somit durch kurze Verifikationszyklen gekennzeichnet und erlaubt einen nahtlosen Übergang vom MiL (Model In the Loop) über SIL (Software In the Loop) zum realen Steuergerät (HiL – Hardware In the Loop). Bei besonderen Anforderungen an die Echtzeit-Fähigkeit der Simulationsplattform ist mit CANoe RT eine spezielle Echtzeit-Version verfügbar. Zu schnellen Entwicklungsergebnissen führen die J1939-Software-Komponenten des Pakets CANbedded J1939. Sie entbinden die Entwickler zu einem Großteil von der Notwendigkeit, sich mit allen Details des J1939-Standards auseinanderzusetzen, und vermeiden Mehrfachentwicklungen. Im Mittelpunkt steht eine vom OEM verwaltete zentrale Datenbasis, in der alle elementaren Informationen der SteuergeräteKommunikation enthalten sind. Die Informationen werden – je nach Bedarf – an die beteiligten Partner verteilt, so dass sich eine flexible Arbeitsteilung zwischen OEM, den Netzwerkspezialisten von Vector sowie den Zulieferern ergibt (Bild 6). Letztere können mit dem Konfigurationswerkzeug GENy ihre spezifischen Einstellungen und Parametrierungen vornehmen. Das Ergebnis ist eine Reduzierung von Kosten und Zeit für Implementierung und

Dipl.-Ing. (FH) Peter Fellmeth studierte an der FH Esslingen im Fachgebiet Technische Informatik mit Schwerpunkt auf Automatisierungstechnik. Als Teamleiter und Produktmanager bei der Vector Informatik GmbH ist er verantwortlich für die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von J1939, ISOBUS, Ethernet und DeviceNet.

Dipl.-Ing. (FH) Thomas Löffler studierte Automatisierungstechnik an der Fachhochschule in Reutlingen. Er arbeitet seit 2000 bei der Vector Informatik GmbH, zu-nächst im Umfeld DeviceNet und seit 2002 im Bereich J1939 und ISOBUS. Seine Schwerpunkte sind Konfigurations- und Generierungswerkzeuge für Embedded Software sowie Betreuung von Kundenprojekten, Produkt- und Protokollschulungen.

www.elektroniknet.de 10/5

Entwicklung + Test

llll Bussysteme

Bussysteme llll

dung des bisherigen Type-I-Diagnosesteckers, der für 250 kbit/s ausgelegt ist. Ein Stecker Type II ist kompatibel zur Buchse Type I. Eine weitere Änderung ist, dass die Diagnosebuchse Type II die bisher für SAE J1708/J1587 benutzen Pins als reserviert kennzeichnet. Die Konsequenz daraus ist, dass ein J1708/J1587-Netzwerk über einen Diagnosestecker Type II nicht mehr angesprochen werden kann.

ˆ Die SAE macht Ernst bei der Dynamik

Quo Vadis SAE J1939 Überblick über die Standardisierungsaktivitäten bei SAE J1939 Aufgrund neuer Anforderungen an die Anwendungsschicht entwickelt die SAE den hauptsächlich bei der Vernetzung des Antriebsstrangs in Nutzfahrzeugen eingesetzten Standard J1939 ständig weiter. Doch auch in den anderen Kommunikationsschichten bis hin zur physikalischen Übertragungsschicht ergeben sich Optimierungen und Erweiterungen. Dieser Artikel fasst den aktuellen Stand der Diskussionen innerhalb der SAE-J1939-Arbeitskreise zusammen, z.B. die geplante Einführung der physikalischen Schicht mit einer Übertragungsrate von 500 kbit/s oder Änderungen am Netzwerk-Management. Außerdem werden die Standardisierungsarbeiten über J1939 in AUTOSAR Release 4 und die WWH-OBD-Diagnose beleuchtet. Von Peter Fellmeth und Holger Söhnle

B

asierend auf dem CANBus (CAN-Highspeed nach ISO 11898) kommt der SAE-J1939-Standard vor allem bei der Vernetzung des Antriebsstrangs und Fahrgestells in Nutzfahrzeugen zum Einsatz. Das Protokoll schafft eine einheitliche Grundlage für die Kommunikation zwischen den elektronischen Steuergeräten und arbeitet nach dem Plug-and-play-Prinzip. SAE J1939 ist ein aktiver Standard, der zwischenzeitlich 19 Dokumente umfasst (Tabelle 1). Elektronik automotive 12.2010 10/6

Die zuständigen SAE-Gremien treffen sich in aller Regel viermal im Jahr, um über Änderungen und Weiterentwicklungen zu bestimmen. Die aktuellen Versionen der Dokumente können einzeln oder im Paket als JPaks über die SAE-Internet-Seite [1] bezogen werden. Schon seit Jahren bewegen sich die Nutzfahrzeugentwickler durch die im Standard geregelte Begrenzung der Datenübertragungsrate auf 250 kbit/s an der Leistungsgrenze [2]. Aus Kommu-

nikationssicht ist die Entwicklung der 500-kbit/s-Datenübertragungsschicht ein überfälliger Schritt. Vor allem von europäischen Nutzfahrzeugherstellern gefordert, ist eine endgültige Verabschiedung absehbar. Die Spezifikation wird in einem eigenen Dokument, J1939-14, erfolgen und beinhaltet im Wesentlichen diese Aspekte: ` Verdoppelung der Datenübertragungsrate von 250 auf 500 kbit/s. ` Verwendung von geschirmten und ungeschirmten Kabeln, wie in [3] und [4] definiert, ist weiterhin möglich. ` Die Topologie ist grundsätzlich ein Bus mit Stichleitungen von max. einem Meter Länge. Für den Anschluss von Diagnosewerkzeugen kann zeitweise eine Stichleitung (von der Diagnosebuchse zum Diagnosewerkzeug) mit einer Länge von fünf Metern verwendet werden. ` Der Bus ist an beiden Enden mit einem Wellenwiderstand von 120 Ω abgeschlossen. Es sind bis zu 30 Knoten möglich. Die Spezifikation für den Diagnosestecker [5] wurde an die Verwendung von 500 kbit/s angepasst. Dazu kommt die neue Steckdose Type II am Fahrzeug zum Einsatz. Diese ist farblich grün gekennzeichnet und verhindert durch Steckerkodierung die Verwenwww.elektroniknet.de

Veränderungen gibt es auch im Netzwerk-Management [6]. Seit längerer Zeit wird im J1939-Gremium darüber beratschlagt, wie mit der Situation umgegangen werden soll, dass die vom Gremium fest zugewiesenen Steuergeräteadressen zur Neige gehen. Besonders für die Hersteller von Sensoren mit direktem Busanschluss stellt dies ein Problem dar. Durch steigende Anforderungen an Emissionsrichtlinien sowie zusätzliche Assistenzsysteme ist hier die Zahl neuer Geräte stark angewachsen. Viele Alternativen wurden erörtert und wieder verworfen. Diese

reichten von einem eigenen Netzwerk für Sensoren bis hin zur Implementierung eines neuen Protokolls, etwa durch die Verwendung von bisher reservierten Data Pages. Fakt war, dass die SAE zwischenzeitlich keine neuen Adressen mehr zugewiesen hat. Für einen Steuergerätehersteller war dies eine unbefriedigende Situation. So wusste er oft nicht, ob seine Realisierung langfristig Bestand haben würde. In der neuen Version des Netzwerk-Managements spricht die SAE die Empfehlung aus, „Address Arbitrary Capable“-Steuergeräte zu implementieren. Diese Steuergeräte sind in der Lage, ihre Adresse basierend auf der aktuellen Fahrzeugkonfiguration nun selbst zu berechnen – und zwar zur Laufzeit Dies läuft im Kern darauf hinaus, den schon immer vorhandenen, aber im Nutzfahrzeug nie wirklich implementierten und benutzen Mechanismus der dynamischen Adresszuweisung zu verwenden. Im Zusammenhang mit dem Netzwerk-Management ist das neu hinzugekommene Name-Management zu erwähnen. Hierbei handelt es sich um eine standardisierte Schnittstelle zur

Dokument

Entwicklung + Test

gezielten Veränderung von Komponenten des 64-bit-Gerätenamens. Dies ist z.B. dann notwendig, wenn vom Gerätenamen die konkrete Funktion/ Messgröße abgeleitet wird. So wird mit Hilfe des Gerätenamens die Position eines Abgastemperatursensors – vor oder nach dem Katalysator sowie rechte oder linke Seite bei zweiflutiger Abgasanlage – unterschieden. Änderungen können an mehreren Steuergeräten nacheinander eingestellt und zu einem Zeitpunkt aktiviert werden. Dies ist hilfreich, wenn beispielsweise mehreren Steuergeräten eines Verbundes gleichzeitig eine neue Function Instance zugewiesen werden soll. Die Änderungen im Netzwerk-Management werden vom Analysewerkzeug CANalyzer.J1939 sowie dem Entwicklungs- und Testwerkzeug CANoe. J1939 von Vector bereits in der Version 7.5 unterstützt.

ˆ AUTOSAR und J1939 finden zueinander Die Einführung von AUTOSAR im Pkw-Bereich läuft auf Hochtouren. Aber auch im Nutzfahrzeug- und

Stand

Status

J1939

Recommended Serial Control and Communications Vehicle Network

Veröffentlicht Stand Feb. 2010, mit Inhalt bis Feb. 2009

Neue Version in Bearbeitung

J1939

Companion Spreadsheet

Veröffentlicht Stand Feb. 2010, mit Inhalt bis Feb. 2010

Neue Version in Bearbeitung mit Inhalt bis Mai 2010

J1939-01

Recommended Practice for Control and Communications Network for On-Highway Equipment

Veröffentlicht Stand Sep. 2000

Neue Version im Abstimmungsverfahren

J1939-02

Agricultural and Forestry Off-Road Machinery, Control and Communications Network

Veröffentlicht Stand Aug. 2006

Turnusgemäße Überarbeitung nach fünf Jahren, geplant ab 2011

J1939-03

On-Board Diaganostics Implementations Guide

Veröffentlicht Stand Dez. 2008

Überarbeitung geplant ab Nov. 2010

J1939-05

Marine Stern Drive and In-Board Spark-Ignition, Engine On-Board Diagnostics Implementation Guide

Veröffentlicht Feb. 2008

Überarbeitung geplant ab Aug. 2010

J1939-11

Physical Layer, 250 kbit/s, Twisted Shielded Pair

Veröffentlicht Stand Sep. 2006

Turnusgemäße Überarbeitung nach fünf Jahren, geplant nach Veröffentlichung von J1939-14

J1939-13

Off-Board Diagnostic Connector

Veröffentlicht Stand Sep. 2006

Neue Version im Abstimmungsverfahren

J1939-14

Physical Layer – 500 kbit/s

Noch nicht veröffentlicht

In Bearbeitung, Abstimmung geplant in 2010

J1939-15

Reduced Physical Layer, 250 kbit/s, Un-Shielded Twisted Pair (UTP)

Veröffentlicht Stand Aug. 2008

Überarbeitung geplant nach Veröffentlichung von J1939-14

J1939-21

Data Link Layer

Veröffentlicht Stand Dez. 2006

Abstimmung beendet, Veröffentlichung geplant in 2010

J1939-31

Network Layer

Veröffentlicht Stand Mai 2010

Keine Aktivität

J1939-71

Vehicle Application Layer

Veröffentlicht Stand Feb. 2010, mit Inhalt bis Feb. 2009

Neue Version in Bearbeitung

J1939-73

Application Layer – Diagnostics

Veröffentlicht Stand Feb. 2010

Neue Version in Bearbeitung

J1939-74

Application Layer, Configurable Messaging

Veröffentlicht Stand Nov. 2006

Neue Version im Abstimmungsverfahren

J1939-75

Application Layer – Generator Sets and Industrial

Veröffentlicht Stand Jun. 2007

Turnusgemäße Überarbeitung nach fünf Jahren, geplant für Nov. 2010

J1939-81

Network Management

Veröffentlicht Stand Mai 2003

Neue Version im Abstimmungsverfahren

J1939-82

Compliance – Truck and Bus

Veröffentlicht Stand Aug. 2008

Keine Aktivität

J1939-84

OBD Communicatins Compliance Test Cases For Heavy Duty Components And Vehicles

Veröffentlicht Stand Dez. 2008

Neue Version in Bearbeitung

l Tabelle 1. Status der SAE J1939-Dokumente (Stand September 2010). www.elektroniknet.de

Elektronik automotive 12.2010 10/7

Entwicklung + Test

llll Bussysteme

Bussysteme llll

Konfigurationszeitpunkt ` Unterstützung mehrerer Botschaften festgelegt werden, ist eine mit gleichem Layout (dieselbe ParaAbbildung in AUTOSAR metergruppe). relativ einfach möglich: ` Netzwerk-Management nach SAE Durch feste SteuergeräteJ1939/81 ohne dynamisches NM, adressen sind Quell- und also ohne AAC (Arbitrary Address Zieladresse festgelegt, Capable). Parameter Group Number (PGN) Antworten auf eine Request-Botdadurch kann mit stati` 23 ... 16 25 24 15 ... 8 schaft. schen Identifiern gearExtended PDU Format PDU specific Data Page Data Page (PF) (PS) beitet werden. Zur Über- ` Unterstützung von Diagnosedienstragung von Daten, die ten. PDU Format 1 (specific) länger sind als die in eiOn-Board-Diagnose (WWH-OBD) ` 23 ... 16 15 ... 8 nem CAN-Frame verfügvia J1939. Destination 00h ... EFh baren 8 byte, spezifiziert Address (DA) In Zusammenarbeit mit großen euJ1939-21 zwei TransportPDU Format 2 (global) protokollvarianten (TP). ropäischen Nutzfahrzeugherstellern 23 ... 16 15 ... 8 Hierbei handelt es sich ist Vector an der Spezifizierung dieser Group F0h ... FFh um die Varianten Broad- J1939-Erweiterungen bei AUTOSAR Extension (GE) cast Announce Message beteiligt. Bereits heute bietet Vector l Bild 1. Aufbau eines 29-bit-Identifiers in J1939-Netzwerken. (BAM) und Connection eine AUTOSAR-Lösung mit J1939Mode Data Transfer Erweiterung entsprechend AUTOSAR Landtechnikmarkt gibt es Interesse, (CMDT; auch RTS/CTS genannt). Bei- Release 4.0 an (Bild 2). Diese steht bei die Vorteile von AUTOSAR zu nut- de sind bereits in AUTOSAR Release einem großen europäischen Nutzfahrzen. Allerdings standen die speziellen 4.0 definiert und seit Dezember 2009 zeughersteller kurz vor dem SerieneinAnforderungen dieser Märkte bei der verfügbar. Damit deckt AUTOSAR satz. Die Erweiterung für AUTOSAR Entwicklung von AUTOSAR nicht im Release 4.0 bereits die Anforderungen Release 4.1 befindet sich im EntwickFokus. Daher sind die bisher freigege- vieler europäischer Nutzfahrzeugher- lungsstadium. benen AUTOSAR-Versionen nur mit steller ab. Einschränkungen in diesen Märkten Eine weitergehende Unterstützung ˆ Diagnose von Nutzfahrzeugen der J1939-Anforderungen ist für Ennutzbar. Speziell die Anforderungen mittels WWH-OBD aus der SAE J1939 können nicht oder de 2012 mit AUTOSAR Release 4.1 nur sehr eingeschränkt mit dem aktu- geplant. Zielgruppe sind hier die euro- Die On-Board-Diagnose (OBD) ist ein ellen AUTOSAR-Konzept in Einklang päischen und teilweise auch die ameri- von der ISO genormtes Diagnosesysgebracht werden. kanischen Nutzfahrzeughersteller. tem, das unter anderem die abgasbeIm Wesentlichen werden die fol- einflussenden Systeme überwacht. Im Der statische Ansatz bei AUTOSAR steht im Gegensatz zum dynamischen genden Erweiterungen in AUTOSAR Laufe der Zeit wurden von dieser Norm regionale Standards abgeleitet (z.B. Verhalten bei J1939. Die AUTOSAR- einfließen: Architektur sieht nur feste CANIdentifier vor, d.h., es gibt eine feste Zuordnung zwischen genau einem Anwendung CAN-Identifier und einem BotschaftsMICROSAR RTE Layout. Im Gegensatz dazu gibt es bei MICROSAR COM J1939 die Zuordnung eines bestimmten COM IPDUM NM PDUR Botschafts-Layouts nur zu einem speBAM ziellen Teil des Identifiers, der Parametergruppe (PG). Die anderen BeCMDT standteile des 29-bit-Identifiers sind CANXCP Complex teilweise dynamisch und nicht zum CANTP Drivers Konfigurationszeitpunkt festgelegt. Ein CANSM solcher dynamischer Identifier kann in CANIF AUTOSAR modelliert werden, indem MICROSAR CAL MICROSAR EXT man für jede im Netzwerk zulässige Kombination aus Priorität, Quelladresse (SA) und Zieladresse (DA) einen eigenen statischen Identifier anlegt Mikrocontroller (Bild 1). Für den Fall, dass alle Netzknoten l Bild 2. Die AUTOSAR-Basis-Software von Vector enthält die beiden J1939-Transportprotokolle eines J1939-Netzwerkes bekannt sind BAM und CMDT. und die Knotenadressen bereits zum Elektronik automotive 12.2010 10/8

MICROSAR IO

MICROSAR IP

MICROSAR MOST

CANTRCV

MICROSAR FR

MICROSAR LIN

J1939TP

MICROSAR CAN

MICROSAR DIAG

MICROSAR MEM

XCP

CANDRV

MICROSAR SYS

MICROSAR OS

SAE-J1939-Nachricht (CAN-basiert) 29 Bit CAN-Identifier Data = 8 Byte 28 ... 26 25 ... 8 7 ... 0 Protocol Data Unit Parameter Group Source Priority (PDU) Number (PGN) Address (SA)

www.elektroniknet.de

Beschreibung / Inhalt der Spezifikation

Dokument

Allgemeine Informationen und Definition der Use Cases

ISO 27145-1

Definition der Diagnosedaten

ISO 27145-2

Definition der Diagnosedienste

ISO 27145-3

Kommunikation zwischen Fahrzeug und externem Testgerät

ISO 27145-4

Tests für die Einhaltung der Norm

ISO 27145-5

Externes Testgerät

ISO 27145-6

l Tabelle 2. Die WWH-OBD ist in den sechs Dokumenten der ISO 27145 festgelegt.

ISO15031), die nun in der WWH-OBD (World-Wide-Harmonized On-BoardDiagnostics) wieder zusammengeführt werden. Dieser Standard wurde durch die Vereinten Nationen initiiert und in deren Global Technical Regulation 5 (GTR 5) festgehalten. Die technische Umsetzung der GTR 5 erfolgt duch die

legt. Dabei erfolgte die Spezifikation der fahrzeugseitigen Implementierung, des Datenzugriffs und der OBD-Daten. Vorerst definieren die regionalen Behörden weiterhin die Grenz- und Schwellwerte, eine Vereinheitlichung zu einem späteren Zeit-

erfolgt erst punkt. Für die On-Board-Diagnose bei Nutzfahrzeugen sind heute die beiden CAN-basierten Protokolle Diagnostics on CAN (ISO 15765-4) und J1939-73 verbreitet (Bild 3). Um einen kostengünstigen Übergang auf WWH-OBD zu ermöglichen, wird vorerst weiterhin die Diagnose über CAN Kommunikations- Fahrzeugdiagnoseverwendet. Längerprotokoll standard J1939-Steuergerät fristig soll auch eine UDS OBD Applikation Diagnose über das ISO 14229 ISO 15031 Diagnose Internet-Protokoll ISO 15765 (DoIP) möglich sein. Transportprotokoll Der Zugang kann WWH-OBD J1939 CAN-Treiber dann sowohl drahtISO 27145 SAE J1939-73 Mikrocontroller gebunden über EtherCAN-Controller net als auch drahtlos CAN sein. Anders als der l Bild 3. Die On-Board-Diagnose bei Nutzfahrzeugen erfolgt über derzeitige Standard CAN-basierte Protokolle. OBD-II nutzt WWHOBD nur Dienste, ISO 27145. Darin sind die technischen die schon in der ISO 14229 Unified Rahmenbedingungen für WWH-OBD Diagnostic Services (UDS) festgelegt festgelegt. Die WWH-OBD zielt zu- sind (Tabelle 3). Es werden keine zunächst auf den Nutzfahrzeugmarkt, soll sätzlichen OBD-spezifischen Dienste aber später auf andere Fahrzeugberei- benötigt. Ab Anfang 2014 müssen alle neu che ausgedehnt werden. Die ISO 27145 besteht aus sechs zugelassenen schweren Nutzfahrzeuge Teilen (Tabelle 2). Die Dokumente die Euro-VI-Standards einhalten und befinden sich im Status Draft Inter- damit über WWH-OBD diagnosefähig national Standard (DIS), eine finale sein. Neu zu entwickelnde FahrzeugtyVersion ist für Ende 2011 absehbar. pen müssen die Standards bereits ein Im ersten Schritt wurden die Anfor- Jahr früher zum 1. 1. 2013 erfüllen. derungen an die Abgaskontrolle und Für die Implementierung der Diadie Diagnosekommunikation festge- gnosedienste von UDS ist von Vector Diagnosedienst

Diagnose-Identifier

UDS-Dienst

Spezifikation

Löschen des Fehlerspeichers

0x14

ClearDiagnosticInformation

ISO 15031 Mode 04

Auslesen des Fehlerspeichers sowie der Umgebungsdaten

0x19

ReadDTCInformation

ISO 15031 Mode 03, 07 und 02

Auslesen der Steuergerätedaten und der Testergebnisse

0x22

ReadDataByIdentifier

ISO 15031 Mode 01, 06 und 09

Ausführen von Routinen

0x31

RoutineControl

ISO 15031 Mode 08

Entwicklung + Test

die vielfach in Serie bewährte CANbedded-Kommunikations-Software inklusive Unterstützung für J1939 erhältlich. Seit kurzem ist auch eine serienreife AUTOSAR-Lösung für die Umsetzung der WWH-OBD-Diagnose via UDS verfügbar. sj Literatur + Links [1] http://standards.sae.org [2] CAN und offene Protokolle im Nutzfahrzeug. Elektronik automotive, Heft 5.2005. [3] SAE, J1939-11, Physical Layer, 250 kbits/s, Twisted Shielded Pair. [4] SAE, J1939-15, Reduced Physical Layer, 250 kbits/s, Unshielded Twisted Pair (UTP). [5] SAE, J1939-13, Off-Board Diagnostic Connector. [6] SAE, J1939-81, Network Management.

Dipl.-Ing. (FH) Peter Fellmeth ist Gruppenleiter und Produkt-Manager bei der Vector Informatik GmbH. Er verantwortet die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von J1939, Isobus, Ethernet und Car-to-x-Kommunikation. Er ist aktives Mitglied in verschiedenen Arbeitsgruppen zur Standardisierung der SAE J1939 und ISO 11783 (TC23/SC19/WG1). [email protected]

Dipl.-Ing. (FH) Holger Söhnle ist Produkt-Manager bei der Vector Informatik GmbH für Embedded Software im Themenumfeld von J1939 und Isobus. [email protected]

l Tabelle 3. Die WWH-OBD verwendet diese Diagnosedienste aus der UDS. www.elektroniknet.de

Elektronik automotive 12.2010 10/9

20

l

AUTOMOTIVE

9. 2 0 10

l

SYSTEME

SYSTEME

EINHEITLICHES DATENAUSTAUSCHFORMAT FÜR CAN

deten Komponenten wie sein Pendant aus den USA. Der europäische OEM bedient sich typischerweise einer eigenen Kette von festen Zulieferern, die individuell entwickelte oder stark angepasste Steuergeräte für ihn erstellen. Das komplette E/E-Design und teilweise auch der Entwicklungsprozess werden vom OEM vorgegeben und sind so ausgelegt, dass die einzelnen Komponenten in verschiedenen Baureihen, Marken oder Märkten eingesetzt werden können. Standards oder offene Protokolle werden nur dort benötigt, wo Schnittstellen nach außen bereitgestellt werden müssen, beispielsweise für die abgasrelevante Diagnose (OBD), das Flottenmanagement (FMS), Toll-Collect-Module (OBU) oder Anhänger (ISO11992). Dasselbe gilt auch, wenn Komponenten, z. B. der Motor, an andere Industrien wie Landtechnik oder Baumaschinen geliefert werden. Daraus resultiert, dass europäische OEMs J1939 in der Praxis meist mehr als „Werkzeugkoffer“ sehen und nur die Eigenschaften nutzen, die im aktuellen Fahrzeug gebraucht werden. Einem J1939-Konformitätstest würden die Implementierungen nicht genügen – aus Sicht der OEMs ist das aber kein Nachteil.

Integration von J1939-Systemen in der Praxis U m d i e Ve r b e s s e r u n g s m ö g l i c h ke i t e n b e i d e r J 1 9 3 9 - Ve r n e t z u n g z u e r ö r t e r n , h at d i e a m e r i k a n i s c h e To c h t e r d e r Ve c t o r I n fo r m at i k G m b H a u f A n re -

Standardsoftwarekomponenten reduzieren Entwicklungskosten Aus dem Vortrag von Ford [2] geht hervor, dass die Netzwerkarchitektur nicht als entscheidender Wettbewerbsvorteil gesehen wird. Vor diesem Hintergrund ist der Einsatz von standardisierten und weitgehend generierten Softwarekomponenten sinnvoll. So hat Ford mit der FNOSInitiative (Ford Network Operating System) im Automobilbereich die Idee aufgegriffen, eine Implementierung für alle Zulieferer zur Verfügung zu stellen. Damit konnten Qualitätsprobleme und ihre Ausbreitung auf ein Minimum reduziert werden. Die Gemeinsamkeit dieses Ansatzes mit

l

AUTOMOTIVE

9. 2 0 10

l 21

J1939 ist, dass FNOS für den Zulieferer wie ein Standard ist. Im Gegensatz zu FNOS wird J1939 aber von vielen unterschiedlich implementiert. Die Teilnehmer berichteten, dass dieser Umstand immer wieder zu Problemen bei der Integration führt. So können Botschaften nicht empfangen werden, da die verwendete Priorität beim Sender und Empfänger nicht übereinstimmt, bestimmte Adressen von Steuergeräten vorausgesetzt werden oder Signale nicht vollständig implementiert sind. Navistar [3] führt auf, dass auch der Austausch von Informationen zwischen OEM und Zulieferer, welche Signale zur Verfügung stehen, immer wieder eine Fehlerquelle hinsichtlich Aktualität und Vollständigkeit darstellt. Statt einen verfügbaren Quasi-Standard wie beispielsweise das DBC-Datenformat für die Beschreibung der CAN-Kommunikation zu nutzen werden häufig Textdokumente verwendet. Die Erfahrungen von Ford mit FNOS zeigen, dass eine Defacto-Kompatibilität die Verfügbarkeit von Produkten erhöht und den Aufwand für die Integration deutlich reduziert. Für einen OEM können sich Vorteile ergeben, wenn er die Referenzimplementierung für unterschiedliche Hardwareplattformen nicht selber entwickelt. Durch die Vergabe an ein darauf spezialisiertes Unternehmen – in diesem Fall Vector – konnten bis jetzt Einsparungen in einer Größenordung von 800.000 US-$ bei Ford erreicht werden. Vector CANtech [4] erörterte die Verwendung von Standardsoftwarekomponenten versus Eigenlösungen. Besonders der Einsatz von Off-the-shelf-Komponenten in Bereichen, die nicht wettbewerbsrelevant sind und auch typischerweise nicht zur Kernkompetenz gehören, bietet eine Reihe von Vorteilen. Zugekaufte und ggf. bereits zertifizierte Komponenten, wie die J1939 CAN-Kommunikationssoftware oder das Betriebssystem, führen zu mehr Sicherheit im Entwicklungsprozess und erhöhen die Inter-

g u n g vo n w i c h t i g e n a m e r i k a n i s c h e r L K W- H e rs t e l l e r z u e i n e r Ko n fe re n z e i n g e l a d e n . D a b e i s t e l l t e n ve rs c h i e d e n e Te i l n e h m e r i h re Ko n z e p t e u n d E r fa h r u n g e n b e i d e r I n t e g rat i o n vo n J 1 9 3 9 - Ko m p o n e n t e n vo r. Z u d e m w u r d e n S c h wa c h p u n k t e i d e n t i fi z i e r t u n d ko n k re t e O p t i m i e r u n g s p o t e n z i a l e diskutiert.

B

ei der Integration von vernetzten Systemen mit dem J1939-Protokoll werden Nutzfahrzeughersteller immer wieder mit Problemen konfrontiert. Schwachstellen sind unter anderem der Informationsaustausch zwischen OEM und Zulieferer oder die unterschiedliche Auslegung des J1939-Standards. Ansatzpunkte für eine Verbesserung sind ein einheitliches Datenaustauschformat für die CAN-Kommunikation, die Einführung eines Werkzeugs für den Konformitätstest oder die verbindliche Definition von Geräteprofilen. J1939 ist nicht gleich J1939 Dass dem Protokoll SAE J1939 im „Heimatland“ USA eine andere Bedeutung als in Europa zukommt, zeigte der Vortrag von Vector [1]. Dabei spielen gewachsene Marktstrukturen ebenso eine Rolle wie unterschiedliche techni-

10/10

sche Anforderungen. So ist zum Beispiel die Beziehung zwischen dem Kunden und dem OEM dahingehend unterschiedlich, dass ein US-Kunde nicht nur die Fahrzeugfunktionen auswählen kann. Der Kunde hat direkten Einfluss darauf, ob zum Beispiel das Bremsensteuergerät von Zulieferer A oder B verbaut wird. Deshalb müssen das E/EDesign und das verwendete Kommunikationsprotokoll möglichst flexibel sein und auf Standards aufsetzen. Typischerweise werden einzelne Komponenten herstellerübergreifend eingesetzt. Dadurch hat der US-OEM weniger Einfluss auf die Funktionalität und den Entwicklungsprozess der Komponentenhersteller. Die Rolle des OEM beschränkt sich oft auf die des Integrators. In Europa hingegen werden die Fahrzeuge in verschiedenen Varianten vom OEM angeboten. Der europäische Kunde hat also nicht die Wahlmöglichkeiten der verwen-

Bild 1: Durch Verwendung von Standardsoftwarekomponenten kann der Anteil der anwendungsspezifischen Software reduziert werden. © automotive

10/11

22

l

AUTOMOTIVE

9. 2 0 10

l

SYSTEME

operabilität. Auch die modellbasierte Entwicklung trägt zur Reduzierung von Fehlerquellen bei (Bild 1). J1939-Integration optimieren Wie ein solches Einsparpotenzial für alle US-NutzfahrzeugOEMs erschlossen werden kann, zeigt Navistar in seinem Vortrag [3]. Navistar sammelte im Rahmen seines „Blue Diamond Program“ Erfahrungen sowohl mit J1939 als auch mit FNOS. Es galt eine Ford-Kabine mit einem NavistarChassis zu verheiraten. Als Bindeglied zwischen der FNOSKabine und dem J1939-Chassis musste ein Gateway (Blue Diamond Gateway) entwickelt werden. Dabei zeigte sich, dass nicht einfach die Vorteile von FNOS eins zu eins auf J1939 angewandt werden können, dafür aber die Prinzipien. Navistar identifizierte eine Reihe von Punkten, die die J1939-Integration zukünftig verbessern können: ■ Die Beschreibung der Kommunikation soll mit einem herstellerübergreifenden Datenformat wie dem DBCFormat erfolgen. Damit lassen sich Inkompatibilitäten oder fehlende Signale automatisch erkennen (Bild 2). ■ Der OEM sollte mehr Einfluss auf die Anzahl der kommunizierten Parametergruppen und Signale erhalten. Potenziell kritische Latenzzeiten oder zu hohe Buslasten lassen sich so besser vermeiden oder ganz ausschließen. ■ Zulieferer können weiterhin eigene Kommunikationssoftware schreiben. Ein verbesserter Wissenstransfer über das Kommunikationsverhalten und die Möglich-

SYSTEME

keit zur Kontrolle der Kommunikation wird mit Hilfe einer DBC-Datenbank erreicht. ■ Austausch von Simulationsmodellen zwischen OEM und Zulieferer für alle Kommunikationsmodule ermöglicht Simulation und Test des gesamten Netzwerks. Diese Punkte hat Vector CANtech [5] unter den Gesichtspunkten Aufwand und Nutzen sowie Zeitschiene für die Einführung betrachtet. Besonders die Nutzung eines gemeinsamen, bereits vorhandenen Datenaustauschformats zwischen OEM und Zulieferer ist empfehlenswert, da der Aufwand gering ist und sich der Nutzen unmittelbar einstellt. Der Einsatz eines Konformitätstests liefert weitere Vorteile. Er unterstützt den Anwender an verschiedenen Stellen des Entwicklungsprozesses, z. B. bei der Implementierung, Verifikation sowie Systemintegration und verbessert sowohl die Qualität des Produktes als auch die Effektivität des Prozesses. Entwicklungswerkzeuge wie CANoe.J1939 von Vector unterstützen die automatische Generierung von Konformitätstests auf Basis von DBC-Datenbanken. Die kritischen Pfade der Entwicklung werden dadurch deutlich früher im Prozess behandelt und treten nicht erst bei der Systemintegration in Erscheinung (Bild 3). Fazit Die Konferenz zeigte, dass alle anwesenden US-amerikanischen OEMs an denselben Problemen arbeiten, wenn auch in unterschiedlicher Schärfe. Dies nährt die Hoffnung, dass die Punkte auch gemeinsam angegangen werden

l

AUTOMOTIVE

Bild 3: Verschiebung des Aufwands an den Anfang des Entwicklungsprozess reduziert Risiken und Integrationsaufwand.

können. Der naheliegendste und erfolgversprechendste Ansatz „Verwendung eines einheitlichen Datenaustauschformats für die CAN-Kommunikation“ kann mit geringem Aufwand erfolgen. Hier profitiert sowohl der OEM als auch der Zulieferer unmittelbar. Eine Referenzimplementierung oder ein offizielles Konformitätstest-Werkzeug könnte mit Hilfe der SAE definiert und umgesetzt werden. In diesem Rahmen könnten auch verbindliche Geräteprofile festgelegt werden. (oe) Literaturhinweise: [1] Fellmeth, P.; Vector Informatik GmbH: “E/E Development and J1939 in Europe, Overview about Current Status”. JEIM Congress 2010. [2] Paton, E.; Ford Motor Company: “Ford Network Operation System, The OEM Perspective”. JEIM Congress 2010.

9. 2 0 10

l 23

© automotive

[3] Venkateswaran, S.; Navistar, Inc: “Blending Automotive and Commercial Vehicle Network Technologies”. JEIM Congress 2010. [4] Stevens, S.; Vector CANtech, Inc.: “Evolution of Vehicle Embedded Software – COTs”. JEIM Congress 2010. [5] Craig, J.; Vector CANtech, Inc: ”In-Vehicle Network Development, Best Practices”. JEIM Congress 2010.

Dipl.-Ing. (FH) Peter Fellmeth ist Gruppenleiter und Produktmanager bei der Vector Informatik GmbH. Hier ist er verantwortlich für die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von J1939, ISOBUS, Ethernet und Car2x.

@

Vector Informatik www.vector.com

Bild 2: Gegenüberstellung der unterschiedlichen Entwicklungsmodelle (grün, blau) und eine mögliche Zusammenführung (rot). © automotive

10/12

10/13

Bussysteme

IIII CAN-Bus

CAN-Bus IIII

CAN und J1939 unter extremen Einsatzbedingungen Garantierte Funktion bei Kälte, Eis und Schnee

Der Einsatz von Elektronik wurde von Maschinenbauunternehmen als notwendiges Übel betrachtet. Für die vom Stahlbau kommende Firma Kässbohrer hat sich diese Sichtweise umgekehrt. Die Fahrzeug-Elektronik in einem „Pistenbully“ ist zuständig für Lenkung, Steuerung von Motor und Hydraulik, Bedienung der Anbaugeräte, Betriebsdatenerfassung und Telematik samt Fahrzeugnavigation mit GPS. Von Thomas Böck, Peter Betz, Markus Hörmann und Lothar Felbinger

I

m Gegensatz zu gewöhnlichen Nutzfahrzeugen besteht bei einem Pistenbully die technische Herausforderung darin, zahlreiche Extremsituationen auch bei Kälte, Schnee und im Nachteinsatz zu beherrschen. Die in allen Richtungen bis 45 Grad schräglagenfähige Ma-schine erreicht mit ihrer Multiflexfräse eine Flächenleistung von 96 000 m2/h. Die Technik ist ausgelegt für Einsätze bis 4000 m Höhe und extreme Außentemperaturen; die Polarausführung kann sogar in Höhen bis 6000 m eingesetzt werden. Elektronik automotive 5.2006 10/14

Die Zeiten für die Pistenpräparation sind häufig für die Abend- und Nachtstunden eingeplant, während die regulären Wintersportaktivitäten ruhen. Wenn die Fahrer bei Schneesturm oder Nebel in großen Höhen oder arktischen Regionen einsam unterwegs sind, kann die Zuverlässigkeit und Verfügbarkeit der Fahrzeuge lebenswichtig sein. Sicherheit sowie bequemes und ermüdungsfreies Steuern und Bedienen stehen daher ganz im Mittelpunkt des Fahrzeugkonzepts. Intelligente Automatikfunktionen unterstützen den Fahrer und reduzieren die Bedienvielfalt,

so dass er sich auf das Wesentliche konzentrieren kann. Durchschlagsichere Windschutzscheiben bewahren den Fahrer vor Steinschlag; ein Beleuchtungssystem mit zahlreichen Fahr-, Such- und Arbeitsscheinwerfern machen die Nacht zum Tag. Automatisches Einblenden einer Rückfahrkamera in das CockpitDisplay verschafft auch bei Rückwärtsfahrt optimale Sicht. Zur Unterstützung der Präparation in Steillagen werden die Fahrzeuge bei Bedarf mit elektrohydraulischen Seilwinden ausgestattet, die 1000 m Seil mitführen. Eine Besonderheit: Die Winde ist drehbar gelagert, das Fahrzeug darf sich dabei beliebig oft um 360 Grad drehen. Neben den Modellen für Gebirge und Schnee und gibt es Pistenbully-Varianten ohne Ladefläche, nur für Personentransport, Baggerausführungen und sogar schwimmfähige Maschinen. Etwa 600 bis 620 Einheiten stellt Kässbohrer [1] pro Jahr her, ein Fahrzeug kostet zwischen 80 000 und 340 000 Euro.

 Ausgangspunkt: ein leistungsfähiges Aggregat Als Antrieb kommen Motoren von Mercedes-Benz mit Leistungen zwischen 90 PS und 460 PS zum Einsatz. So ist der „Pistenbully 600“ mit einer 12,8-Liter-Maschine mit 295 kW (400 PS) ausgerüstet; diese liefert Drehmomente bis 1900 Nm. Zwei voneinander getrennte hydrostatische Antriebskreise ohne Trennkupplung sind für den rechten und linken Fahrantrieb verantwortlich. Die Motorsteuerung sorgt für das nötige Motormoment beim Anfahren und verhindert ein Abwürgen. Gleichzeitig bietet eine Grenzlastregelung Schutz gegen Überlastung und Überdrehen des Dieselmotors. Zum Fahren bzw. Verzögern (Bremsen) dient ein einziges Fahrpedal, d.h.

es gibt keine Betriebsbremse, sondern lediglich eine Feststellbremse. Fahrtrichtungsänderungen werden durch eine Differenz zwischen den Kettengeschwindigkeiten erreicht. Jeder Antrieb ist in seiner Ausgangsdrehzahl stufenlos verstellbar und in der Drehrichtung umkehrbar, so dass die vollelektronische Lenkung unter anderem Drehen/Wenden auf der Stelle, Fahrtrichtungsvorwahl und Geschwindigkeitsreduzierung unterstützt. Die „Lenkaggressivität“ variiert mit der Fahrgeschwindigkeit, der Fahrer kann sie auf seine Bedürfnisse einstellen. Damit bleiben Veränderungen der Fahrgeschwindigkeit durch Fahrpedal oder Lastbegrenzungsregler ohne Einfluss auf den Lenkradius. Radsensoren ermöglichen eine Geradeaus- und Kurvengleichlaufregelung oder asymmetrische Lenkkennlinien für Sondereinsätze.

künftige Funktionen reserviert, die derzeit noch nicht gebraucht werden. Daneben kommt CAN für SoftwareUpdates, zur Parametrierung und für Messsysteme zum Einsatz. Da sich derzeit alle Funktionen mit CAN realisieren lassen, ist die Verwendung von neueren Kommunkationssystemen wie FlexRay, LIN oder MOST nicht im Gespräch. Die Elektrik ist vollkommen modular aufgebaut und über alle Fahrzeugvarianten vereinheitlicht. Die Grundverkabelung berücksichtigt alle aktuellen und künftigen Optionen; Erweiterungen und Nachrüstungen lassen sich durch Adapterkabelsätze einfach bewerkstelligen.

Für die zentrale Steuerung aller Funktionen wie Leistungs- und Energiemanagement, Motorsteuerung, Hydraulik der Fahr- und Fräspumpen, ÖlmengenVerteilung für die Front- und Heckhydraulik sowie die Überwachung aller Sensoren und Aktoren ist das Pistenbully-Universal-Steuergerät PSX verantwortlich. Es wird ergänzt durch die „Zentral-Elektronik“, auf der neben zahlreichen diagnosefähigen und kurzschlussfesten Ein-/Ausgängen z.B. Zentralverriegelung, Funkfernsteuerung, Beleuchtungssteuerung und Spannungswandler für 12 V untergebracht sind. Die volllastfähige Einheit liefert einen Summendauerstrom von 640 A bei 24 V und erreicht damit eine Schaltleistung von bis zu 15 kW. Die „Zentral-Elektronik“ hat Anbindungen zu allen fünf CAN-Bussen. Insgesamt sind nur acht

Erst durch die konsequente Vernetzung des Fahrzeuges mit CAN wurde eine dezentrale Steuerungsstruktur ermöglicht (Bild 1). Elektronische und mechanische Komponenten konnten sinnvoll in einem Steuergerät kombiniert werden. Dadurch wurde im Vergleich zu früheren Pistenbully-Generationen der Verkabelungsaufwand signifikant reduziert. Nahezu die gesamte Kommunikation führt über die zwei Hauptbusse CAN 1 und CAN 2 der insgesamt fünf CAN-Bus-Stränge. Während CAN 3 beim Flottenmanagement zur externen Kommunikation dient, sind die technisch einsatzbereiten Systeme CAN 4 und CAN 5 für

MultifunktionsJoystick

Bedienpanel

Heizungsregler

Telemetrie

CAN 1 (KGF intern) Terminal Laptop

UniversalSteuergerät PSX

Kamera Kamera

BandendeProgrammierung

Terminal Control Center TCC

Lenksäule

Winde

ZentralElektronik

CANInstrumente

CAN 2 (J1939) Motor

CANVentile

Fronthydraulik

„richtige“ Sicherungen notwendig, alles andere wurde über Leistungselektronik kurzschlusssicher und „selbstheilend“ ohne Relais verwirklicht.

Komfortabel und intuitiv manövrieren Am internen Fahrzeugbus (CAN 1) hängen u.a. die Bedien- und AnzeigeElemente des Cockpits (Bild 2). Dazu gehören neben einem ergonomischen Halblenkrad ein Display mit berührungsempfindlichem Bildschirm, CANRundinstrumente, das in der Armlehne

Viel Leistungs-Elektronik, wenig Sicherungen, keine Relais

Konsequente Vernetzung mit CAN

LenkJoystick

Bussysteme

LüfterSteuergerät

I Bild 1. Übersicht der CAN-Netzwerke im aktuellen Pistenbully.

(Bild: Kässbohrer)

integrierte Terminal Control Center (TCC) und ein Joystick mit programmierbaren Funktionsknöpfen. Das Display informiert über die wichtigsten Betriebszustände wie Fahrgeschwindigkeit, Winden-Zugkraft, Motordaten usw. Es erlaubt eine intuitive Bedienung wahlweise am Bildschirm oder mit dem TCC. Über das rechts vom Fahrer angeordnete Bedienpanel mit Folientastatur lassen sich die zahlreichen Funktionen des Pistenbullys direkt anwählen. Per Joystick werden die verschiedenen Bewegungen des Räumschilds und des hinteren Geräteträgers gesteuert bzw. der Fräsendruck und die Winden-Zugkraft eingestellt. Der Joystick ist eine Eigenentwicklung: Keines der auf dem Markt verfügbares Modell entsprach den Anforderungen der Pistenbully-Entwickler.

CAN 4 CAN 5 CAN 3

Heckhydraulik

I Bild 2. Bedien- und Anzeige-Elemente im Pistenbully-Cockpit.

Flottenmanagement (Quelle: Kässbohrer)

CAN steuert Hydraulikmodul CAN 2 wird als Sensor-Aktor-Bus für Motorsteuerung, Ventilsteuerung und die Anbindung der Sensoren eingesetzt. Die Hydraulikventile werden vollständig über CAN angesteuert,

Erschienen in Automobil Elektronik, 8/2011

www.elektroniknet.de 10/15

Bussysteme

IIII CAN-Bus

CAN-Bus IIII

Während Kässbohrer bei dem Funktionsbus CAN 1 das hausinterne Protokoll KGF einsetzt, findet beim Antrieb auf CAN 2 das J1939-Protokoll Verwendung. Ein standardisiertes Antriebsmanagement auf Basis von SAE J1939 hat hier den Vorteil, dass sich das Antriebssystem herstellerunabhängig mit Komponenten von Fremdanbietern aufbauen lässt, einschließlich eines entsprechenden Diagnosesystems. Auf der Funktionsseite wird bewusst das proprietäre Protokoll eingesetzt, um Manipulationen zu verhindern und gleichzeitig das Know-how zu schützen. Aus diesem Grunde wurde auch auf den Standard CCP (CAN Calibration Protocol) für die Steuergerä-te-Applikation verzichtet. Die CAN-Bussysteme lassen sich per Laptop parametrieren und diagnostizieren.

Auch bei Busausfall sicher ins Tal I Bild 3. CANoe als Joystick-Simulator für den Test von Hydraulikventilen.

d.h. ohne zusätzliche analoge oder digitale I/O-Signale. So genannte Mehrfachmodule stellen auf der Seite des Sensor-/Aktor-Busses Eingangskanäle, Digitalausgänge, PWM-Ausgänge und Brückenausgänge zur Verfügung; diese sind ebenfalls di-

I Bild 4. CANoe im Flashmodus. Elektronik automotive 5.2006 10/16

(Bild: Kässbohrer)

agnosefähig, kurzschlussfest und selbstheilend.DieSensorenwerdensämtlich über 4-bis-20-mA-Stromschnittstellen angeschlossen, um Übergangswiderstände bei korrodierenden elektrischen Verbindungen zu kompensieren.

(Bild: Vector Informatik)

Beim Pistenbully kommen schon seit den 1970er Jahren X-by-Wire-Systeme in der Serie zur Anwendung, deren Einsatz im öffentlichen Straßenverkehr erst Jahrzehnte später zum Thema wurde. Bei reinen Offroad-Fahrzeugen ohne Straßenzulassung gelten andere rechtliche Grundlagen für Betrieb und Sicherheit, da diese ausschließlich auf Privatgrund eingesetzt werden. Fallen Lenkpotentiometer, Fahrtrichtungstaster und/oder das redundante, berührungslos arbeitende Fahrpedal aus, bleibt die Fahrfähigkeit solange wie möglich erhalten. Die zwischen 7 und 10 t schweren und maximal 23 km/h schnellen Fahrzeuge lassen sich dann über die Notlaufeigenschaften mit einer gedrosselten Geschwindigkeit von 5 km/h sicher ins Tal lenken. Selbst bei einem Ausfall beider CAN-Busse bleibt der Pistenbully manövrierfähig – er wird dann über PWM-Signale gesteuert. An die Elektronik werden dabei besondere Anforderungen gestellt: Diese muss widrigen Temperatur- und Feuchtigkeitsbedingungen widerstehen, erhebliche mechanische Belastungen aushalten und gegenüber elektromagnetischen Störungen unempfindlich sein. So dürfen hohe Feldstärken von Funksendern auf den Berggipfeln die Fahrzeugfunktionen in keinem Fall beeinträchtigen. www.elektroniknet.de

Bussysteme

 Von der Simulation zur realen Elektronik Software-Entwicklung und Fahrzeugapplikation – darunter versteht man die Anpassung von FahrzeugParametern an die Gegebenheiten – einschließlich aller Regelmodule finden komplett im Hause Kässbohrer statt. Damit ist der Hersteller in der Lage, die Fahrzeuge an neue Einsatzsituationen anzupassen. Da die Komplexität der Software und der elektronischen Funktionen stetig ansteigt, sind die Entwickler bei einem Projekt wie dem Pistenbully auf leistungsfähige Tools angewiesen, auch was die Software betrifft. Entlang des Entwicklungsprozesses sind Design, begleitende Tests und Simulationen von Teil- oder von Gesamtsystemen unverzichtbar. Hier kommt CANoe mit der Option J1939 von Vector Informatik [2] zum Einsatz. Die Möglichkeiten von CANoe als Entwicklungs- und Simulationswerkzeug reichen von der Simulation eines einzigen Netzknotens, über Test und Diagnose bis zur Darstellung vollständiger CAN-Netzwerke. Mit den ersten Untersuchungen am rein virtuellen Modell beginnend, lassen sich im weiteren Verlauf der Entwicklung die virtuellen Knoten Schritt für Schritt durch reale Hardware ersetzen. Die Fahrzeugfunktionen werden in diesem Fall von einem virtuellen Steuergerät mit einer OSEKEmulation ausgeführt. Es erlaubt unter anderem die Ansteuerung bzw. Zustandsanzeige virtueller Sensoren und Aktoren. Entsprechende Panels können automatisch generiert werden.

Kurze Entwicklungszeiten Bei Kässbohrer dient CANoe u.a. auch zum Simulieren von Buslasten, als Messwerkzeug und zum Parametrieren von Steuergeräten über das eigene KGF-Protokoll (Bild 3). Die Entwickler generieren damit z.B. Diagnose- und Setup-Informationen bei Temperatur-, EMV- und Reaktionstests von Ventilsteuerungen und sind in der Lage, die Lösungen für die Seriengeräte schlank zu halten. Die Entwicklung der zweikanaligen Lüftersteuerung des Pistenbullys war ohne Einsatz realer Hydraulik-Pumpen, Ventile und Motoren in bemerkenswert www.elektroniknet.de

I Bild 5. CANoe bei der Messdatenerfassung während der Erprobung.

kurzer Zeit möglich. CANoe hat dazu alle nötigen CAN-Knoten, Sensorsignale oder Steuergeräte-Informationen realitätsnah simuliert. Beim Steuergeräte-Setup erlaubt CANoe den Zugriff auf EEPROM-Inhalte über ein eigenes Flash-Protokoll. Über die in-

(Bild: Vector Informatik)

tegrierte Programmiersprache CAPL (Communication Access Programming Language) kann dies einfach nachprogrammiert werden. Die auf Festplatte gespeicherten EEPROM-Daten können jederzeit in den Controller geladen werden (Bild 4).

Hintergrund SAE J1939 Das Protokoll SAE J1939 wurde 1998 von der SAE (Society of Automotive Engineers) veröffentlicht. Es basiert auf dem bekannten CAN-Bussystem und wurde hauptsächlich für den Einsatz in Nutz- und Spezialfahrzeugen konzipiert. SAE J1939 dient zur Kommunikation zwischen elektronischen Steuergeräten und bildet die Grundlage für verschiedene internationale Standards in den Bereichen LkW und Anhänger (ISO 11992), Forst- und Landmaschinen (ISO 11783) oder Marine-Anwendungen (NMEA 2000). Die einzelnen Teile der Spezifikation regeln die Übertragungsart der Nachrichten, deren Inhalt und Aufbau sowie ggf. deren Segmentierung: } J1939/11 Physical Layer (shielded twisted pair) } J1939/12 Physical Layer (twisted quad of wires) } J1939/13 Off-Board Diagnostic

Connector } J1939/15 Reduced Physical Layer (250 kbit/s, unshielded twisted pair) } J1939/21 Data Link Layer } J1939/31 Network Layer } J1939/71 Vehicle Application Layer } J1939/73 Application Layer Diagnostics } J1939/81 Network Management Einen Überblick über J1939-konforme Produkte findet man bei der Nutzerorganisation CiA (CAN in Information, www.can-cia.org). Der seit kurzem verfügbare J1939-Produktkatalog ermöglicht Entwicklern und Einkäufern schnellen Zugriff auf entsprechende Bausteine und Entwicklungswerkzeuge. Diese Dienstleistung ist für J1939 bisher einzigartig und hat sich, laut CiA, schon in den Bereichen CAN bzw. CANopen bewährt. sj

Elektronik automotive 5.2006 10/17

Bussysteme

IIII CAN-Bus

I Bild 6. Einfache Fehlerlokalisierung für den Fahrer mit „On Board“-Diagnose (OBD).

Unverzichtbar: Echtzeitfähige Entwicklungs-Tools Die Echtzeit-Fähigkeit der Entwicklungs-Tools ist bei Analyse und Test von CAN-Systemen ein wichtiges Kriterium. Diese Erfahrung machten auch die Pistenbully-Entwickler: Erst nach längeren Fehlersuchen stellte sich heraus, dass ein anderes Tool hinsichtlich der Abtastrate nicht mit den Anforderungen mithalten konnte

Dipl.-Ing. (FH) Markus Hörmann studierte Nachrichtentechnik an der FH in Kempten. Er leitet den Bereich Versuch Elektronik mit Prüfmittelbau der Kässbohrer Geländefahrzeug AG. [email protected]

(Bild: Kässbohrer)

und dadurch fehlerhafte Ergebnisse lieferte. Häufig benötigte Bedienoberflächen, Panels und andere Tools werden von Kässbohrer in der Regel mit Hilfe von Borland-C++ selbst programmiert. Auch bei solchen Eigenentwicklungen fungieren die CANoeDatenbasen stets als Grundlage. CANoe ermöglicht darüber hinaus eine optimale Zusammenarbeit mit Zulieferern, indem man vorab testen kann, wie

Dipl.-Ing. (FH) Peter Betz studierte Nachrichtentechnik an der FH in Ulm. Er ist im Bereich Entwicklung Elektronik der Kässbohrer Geländefahrzeug AG verantwortlich für Systementwicklung. [email protected]

sich Baugruppen verhalten. Allerdings liefern nicht alle Systemlieferanten CANoe-Simulationen ihrer Produkte bzw. stellen diese vorab zur Verfügung. Ein weiterer wichtiger Aspekt ist die Mobilität der Tools. Da sich die Schneeverhältnisse ständig ändern, wird die Feinabstimmung im Antriebssystem häufig vor Ort auf den Bergen vorgenommen. Wenn es gilt, Regelkreise für die verschiedenen Arten der Pistenpräparation zu perfektionieren und an örtliche Gegebenheiten anzupassen, macht sich CANoe auf dem Laptop als effizientes mobiles Diagnose- und Mess-Labor bezahlt (Bild 5). Das Fahrzeug lässt sich über einen an die CAN-Diagnosesteckdose angeschlossenen Programmier-PC vollständig und jederzeit parametrieren. Für jeden Pistenbully existiert eine elektronische Fahrzeugakte, die eine lückenlose Dokumentation von Software-Updates, der Lebensdauer einzelner Komponenten, aktueller SoftwareStände usw. erlaubt. Es ist jederzeit möglich, den Auslieferungszustand wieder herzustellen. Treten Probleme beim Kunden auf, erlaubt die „On Board“-Diagnose eine schnelle, komfortable Fehlerlokalisation über das Cockpit-Display (Bild 6). Alle Hydraulik-Funktionen, Sensoren und Aktoren sind elektronisch diagnosefähig ausgeführt. Für die Fehlersuche im Fahrzeug reichen Schaltplan und Display, weitere Hilfsmittel werden nicht benötigt. Im Fehlerspeicher sind Fehlerhistorie und Fehlerhäufigkeiten abgelegt. jw

Internet Links [1] Kässbohrer Geländefahrzeug AG – www.pistenbully.com [2] Vector Informatik GmbH – www.vector-informatik.com

Dipl.-Ing. (FH) Thomas Böck studierte allgemeine Elektrotechnik an der FH in Kempten. Er leitet bei der Kässbohrer Geländefahrzeug AG die Entwicklung Elektronik/ Hydraulik. [email protected]

Elektronik automotive 5.2006 10/18

Dipl.-Ing. (FH) Lothar Felbinger studierte Automatisierungstechnik an der FH Reutlingen. Mittlerweile arbeitet er als Key Account und Business Development Manager bei der Vector Informatik GmbH im Bereich der Produktlinie Open Networking. [email protected]

www.elektroniknet.de

76

l

A U T O M O T I V E -SPECIAL 9. 2 0 0 8

A U T O M O T I V E -SPECIAL 9. 2 0 0 8

l 77

Bild 1: Der MAN Common Engineering Data Backbone. © automotive

ERFOLGSFAKTOREN BEI DER ELEKTRONIKENTWICKLUNG

Entwicklungstrends

in der Nfz-Vernetzung

D i e S t e u e rg e r ä t eve r n e t z u n g i m N u t z fa h r z e u g i s t vo n d e n s e l b e n H e ra u s fo rd e r u n g e n g e p r ä g t w i e i m P k w. E rs c h we re n d ko m m t d i e h o h e Va r i a n t e n z a h l b e i g e r i n g e re n S t ü ck z a h l e n h i n z u , s ow i e l ä n g e re P ro d u k t l e b e n s z y k l e n , d i e e i n e e n t s p re c h e n d e Au s l e g u n g d e r A rc h i t e k t u r e r fo rd e r n . U m d e m Ko s t e n d r u ck z u b e g e g n e n u n d z u ve r l ä s s i g e Fa h r z e u g e a u f d i e S t ra ß e z u s c h i cke n , s i n d s p e z i e l l a n g e p a s s t e E n t w i ck l u n g s m e t h o d e n u n e r l ä s s l i c h .

D

ie besonderen Herausforderungen für die NfzHersteller sind die im Vergleich zum Pkw relativ hohe Variantenvielfalt bei deutlich geringeren Stückzahlen. Die gleichzeitige Verwendung elektronischer Steuergeräte über verschiedene Marken hinweg sowie die Integrationen von standardisierten Komponenten reduzieren zwar den Kostendruck, machen aber das Design der Elektronik und der Software komplexer. Betrachtet man die Lösungsansätze verschiedener NfzHersteller, so wird schnell klar, dass es die eine universelle Lösung nicht gibt. Aus der Vogelperspektive zeichnen sich aber klare Trends wie beispielsweise der Einsatz von Standards, Codegeneratoren und eine durchgängige Werkzeugkette klar ab. Die Anzahl der Steuergeräte wird eher

10/20

moderat zunehmen, wohingegen die rein in Software realisierten Funktionen weiterhin stark wachsen. Gemeinsamer Ansatzpunkt aller Lösungen ist der Einsatz einer umfassenden und durchgehenden Werkzeugkette – von der Anforderung bis zur Validierung. Im Mittelpunkt der Werkzeugkette sollte deshalb eine Datenbank mit Autorentools stehen. Sowohl die Datenbank als auch das Autorentool sind spezifisch an die Anforderungen des Fahrzeugherstellers anzupassen. So berücksichtigen die Werkzeuge neben den rein technischen Aspekten auch den individuellen Entwicklungsprozess der Unternehmen. Variantenmanagement, Konfigurationsmanagement oder auch die Einhaltung von Workflows sind in den Werkzeugen abgebildet. Müssen externe Zulieferer mit

eingebunden werden, kommen meist Standards oder Defacto-Industriestandards, wie das CANdb++ Datenformat der Vector Informatik, als Datenaustauschformat zum Einsatz. Teilweise gibt der Fahrzeughersteller seinen Zulieferern aber auch die Nutzung bestimmter Werkzeuge vor. Diese sind dann sehr eng an die Datenbank angekoppelt und unterstützen die Zulieferer insbesondere bei Aspekten wie Kompatibilität zu den Anforderungen, Qualität und Effizienz. Beispiel dafür sind Codegeneratoren für eingebettete Systeme oder Werkzeuge zum Testen wie etwa das Entwicklungs- und Test-Tool CANoe.J1939 von Vector. Das Systemdesign wird aufgrund steigender Anforderungen an die Vernetzung immer komplexer. Einzelne Steuergeräte werden in verschiedenen Plattformen und Ländern verbaut, wodurch sich die Variantenvielfalt erhöht. Dies erfordert Flexibilität in den Kommunikationsstrukturen und bei der Abbildung von Funktionen auf Steuergeräte. Nicht nur die verfügbaren Signale sind davon betroffen, sondern auch der Einsatz von Kommunikationsprotokollen. So werden in Europa häufig proprietäre Kommunikationsprotokolle, ähnlich zum Pkw, eingesetzt, wohingegen im nordamerikanischen Markt für schwere Lkw das Protokoll nach SAE J1939 dominiert. Bei der Fahrzeugdiagnose gibt es ebenfalls Unterschiede: In Europa wird die OBD-Diagnose nach UDS (ISO15765) und in den USA nach SAE J1939-73 umgesetzt. Mit unterschiedlichen Ansätzen zum Ziel Der Ansatz der MAN Nutzfahrzeuge AG basiert auf dem Einsatz einer integrierten Entwicklungsdatenbank als „Common Engineering Data Backbone“. Von dieser Plattform ausgehend werden alle fahrzeugspezifischen Funktionen entwickelt und Informationen hinterlegt. Die eASEE Tool Suite von Vector dient mit 8 Domänen als durchgängige Entwicklungsdatenbank und wurde speziell für die Anforderungen bei MAN im Rahmen eines Konfigurations-

prozesses individuell angepasst (Bild 1). Sie dient sowohl der Funktionsentwicklung als auch der Beschreibung der Kommunikationsmatrix. Da MAN bei der Kommunikation soweit wie möglich auf den SAE-Standard J1939 aufsetzt, wurde eASEE an die Anforderungen des J1939-Protokolls angepasst. Ein speziell für MAN entwickeltes und an das Data Backbone angepasstes Modul schlägt die Brücke zwischen der Modellierung in eASEE und der automatischen Codegenerierung für die Steuergeräte (Bild 2). Bei der Codegenerierung setzt der Münchner Nutzfahrzeughersteller auf die bewährten CANbedded.J1939 Standard-Softwarekomponenten von Vector. CANbedded.J1939 bekommt alle für die Konfiguration und Codegenerierung notwendigen Informationen direkt aus der Datenbank und kann ohne manuelle Eingriffe direkt den Embedded Code erzeugen. Damit lassen sich Änderungen in der Modellierung sofort in den Steuergerätecode übernehmen. Dieses Vorgehen schließt Fehler wie die falsche Konfiguration des Codegenerierungswerkzeugs aus und gewährleistet eine fehlerfreie und vollständige Codegenerierung. Zudem ist die Verifikation des Gesamtsystems einfacher, da Teile der Software bereits überprüft wurden. Eine Weiterverwendung der Kommunikationsdaten für Analysewerkzeuge wie den CANalyzer.J1939 oder Testwerkzeuge wie CANoe.J1939 von Vector ist möglich und unterstützt die Entwicklung der Anwendungsschichten. Die Volvo Truck Corporation wählte einen Lösungsansatz für die Softwareentwicklung, der sich zur Zeit auch im KfzUmfeld etabliert: die Verwendung von AUTOSAR und darauf aufsetzender Werkzeuge (Bild 3). Die Vorteile des Vorgehens liegen im Einsatz von standardisierten und bewährten Tools. Das bietet bei einer stark markenübergreifenden und auf viele Standorte verteilten Entwicklung Vorteile. Ein gemeinsames Verständnis für die grundlegenden Softwarestrukturen und die Architektur ist schnell erreicht. Die Einbindung von Zulieferern ist einfacher und Werkzeu10/21

78

l

A U T O M O T I V E -SPECIAL 9. 2 0 0 8

Bild 2: Basierend auf der Beschreibung der Elektronikstruktur im Funktionsdatenmanagement von eASEE erfolgt die Codegenerierung für die Steuergeräte. © automotive

Bild 3: Einsatz von standardisierten Datenformaten ermöglicht die Verwendung von Standardprodukten für die Beschreibung und Erstellung der Steuergerätesoftware (alle Bilder Vector Informatik). © automotive

ge müssen nicht zwingend vorgegeben werden. Damit reduziert sich die Abhängigkeit von einzelnen Tool-Herstellern und Zulieferern. Problematisch bei diesem Ansatz ist die Verwendung von Kommunikationsmethoden, die sich mit den Eigenschaften von AUTOSAR nicht oder nur proprietär darstellen lassen. Insbesondere der Einsatz von J1939 ist hierbei zu nennen. Geht AUTOSAR im Grundsatz von einem Netzwerk mit bekannten Teilnehmern und damit von einer zum Integrationszeitpunkt bekannten Kommunikationsmatrix aus, so ist dies gerade bei der J1939 mit seinem Plug&Play-Konzept nicht der Fall. Dieser Herausforderung begegnet Volvo Trucks zweigleisig. Zum einen wurden die Teile von J1939, welche in Volvo-Fahrzeugen verwendet werden, identifiziert und in die bestehende Vector AUTOSAR-Toolkette integriert. Zum anderen verfolgt Volvo, zusammen mit Vector und anderen europäischen Nfz-Herstellern die Aufnahme des J1939-Protokolls in Teilen in AUTOSAR. Dies ermöglicht Volvo, die Vorteile von AUTOSAR unmittelbar und durchgängig zu nutzen. Auf der anderen Seite erlaubt die AUTOSAR-Integration von J1939

10/22

grundsätzlich die Unabhängigkeit bei der Wahl der Werkzeuge. Volvo hat sich dabei für Vector als Lieferant der Werkzeuge und Embedded Softwarekomponenten entschieden, da Vector in allen Bereichen bereits Lösungen anbietet und diese sehr flexibel auf Volvo-spezifische Anforderungen anpassen konnte.(la) Literatur: [1] J. Svensson, „The Use of AUTOSAR in Volvo Group“, Vortrag auf dem Vector J1939 User Day, Download der Folien unter www.vector-informatik.de/j1939ud

Dipl.-Ing. (FH) Peter Fellmeth ist Teamleiter und Produktmanager bei der Vector Informatik GmbH. Er ist dort für die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von J1939, ISOBUS, Ethernet und DeviceNet verantwortlich.

@

Vector Informatik www.vector-informatik.com

Konformitätstest IIII

Entwicklung + Test

Drahtlose Analyse in einer CAN-Multiprotokoll-Umgebung Case Study BOMAG GmbH

Der Kunde

Die Vorteile

Die BOMAG GmbH ist Weltmarktführer auf dem Gebiet

Zuverlässige Netzwerkanalyse über WLAN und Ethernet

der Verdichtungstechnik. Das zur FAYAT Gruppe gehörende

Die Lösung bietet wichtige Vorteile gegenüber den Mög-

Unternehmen produziert im Stammwerk Boppard pro Jahr

lichkeiten einer einfachen CAN/WLAN-Bridge: > Als Host genügt ein WLAN-fähiges Laptop/Notebook,

rund 30.000 Maschinen für die Erd-, Asphalt- und Müllverdichtung sowie Stabilisierer/Recycler. Ein Großteil des Know-

das über Standard-Bordmittel und WLAN die

how ist heute in der Elektronik verankert.

Verbindung hält.

Gesicherte Kompatibilität

L

> Der für die Umsetzung von CAN auf WLAN verantwortDie Herausforderung

liche „Tastkopf“ am Prüfling sendet die Botschaften

Aufzeichnen der Kommunikation verschiedener Fahrzeug-

streng in der chronologisch richtigen Reihenfolge, indem er

busse aus der Distanz

die ursprünglich auf dem Bus festgehaltenen Zeitstempel

Bei der Elektronikentwicklung von modernen Baumaschinen

berücksichtigt. Über eine CAN-WLAN-CAN-Bridge wäre

lässt sich auf Prüfständen bereits ein großer Teil sinnvoll testen und simulieren. Im fortgeschrittenen Entwicklungsstadium jedoch finden Tests und Probeläufe vorzugsweise unter Realbedingungen auf Baustellen oder Testgeländen statt. Bisher war eine zeitgleiche Analyse der Messdaten

dies nicht möglich. > Während des Betriebs auf der Baustelle können die BOMAG-Elektronikentwickler nun ohne Kabelverbindung zur Maschine messen, beobachten und auswerten. > Multibus-Einsatz und ein gleichzeitiger Einsatz der

während der Feldtests für die BOMAG-Elektronikentwick-

höheren Protokolle J1939 und CANopen auf demselben

ler nicht möglich, ohne selbst auf der Maschine mitfahren

Bus sind möglich.

zu müssen. Sie konnten nur im Nachhinein die aufgezeichneten Daten mit dem CANalyzer untersuchen.

> Die für BOMAG individuell entwickelte Remote-CANAnalyse ist in der Zwischenzeit fester Bestandteil von CANoe/CANalyzer .Ethernet.

Die Lösung Drahtloser Empfang und Versand der CAN-Botschaften von schwer zugänglichen oder mobilen CAN-Bussystemen Bisher war für die Arbeit mit CANalyzer und CANoe ein physikalischer Kontakt mit dem zu analysierenden Bussystem zwingend notwendig. Mit der CANoe/CANalyzer Option .Ethernet kann über WLAN mit dem Prüfling Kontakt aufgebaut werden. Die CAN-Botschaften werden samt Zeitstempel über eine TCP/IP-Verbindung getunnelt, so dass die mit den Botschaften bereitgestellten Zeitstempel

V2.0 | 2009-07

als Referenzzeit für CANoe und CANalyzer dienen.

ängst hat in der Agrartechnik das Informationszeitalter Einzug gehalten, und das Systemdenken hat die Insellösungen abgelöst. Eine einheitliche Datenschnittstelle für die Verbindung von Traktor, Anbaugeräten und BordComputer ist daher aus der Landwirtschaft nicht mehr wegzudenken. Vor diesem Hintergrund wurde mit Isobus ein international abgestimmtes Bussystem entwickelt und erstmals auf der Agritechnica 2001 vorgestellt. Isobus standardisiert die Datenkommunikation zwischen Traktor und Anbaugerät bzw. Farm-Management-Computer und ermöglicht einen systemweiten Datenaustausch. Die Normenreihe ISO 11783 besteht aus 14 Teil-Normen, die sich mit verschiedenen Aspekten der Technologie auseinandersetzen, von der Systembeschreibung (Teil 1) über Physical Layer (Teil 2), Data Link Layer (Teil 3), Network Layer (Teil 4) und Virtual Terminal (Teil 6) bis hin zur Diagnose (Teil 12) und File Server (Teil 13). „Des einen Freud, des anderen Leid“ heißt es im Volksmund. Mit dem Anspruch der system- und herstellerunabhängigen Kompatibilität von ISO11783-kompatiblen Produkten [1] verhält es sich in etwa ebenfalls so. Für den Kunden ist es nicht nur sehr bequem in der Handhabung, sondern eröffnet ihm auch die Möglichkeit, herstellerunabhängig und damit flexibel einzukaufen. Das stellt nicht zuletzt einen großen

www.elektroniknet.de 10/24

Vector Informatik GmbH | Stuttgart · Braunschweig · Hamburg · Karlsruhe · München · Regensburg | www.vector.com

Automatische Interoperabilitätstests für ISO-11783-Systeme Die geforderte uneingeschränkte Kompatibilität der Komponenten am Isobus kann nicht allein mit der Durchführung des Konformitätstests am Ende der Geräteentwicklung erreicht werden. Vielmehr sind „Plug-Feste“ und fortlaufende Tests während der gesamten Entwicklung notwendig. Solche Prüfungen können effizient nur durch Werkzeuge mit Domänenwissen erfolgen, die eine Vielzahl von Aufgaben abdecken – von der Simulation über die Analyse bis hin zu Konformitätstests. Entwickler von Anbaugeräten und Traktoren benötigen ein Werkzeug, das den Konformitätstest abdeckt, diesen selbstständig durchläuft, es aber auch ermög-licht, nur Teile zu prüfen und sich darüber hinaus auch auf den Test der Anwendung ausdehnen lässt. Von Peter Fellmeth

Motivationsfaktor für die Anschaffung solcher Arbeitsmaschinen dar. Für die Hersteller ist dieses Versprechen hingegen eine große Herausforderung in Bezug auf Entwicklung, Betrieb und Wartung der Arbeitsmaschinen. CANoe.ISO11783 von Vector Informatik bietet hier eine durchgängige Entwicklungs- und Testlösung. Die Option ISO 11783 für das Werkzeug CANoe stellt das notwendige Domänenwissen bereit und unterstützt so die Konformität zum ISO-11783-Standard (Bild 1). Die Erfahrungen der letzten zwei Jahre im Umfeld Isobus haben gezeigt, dass trotz stark steigender Anzahl der

zertifizierten Geräte mittels Konformitätstest [2] das Zusammenspiel unterschiedlicher Komponenten, wie z.B. Task Controller und Anbaugerät, nicht immer reibungsfrei funktioniert. Überraschungspotential steckt auch in der Bedienung eines Anbaugeräts mit Hilfe des Virtual Terminals. Die Spanne der Erfahrungen reicht von „funktioniert überhaupt nicht“ bis „keine Pro-bleme“. Auch für den ServiceTechniker ist es in einer so heterogenen Umgebung wie dem Isobus schwer, die Ursache eines Problems zweifelsfrei festzustellen und gegebenenfalls zu beseitigen. Häufig ist er dabei mit Elektronik automotive 10.2009 10/25

Entwicklung + Test

IIII Konformitätstest

I Bild 1. Die komplexen Kommunika­ tionsstrukturen des Isobus­ Standards können mit CANoe. ISO11783 einfach analysiert und simuliert werden. Hier werden der File Server, zwei Anbaugeräte und das Virtual Termi­ nal simuliert.

zwangläufig beheben, aber eine klare Identifikation der Ursache ist möglich. Liegt die Ursache beim Anbaugerät, kann der fälschlicherweise gerufene Service-Techniker des Traktorherstellers somit wertvolle Informationen wie FehlerCodes oder Teilenummern der betroffenen Komponenten ermitteln und so den Service-Techniker des Anbaugeräteherstellers vorab informieren. Dies reduziert die Ausfallzeiten auf ein Minimum und führt so beim Kunden zu einer höheren Akzeptanz von Arbeitsmaschinen mit Isobus. Aktuelle Bestrebungen zur Erweiterung des Teils 12 des Norm-Entwurfs ISO 11783 gehen dahin, dass es ein standardisiertes Beschreibungsformat für die Diagnose gibt. Damit kann jeder Hersteller individuell für jedes Steuergerät den Diagnoseumfang beschreiben. Eine darauf vorbereitete Diagnoseanwendung kann mit Hilfe dieser Beschreibung unabhängig vom Steuergerätehersteller das Steuergerät diagnostizieren. Die Diagnose-Beschreibungsdatei wird vom Steuergerät selbst oder über das Internet heruntergeladen.

Hersteller mit eigenem, firmenspezifischem Diagnosewerkzeug integrieren so die ISO-11783-Diagnose in ihr bestehendes und eingeführtes Werkzeug. Hersteller ohne eigene spezialisierte Werkzeuge können künftig standardisierte Diagnosewerkzeuge benutzen. Der praktische Nutzen liegt unter anderem darin, dass ein Service-Techniker mit einem Werkzeug eine systemweite Diagnosemöglichkeit hat. Damit lassen sich die wirklichen Ursachen effizient und sicher lokalisieren und bestenfalls auch gleich beseitigen.

 Automatisierte Tests während der Entwicklungsphase

Neben der ständigen Verfeinerung und Erweiterung der Testfälle des Konformitätstests im Rahmen der Standardisierungsarbeiten wurde mit dem Teil 12 des Testfall-Entwicklung Test-Ausführung Analyse der Ergebnisse Norm-Entwurfs ISO 1178 [4] eine gemeinsame DiagnoseGenerator CANdb schnittstelle geschaffen. Sie Plug-In/DiVa CANdela basiert auf der SAE-J1939HTLM Kontrolle TestGenerator 73-Diagnose [5]. Teil 12 der Report TestXLS Excel-Makro ISO-Norm definiert im beSpezifikation reits veröffentlichten Teil, der XML-Editor CANoe.ISO11783 XLM Basisdiagnose, einen offenen z.B. XML Spy XLM Diagnosezugang. Dieser stellt Test Automation grundlegende Funktionen CAPL Editor DB zur Verfügung und soll eine Vector Systemübersicht ermöglichen. CAPL-Browser Dazu gehört die eindeutige Identifikation der SteuergeVector räte am Bus sowie InformaI Bild 2. Ablaufschema des „CANoe.ISO11783 Test Feature Sets“ von der Erstellung des Testablaufs bis zur tionen zu Software-Version, Auswertung der Ergebnisse. Herstellerteilenummer und zu

Die Einführung eines einheitlichen Diagnosezugangs hilft, ein Problem vor Ort schnell zu erkennen und das defekte Teil eventuell auszutauschen. Im Falle einer Inkompatibilität sieht das jedoch meist anders aus: Ein Tausch der Elektronik hilft nicht weiter, da damit die Ursache des Problems nicht beseitigt wird. In einem solchen Fall wird eine korrigierte Steuergeräte-Software benötigt. Diese zu erstellen und zu testen, erfordert jedoch Zeit. Zudem ist die Verteilung der Software häufig kostspielig, da teilweise bereits ausgelieferte Geräte zurückgeholt werden müssen. Solchen Kompatibilitätsproblemen kann man durch geeignete Maßnahmen im Vorfeld begegnen. Eine Möglichkeit ist der Konformitätstest, der aber den Nachteil hat, dass die Anwendung selbst nicht Teil des Tests ist. Der Fokus beim Konformitätstest liegt auf der Prüfung der Konformität zum Standard. Zudem ist die Anwendung des Konformitätstests während der Entwicklung aufwendig oder nicht möglich, da nicht immer am Anfang der Entwicklung von einer hundertprozentigen Kompatibilität ausgegangen werden kann. Oftmals möchte man nur punktuell einen einzelnen Aspekt prüfen, z.B. das Transportprotokoll. Solche, die Entwicklung begleitenden Prüfungen werden erfahrungsgemäß sehr häufig wiederholt, haben eine Vielzahl von alternativen Abläufen und müssen flexibel konfigurierbar sein. Daher sollten solche Prüfungen automatisierbar sein. Treten während des Tests Probleme auf, sind umfangreiche Analysemöglichkeiten gefragt.

Elektronik automotive 10.2009

www.elektroniknet.de

ihm unbekannten Geräten bzw. Kombinationen von Geräten konfrontiert. Angesichts dieser Problematik und zur Sicherung der Kundenzufriedenheit hat die Herstellerinitative AEF (Agricultural Industry Electronics Foundation) eine Projektgruppe installiert, die Aktivitäten zur Verbesserung der Interoperabilität von Isobus-Geräten durchführt [3].

 Einheitlicher Diagnosezugang für den Fall der Fälle

10/26

Konformitätstest IIII

durchgeführten Konformitätstests. Jedes Steuergerät kann aktuelle Fehler berichten, und nach Aufforderung durch das Diagnosewerkzeug auch zurückliegende Fehler. Diese Informationen sollen ein schnelles und sicheres Einkreisen der Ursachen ermöglichen. Das ist besonders dann von Vorteil, wenn das Netzwerk aus Komponenten verschiedener Hersteller besteht. So kann z.B. der Service-Techniker eines Traktorherstellers mit seinem ISO-11783-12-kompatiblen Diagnosewerkzeug auch Probleme feststellen, die im Zusammenhang mit einem Anbaugerät eines anderen Herstellers auftreten. Das Problem lässt sich damit nicht

www.elektroniknet.de

Originalperipherie, z.B. Schweinwerfer (optional)

ECUPrüfling

Entwicklung + Test

VT-System

I/OAnschlüsse

CANoe

CAN, LIN, MOST, FlexRay, ...

I Bild 3. CANoe.ISO11783 und das VT­Sys­tem von Vector bilden zusammen eine „Midsize HiL“.

 Ein Werkzeug für alle Fälle CANoe.ISO11783 von Vector Informatik ist eine durchgängige Entwicklungs- und Testlösung zur Sicherung der Konformität zum Standard ISO 11783 und stellt das notwendige Domänenwissen bereit [6]. So ist z.B. das Virtual Terminal fester Bestandteil von CANoe (Bild 1). Mit Hilfe des „Diagnostic Trouble Code-Monitor“ und des „J1939-Scanners“ lassen sich die Diagnosemeldungen visualisieren. Das integrierte „Test Feature Set“ erlaubt es, wiederkehrende Tests und Testabläufe zu definieren. Die Testabläufe können einfach definiert werden, z.B. per XML. Bild 2 zeigt eine schematische Darstellung des Test Feature Set. CANoe.ISO11783 kann in einer solchen Umgebung die Rolle des TestMasters darstellen und über vielfältige Schnittstellen wie z.B. COM oder .NET andere Werkzeuge einbinden bzw. ansteuern. Es ist aber auch möglich CANoe.ISO11783 in eine bestehende Testumgebung über die oben genannten Schnittstellen zu integrieren. Durch umfangreiche Simulationsund Analyseeigenschaften ist der Einsatz nicht nur auf Tests oder Simulation einzelner Steuergeräte beschränkt. Das Werkzeug kann ganze Netzwerke simulieren (Restbussimulation). So lässt sich einem Anbaugerät beispielsweise die Bedienung über einen Task Controller oder das Virtual Terminal vorspielen. Mit Hilfe der Test-Hardware von Vector steuert CANoe. ISO11783 auch reale Verbraucher und Sensoren wie Stellmotoren und Ausgänge eines Steuergerätes (Bild 3) direkt an bzw. liest diese ein. Die komplexen Kommunikationsstrukturen des Isobus-Standards

können mit CANoe.ISO11783 einfach und effizient genutzt, analysiert und simuliert werden. Damit steht ein durchgängiges Werkzeug zur Sicherung der Konformität über alle Produktphasen zur Verfügung: von der Entwicklung, über den Betrieb bis zur Wartung der Arbeitsmaschinen. sj Literatur und Links [1] VDMA Fachverband Landtechnik: Isobus spricht alle Sprachen. Reden Sie doch einfach mit. 2005, S. 2. [2] VDMA Fachverband Landtechnik: IsobuskonformeGerätenachStandardISO11783. www.isobus.net/isobus_D [3] www.isobus-fuer-alle.de/aef [4] Society of Automotive Engineers: J1939. [5] InternationalOrganisationforStandardization: ISO/FDIS 11783-12. ISO 11898. [6] www.vector.com/isobus

Dipl.-Ing.(FH) Peter Fellmeth studierte an der FH Esslingen im Fachgebiet Technische Informatik mit Schwerpunkt Automatisierungstechnik. Er ist Team-Leiter und Produkt-Manager bei der Vector Informatik GmbH. Hier ist er verantwortlich für die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von Isobus, J1939, Ethernet und DeviceNet. [email protected]

Elektronik automotive 10.2009 10/27

Entwicklung + Test

llll Off-Highway-Anwendungen

Off-Highway-Anwendungen llll

Neue Wege beim Testen Simulationen ersetzen unflexible und zeitintensive Praktiken beim Testen von Isobus-Task-Controllern Die system- und herstellerübergreifende Kompatibilität von Isobuskonformen Geräten erlaubt es dem Landwirt, Traktoren und Anbaugeräte über Herstellergrenzen hinweg beliebig zu kombinieren. So einfach wie sich das auf der Anwenderseite darstellt, so hoch ist der Aufwand auf der Entwicklungsseite, insbesondere in der Testphase. Ein Blick zu John Deere zeigt, dass die gängige Testpraxis bei Elektronikkomponenten in der Branche derzeit häufig an Grenzen stößt. Ungleich schneller und effizienter führen automatische Testabläufe mit einer simulierten Anbaugeräteumgebung ans Ziel. Von Alexander Ostermüller und Peter Fellmeth

D

as Zusammenspiel mit vielen unterschiedlichen Anbaugeräten macht den Traktor zum Multitalent unter den Feldmaschinen. Solange der Traktor eine reine Zugund Antriebsmaschine bleibt und darüber hinaus keine Interaktion mit Elektronik automotive 11.2011 10/28

dem Anbaugerät stattfindet, ist die Bedienung der beiden relativ unkompliziert, aber wegen der fehlenden Kopplung wenig effizient. Die moderne Landwirtschaft verlangt jedoch intelligente, automatisierte Lösungen, die zum Beispiel eine variable Aus-

bringmenge für Saatgut und die Dokumentation der auf dem Feld durchgeführten Arbeit unterstützen. Je größer allerdings die Komplexität wird und je mehr intelligente Funktionen Einzug in die Agrartechnik halten, desto mehr Aufwand erfordert es, die Bedienung und Handhabung für den Landwirt einfach zu halten. Langwierige Inbetriebnahmeprozesse sind kontraproduktiv, nicht zuletzt für die Akzeptanz der modernen Landtechnik. Die verschiedensten Anbaugeräte müssen sich zügig und problemlos an den Traktor ankoppeln – sowohl mechanisch als auch elektronisch.

ˆ Isobus-Kompatibilität und -Konformität haben oberste Priorität Eine Schlüsselrolle spielt dabei die Isobus-Anwendung. Isobus wurde ins Leben gerufen, damit Zugmaschinen, Anbaugeräte und Bedien-Terminals miteinander kommunizieren und Daten austauschen können. Die technischen Details sind in der Normenreihe

ISO 11783 definiert und behandeln alle Themen vom Schichtenmodell über die Diagnose bis zum File-Server. Damit die Interoperabilität zwischen Geräten unterschiedlicher Hersteller reibungslos funktioniert, sind sowohl für Hersteller von Traktoren als auch von Anbaugeräten umfangreiche Tests unverzichtbar. Neben den obligatorischen Konformitätstests spielen die Entwicklungsabteilungen zahlreiche weitere Testszenarien durch. Darüber hinaus organisieren die Hersteller regelmäßig „Plug-Feste“, in denen sie die Praxistauglichkeit der zahlreichen Funktionen ihrer Produkte herstellerübergreifend verifizieren. Als einer der Vorreiter der modernen Landtechnik gilt das Traditionsunternehmen John Deere. Die Produktpalette reicht von Traktoren über Feldspritzen und Ballenpressen bis zu Sä-, Ernte- und Häckselmaschinen. Nicht nur landtechnische Produkte werden entwickelt, sondern auch Baumaschinen, Forstmaschinen und Kommunaltechnik sowie Maschinen für die Rasen-, Grundstücks- und Golfplatzpflege. Neben den deutschen Niederlassungen in Zweibrücken, Mannheim und Bruchsal hat der amerikanische Landmaschinenspezialist im Frühjahr 2010 einen weiteren Standort in Kaiserslautern eröffnet. Die Mitarbeiter im neuen Europäischen Technologie- und Innovationszentrum (ETIC) beschäftigen sich mit Zukunftstechnologien und bringen gemeinsam mit den Entwicklungsabteilungen der anderen Standorte entsprechende Produkte zur Serienreife. Precision Farming (Präzisionslandwirtschaft), die Integration von intelligenten Technologien in die Maschinen und Landmaschinen-Elektronik bilden die Schwerpunkte der Entwicklungstätigkeiten in Kaiserslautern.

der am PC geplanten Einsätze lädt der Landwirt per Speicherkarte oder USBSpeichermedium auf die Bedienkonsole im Traktor. Auch die Telematik und die Satellitennavigation leisten in Kombination mit Lenk- und Spurführungssystemen sowie der Teilbreitensteuerung wichtige Beiträge. Das Ergebnis ist ein lückenloses Ausbringen von Saatgut und Dünger ohne Fehlstellen. Gleichzeitig sorgt die Technik für minimale Überlappungen an keilförmigen Flächen und spart Rohstoffe an Feldgrenzen. Anbaugeräte mit Teilbreitensteuerung sind in mehrere Sektionen unterteilt, die sich unabhängig voneinander einund ausschalten lassen. Da sämtliche Aktivitäten protokolliert werden, führen Bewegungen des Traktors, bei denen das Anbaugerät entweder über die Feldgrenzen hinausragt oder schon bearbeitete Bereiche überstreicht, zu einer automatischen Deaktivierung der betreffenden Sektionen.

ˆ Der Task Controller als Schnittstelle zur Gerätesteuerung Diese Funktionen erfordern eine genaue Kenntnis der technischen Daten und Funktionen des Anbaugeräts seitens der Traktorelektronik. Das IsobusBedien-Terminal ist meist nicht nur ein Bedien- und Anzeigesystem, sondern ein Mini-Computer, auf dem gleichzei-

Entwicklung + Test

tig mehrere Anwendungen laufen, wie z.B. der Task Controller, der in ISO 11783 Teil 10 beschrieben ist. Er dient im Idealfall gleichzeitig als ein Dokumentations- und Steuerungssystem mit einer Schnittstelle über die TaskData. xml-Datei zum Farm-ManagementSystem. Im „John Deere GreenStar 2630 Display“ stellt der Task Controller eine Schnittstelle zwischen dem Dokumentationssystem und einem IsobusAnbaugerät dar. Beim ersten Ankoppeln lädt der Task Controller ein „Device Description File“ vom Rechner des Anbaugeräts. Diese Gerätebeschreibungsdatei enthält alle für den Task Controller notwendigen Informationen, wie Arbeitsbreite, Art der Aufhängung zum Traktor oder ggf. die Anzahl der schaltbaren Sektionen mit zugehörigen Elementnummern. Das Anbaugerät lässt sich über die Bedienkonsole des Traktors bedienen (Bild 1). Der Task Controller muss lückenlos die gesamte Bandbreite an möglichen Anbaugeräte-Konstellationen beherrschen. Nur so ist sichergestellt, dass das Isobus-Bedien-Terminal und dessen Anwendungen mit jedem verfügbaren Isobus-Anbaugerät korrekt zusammenarbeiten. Jede Arbeitsmaschine funktioniert jedoch anders und nutzt eine andere Kombination von Funktionen des Task Controller. Für Testzwecke tauschen die Hersteller daher spezielle Hardware-Boxen un-

ˆ Vom Hofrechner bis zur automatischen Teilbreitensteuerung Der Begriff des Precision Farming bringt die aktuellen Trends der Agrartechnik anschaulich auf den Punkt. Es geht dabei um den optimalen Einsatz aller verfügbaren Ressourcen wie Maschinen, Saatgut, Düngemittel und Treibstoff, mit dem Ziel, größtmöglichen Ertrag und maximale Wirtschaftlichkeit zu erreichen. Die Parameter

l Bild 1. John-Deere-Isobus-Bedienterminal mit der Kverneland-Düngerstreuer-Bedienoberfläche. (Bilder: John Deere) Elektronik automotive 11.2011 10/29

Entwicklung + Test

llll Off-Highway-Anwendungen

l Bild 2. Simulation von Traktor und Düngerstreuer in CANoe.ISO11783.

tereinander aus, in denen der elektronische Funktionsumfang ihrer Anbaugeräte abgebildet ist. Leider enthalten die Boxen neben der SteuergeräteHardware und -Software nur selten alle Komponenten, die zu einem umfassenden Funktionstest der Gerätelogik nötig sind.

ˆ Effizientere Testmethode gesucht

Außerdem gibt es für Auf bau und Handhabung der Test-Boxen keine Standardisierung. Jede Firma verfolgt eine andere Bedienphilosophie, manche Boxen sind reine Simulationen, andere entsprechen weitgehend der realen Elektronik. Bevor die Tester zu ihrer eigentlichen Arbeit kommen, müssen sie umfangreiche Bedienungsanleitungen studieren und sich mit zahlreichen virtuellen Bedienelementen und Funktionen vertraut machen. Diese in der Branche zwar gängige, aber höchst unflexible und unbefriedigende Vorgehensweise war für John

Off-Highway-Anwendungen llll

Deere der Anlass zur Suche nach einer effizienteren Testmethode. Die Lösung fanden die Test-Ingenieure in CANoe.ISO11783, einem auf die Anforderungen von Isobus exakt zugeschnittenen Entwicklungs-, Testund Simulationswerkzeug aus dem Hause Vector Informatik. CANoe.ISO11783 sorgt bei Entwicklungen von Beginn an bis zur Testphase und zur Wartung für Isobus-Konformität. Die komplexen Isobus-Kommunikationsstrukturen lassen sich auf vielfältige Weise analysieren, visualisieren und aufbereiten. Funktionen wie das Virtual Terminal oder der Interaktive Task Controller erleichtern dem Entwickler die Arbeit mit ISO 11783. Mit dem CANoe-Terminal sind z.B., anders als mit einer realen Konsole, verschiedene Display-Arten, Auflösungen oder Schwarz/Weiß-Darstellungen durchspielbar. Der Interaktive Task Controller ermöglicht das Laden der Gerätebeschreibung von einer beliebigen, realen Isobus-Maschine oder dient zur Verifikation von Simulatoren, bevor diese zum Testen eingesetzt werden.

Auch in Kaiserslautern waren die Mitarbeiter damit beschäftigt, Funktionsumfänge und Kompatibilität ihrer Task Controller anhand der Test-Boxen und realer Geräte verschiedener Anbaugerätehersteller zu prüfen. Das ist angesichts der Vielfalt an Feldgeräten und Fremdfirmen eine zeitintensive und mühsame Angelegenheit. Theoretisch müsste man jede Isobus-Maschine, sei sie zum Säen oder Pflanzen bestimmt, jeden Düngerstreuer, jede Pflanzenschutzspritze sowie alle weiteren Maschinen mit jeder Task-Controller-Version testen. l Bild 3. Unterstützung eines „Isobus Multiple Product Implement“ seitens des Task-Controller durch eine Simulation. Elektronik automotive 11.2011 10/30

ˆ Höhere Testabdeckung in kürzerer Zeit Um beim Testen des Task Controller von den Anbaugeräteherstellern unabhängig zu sein, nutzen die Test-Ingenieure von John Deere vor allem die Simulationsmöglichkeiten des Werkzeugs (Bild 2). CANoe ist in der Lage, nicht nur einzelne Steuergeräte, sondern ganze Netzwerke zu simulieren. Denn Entwicklungen lassen sich nur vernünftig und realitätsnah testen, wenn das spätere Umfeld entweder bereits komplett vorhanden ist oder per Restbussimulation generiert wird. Im Fall des Task Controller sind Anbaugeräte in den verschiedensten Ausprägungen simulierbar. So kann John Deere völlig unabhängig von Fremdherstellern agieren und ist nicht mehr auf deren Hardware-Boxen angewiesen. Eine Hilfe bei der Definition von automatischen und wiederkehrenden Tests ist das integrierte Test Feature Set. Das System kann wahlweise als Test-Master fungieren oder sich in bestehende Testumgebungen einfügen. Zur Ansteuerung und Kommunikation mit anderen Werkzeugen stehen Schnittstellen wie COM oder .NET zur Verfügung. Eine wesentliche Erleichterung stellt für John Deere die Flexibilität der Simulationen dar, wie das Beispiel der Teilbreitensteuerung zeigt: So lässt sich etwa die Art und Größe von Arbeitsmaschinen ohne nennenswerten Aufwand variieren und nachprüfen, ob der Task Controller auch mit 16 statt acht Sektionen umgehen kann. Ebenso sind Anbaugeräte definierbar, deren Sektionen nicht streng nebeneinander, sondern versetzt hintereinander angeordnet sind. Da CANoe.ISO11783 den Standard umfassend und vollständig repräsentiert, erreicht der Landmaschinenspezialist in kürzerer Zeit eine höhere Testabdeckung. Das gilt insbesondere auch für Anwendungssituationen, die von den Hardware-Boxen nicht beziehungsweise teilweise nicht unterstützt werden. Dazu gehören Tests mit intelligenter Steuerung der Fahrgeschwindigkeit, die Überprüfung auf korrekte Handshakes oder das Simulieren von Fehlern, etwa indem ein Anbaugerät keine Bereitschaft für die Teilbreitensteuerung signalisiert. Im Technologie- und Innovationszentrum von John Deere dient CANoe.

ISO11783 nicht nur zur Simulation von fremden Arbeitsmaschinen, sondern auch zur eigenen Steuergeräteentwicklung. Für die Tests lässt sich wahlweise die echte Traktor-Hardware verwenden oder diese ebenfalls simulieren. Da es vom Task Controller manchmal mehrere Versionen gibt, die alle zu testen sind, ermöglichen hier Simulationen ein schnelles Umschalten zwischen verschiedenen Varianten. Einen weiteren Vorteil bietet CANoe bei verteilten Entwicklungsarbeiten an verschiedenen Standorten. Die Simulationskonfigurationen können per EMail schnell und komfortabel zwischen verschiedenen Abteilungen ausgetauscht oder zu den Kollegen in die USA geschickt werden.

ˆ Zukünftige Anforderungen abdecken Die Komplexität des Isobus sowie die Vielfalt der am Markt verfügbaren Anbaugeräte lassen sich mit althergebrachten Entwicklungs- und Testmethoden nicht mehr rationell beherrschen. An ihre Stelle treten Entwicklungs-, Test- und Simulationswerkzeuge wie CANoe.ISO11783, die in allen Produktphasen für größtmögliche Kompatibilität zum Standard sorgen. Die Multibusfähigkeit des Werkzeugs erlaubt eine problemlose Darstellung und Interpretation von Isobus- und J1939-Botschaften in einem TraceFenster. Da das Werkzeug den vollen Isobus-Funktionsumfang abdeckt und stets auf dem aktuellen Stand ist, erzielt John Deere mit geringerem Zeitund Personalaufwand eine bessere Testabdeckung. Gleichzeitig ist man in der Lage, nicht nur erweiterte TaskController-Funktionen zu testen, sondern jederzeit auch für neueste und künftige Entwicklungen des Isobus-Standards die Gegenstelle zu simulieren. Interessant in diesem Zusammenhang ist der „Isobus Multiple Product Implement Simulator“ (Bild 3). Ein Multiple-Product-Anbaugerät ist beispielsweise eine Maissämaschine mit Unterfußdüngung. Dadurch ist es möglich, gleichzeitig zu säen und festen Dünger auszubringen. Die Vorteile liegen, neben der Zeitersparnis, in einer geringeren Bodenerosion, wenn der Traktor nur einmal statt mehrfach über das Feld fährt. Zur Testzeit im

Entwicklung + Test

Frühjahr 2011 gab es noch keinen Anbaugerätehersteller, der solche Isobus-Maschinen auf dem Markt anbietet. Deshalb war das Unterstützen solcher Maschinen seitens des Task Controllers nur mit einer Simulation möglich. Auch das Potential der Simulationen ist mit der bloßen InHouse-Anwendung längst noch nicht erschöpft. Wünschenswert aus Sicht der John-Deere-Mitarbeiter wäre es, wenn die Hersteller statt der unflexiblen, teueren und schwer zu reproduzierenden Hardware-Boxen die CANoe-Simulationen austauschen würden. Befürchtungen, damit sein Know-how preiszugeben, sind unbegründet, da es für die Simulationen völlig ausreichend ist, das Kompilat ohne den Source Code weiterzugeben. sj

Dipl.-Ing. (FH) Peter Fellmeth ist Gruppenleiter und Produkt-Manager bei der Vector Informatik GmbH. Hier ist er verantwortlich für die Entwicklung von Produkten und kundenspezifischen Projekten im Umfeld von Isobus, J1939, Ethernet und Car-2-X. [email protected]

Dipl.-Ing. (FH) Alexander Ostermüller ist Test-Ingenieur im Europäischen Technologie- und Innovationszentrum (ETIC) von John Deere in Kaiserslautern. [email protected]

Elektronik automotive 11.2011 10/31

10/32

10/33

10/34

10/35

N U T Z FA H R Z E U G E

N U T Z FA H R Z E U G E

Fahrspur des Masters und erfüllt dieselbe Arbeitsaufgabe. Soll der Slave exakt in der Fahrspur des Masters folgen, hilft der Modus Tracking. Der Modus Ignore erlaubt es den Slave kurzfristig auszukoppeln, um mit dem Master unabhängige Fahrmanöver durchzuführen. Der Slave schließt bei Verlassen des Modus wieder auf direktem Weg auf. Für das Wendemanöver am Vorgewende steht der Fahrmodus Turn-Over zur Verfügung. Wird ein Hindernis im geplanten Pfad gemeldet, sucht sich der Slave im Modus Evasion einen kollisionsfreien Ausweichpfad.

Entwicklung eines kooperativen Traktorgespanns

Bild 2: Sicherheitskonzept der elektronischen Deichsel.

Sicherheitskonzept und Zustandsautomat Sicherheit ist in der Entwicklungsphase eines unbemannten Fahrzeugs ein wesentlicher Aspekt. Nach ISO 25119 sind mithilfe typischer Werkzeuge Risikoquellen und Schwachstellen der funktionalen Sicherheit einer Maschine zu identifizieren und mit geeigneten Maßnahmen zu entschärfen. Eine Risikoanalyse liefert für jedes betrachtete Szenario im Produktlebenszyklus einen sogenannten Agricultural Performance Level (AgPL), aus welchem Anforderungen an Hard- und Software abgeleitet werden können. Der elektronischen Deichsel liegt ein dreistufiges Sicherheitskonzept zugrunde (Bild 2). Im Zustand Operational liegen keine kritischen Fehler- und Warnmeldungen vor; der geplante Pfad ist frei von Hin-

Während Fahrerassistenzsysteme zunehmend die Kontrolle über Längs- und Querregelung von Fahrzeugen im Straßenverkehr übernehmen [1], schreitet in der Landtechnik die Entwicklung fahrerloser Maschinen voran. Diesen Trend unterstützt auch die am Lehrstuhl für mobile Arbeitsmaschinen des Karlsruher Instituts für Technologie, KIT, in Kooperation mit den Firmen AGCO und geo-konzept entwickelte elektronische Deichsel für landwirtschaftliche Arbeitsmaschinen [2].

10/36

HANSER automotive 9 / 2014

Elektronische Deichsel für Traktoren Die elektronische Deichsel ermöglicht das zeitgleiche Führen von zwei Traktoren mit nur einem Fahrer. Hierzu werden zwei baugleiche Traktoren, ausgestattet mit identischem Anbaugerät, mit hochgenauen RTK-GNSS-Empfängern (Real-Time-Kinematics) versehen und per Datenfunk miteinander verbunden. Während ein Traktor, als Masterfahrzeug konfiguriert, bemannt vorweg fährt, folgt ein unbemanntes, als Slave konfiguriertes Fahrzeug mit vorgegebenem longitudinalen und lateralen Ver-

satz. Die Arbeitseinstellungen des Masterfahrzeugs werden zur Umsetzung des Arbeitsprozesses ortsgebunden vom Slave kopiert. Eine gute Bedienbarkeit und hohe Sicherheit wird durch die Nutzung von Umfeldsensorik zur Hinderniserkennung (Bild 1) und webbasierten Geo-Informationen erzielt.

Systemfunktion Zum Betrieb der elektronischen Deichsel stehen dem Fahrer fünf Fahrmodi zur Verfügung. Als Start- und Arbeitsmodus dient der Modus Parallel Driving. Hier folgt der Slave parallel der © Carl Hanser Verlag, München

Zustand Assignment mit beiden Fahrzeugen eine Zuweisung durchgeführt werden, in der die Funkverbindung zwischen beiden Fahrzeugen hergestellt wird. Wurden zwei Fahrzeuge zugewiesen, geht das System in den Safety Stop über. Der Slave befindet sich nun im aktiven Halt. Nun kann zu jedem Zeitpunkt der Emergency Stop ausgelöst werden. Um den Fahrbetrieb aufzunehmen, werden die Fahrzeuge nach Freigabe durch den Fahrer im Zustand Docking mit einander gekoppelt, sofern Relativpositionen und Ausrichtung dies zulassen. Das System geht in den Zustand Operation über und der Slave ist eigenständig fahrfähig. Vom Standardfahrmodus Parallel Driving aus kann jeder andere Fahrmodus aktiviert werden. Kollisionsgefahr wird von der Umfeldsensorik bestehend aus 2D-Laserscannern und 3D-Kameras erkannt und führt unmittelbar zum Safety Stop.

Prototypenentwicklung an verteilten Standorten Alle Bilder: Karlsruher Institut für Technologie (KIT)

A

utomatisiertes Fahren steht in der Automobilbranche hoch im Kurs. Auch bei der Entwicklung landwirtschaftlicher Arbeitsmaschinen gewinnt dieses Thema zunehmend an Bedeutung. In einem Forschungsprojekt beim Karlsruher Institut für Technologie wurde nun ein System entwickelt, bei dem eine bemannte Landmaschine als Leitfahrzeug voraus fährt und sich eine weitere autonom und fahrerlos daran orientiert. Ziel des Projektes: Steigerung der Flächenleistung und Optimierung der Maschinenauslastung in der Agrarwirtschaft ohne zusätzlichen Personalaufwand.

dernissen. Der Zustand Safety Stop (SSt) ist als aktiver Halt in Bezug auf Fahr- und Arbeitsantriebe zu verstehen. Als höchster Level des Sicherheitskonzepts dient der Zustand Emergency Stop (ESt). Hier wird mit sofortiger Wirkung der Motor abgeschaltet und die elektronische Feststellbremse betätigt. Die Umsetzung des Sicherheitskonzepts erfolgt in Form eines Zustandsautomaten, der als zentrales Softwaremodul auf beiden Fahrzeugen aktiv ist und synchronisiert den Gesamtsystemzustand festlegt. Bild 3 zeigt den Zustandsautomaten der elektronischen Deichsel. Bei Systemstart ist zunächst der Zustand Default aktiv. Die Rolle des Traktors kann als Master oder Slave festgelegt werden. Nach Festlegung der Rollen muss im

Bild 1: Prototypischer Aufbau zum Test der Umfeldsensorik des Slave-Traktors. www.hanser-automotive.de

Die Umsetzung eines komplexen modularen Assistenzsystems mit externen Projektpartnern erfordert eine detaillierte Spezifikation der Schnittstellen. Aufgrund der nicht harmonisierten Entwicklungsplattformen bei den einzelnen Partnern wurde eine verteilte Architektur gewählt, in der verschiedene Soft- und Hardwaremodule über einen proprietären edaugCAN-Bus und über TCP/IP Ethernet miteinander kommunizieren. HANSER automotive 9 / 2014

10/37

N U T Z FA H R Z E U G E

N U T Z FA H R Z E U G E

Restbussimulation zur Unterstützung der Softwareentwicklung

Bild 3: Modell zur Festlegung des Betriebszustands.

Hardwarearchitektur Während die Umsetzung der Navigationsfunktionen (NAV) und der Zugang zum proprietären, maßgeschneiderten Geo-Datenserver (GIS), sowie der Zugriff auf die Fahrzeugsteuerung (EXT) über das Hauptsteuergerät und die Bedieneroberfläche für das serienmäßige Terminal (HMI) in der Verantwortung der Projektpartner lag, wurden am KIT der Zustandsautomat (ZST) und die Umfelderkennung (UFS) auf einer Rapid-Prototyping-Plattform implementiert.

intensiven Umfelddaten werden über TCP/IP-Ethernet übertragen. Geringe Teilnehmerzahl und Netzwerklast erlauben einen echtzeitfähigen Versand und Empfang der Daten. Funkkommunikation zwischen den Fahrzeugen erfolgt im Vollduplex-Verfahren. Die verwendeten Modems werden über RS232-Schnittstellen eingebunden. Master und Slave tauschen laufend Daten über Position und Bewegungszustand, Systemzustand, Einstellungen der Arbeitsantriebe, den Fahrzeugzustand und Umfeldinformationen aus

(Bild 4). Die pragmatische Gestaltung der Schnittstellen ermöglicht eine unkomplizierte Umsetzung und Validierung der Teilfunktionen. Als Sicherheitsmechanismen zur Diagnose typischer Datenübertragungsfehler wurden Timeouts und Prüfsummen verwendet, um Datenintegrität und die Aktivität der Teilnehmer zu gewährleisten. Ein Überschreiten eines Timeouts auf dem CAN-Bus oder in der Funkstrecke löst unmittelbar den Emergency-Stop aus, da die Kontrolle über das Fahrzeug nicht mehr gewährleistet werden kann.

Datenkommunikation Für den Austausch von System- und Betriebsdaten innerhalb der Fahrzeuge über das proprietäre CAN-Protokoll wurde physikalisch der ISOBUS des Traktors genutzt. Durch die Wahl von 11-bit-Identifiern können beide Busse störungsfrei parallel betrieben werden. Jedes Hardware-Modul verfügt über eine eigene CAN-ID, unter der mittels Multiplexing alle relevanten Signale übertragen werden. Die bandbreiten-

10/38

HANSER automotive 9 / 2014

In der Entwicklung von Steuergeräten stellt die Restbussimulation (RBS) ein mächtiges Werkzeug zur Unterstützung des Debuggings und zur Validierung der Software unter möglichst realitätsnahen Randbedingungen dar. Nicht nur in der Automobilbranche, sondern auch bei mobilen Arbeitsmaschinen kommunizieren Steuergeräte, Sensoren und Aktuatoren gleichzeitig in verschiedenen Netzwerken. Umfassende Softwaretests sind meist erst möglich, wenn die Schnittstellen des Steuergeräts mit realistischen Werten versorgt werden können. Um Softwaretests in der Entwicklungsphase nicht aufwendig im realen System durchführen zu müssen, kann mithilfe einer RBS die übrige Netzwerkumgebung eines Steuergerätes virtuell nachgebildet werden. Softwaretests erfolgen auf diese Weise kostengünstig, schnell und sicherheitsunkritisch.

CANoe Die Software CANoe der Firma Vector Informatik unterstützt flexibel die Entwicklung der Netzwerkkommunikation. Die Struktur eines CAN-Netzwerkes wird in CANoe vollständig mithilfe sogenannter Netzknoten abgebildet, in denen das Kommunikationsverhalten der Teilnehmer hinterlegt wird. Darüber hinaus können Bedien-Interfaces, Signalgeneratoren und weitere Kommunikationsschnittstellen als Netzknoten angelegt werden. Das eventgesteuerte oder interaktive Verhalten kann in CAPL, einer C-ähnlichen Programmiersprache [3], oder bspw. mithilfe kompilierter Simulink-Modelle erfolgen. In einer Datenbasis werden alle vorkommenden Nachrichten inklusive Signalaufbau hinterlegt und einzelnen Netzknoten zugewiesen. CANoe ist multibusfähig, d. h. sowohl proprietäre als auch standardisierte Protokolle wie CAN, J1939 oder ISO 11783 und auch FlexRay und Ethernet werden unterstützt. Zur Modellierung und zeitsynchronen Auswertung steht ein Set von

Stimulations- und Tracing-Funktionen mit vielfältigen Filtermöglichkeiten, grafischer Signaldarstellung sowie eine Übersicht über wichtige Kommunikationsparameter wie Buslast oder Fehlernachrichten zur Verfügung. Beliebige Steuergeräte können nun wahlweise virtuell oder real betrieben werden, indem die Netzknoten in CANoe aktiviert oder deaktiviert werden. Die Busankopplung erfolgt über ein Interface der Firma Vector. CANoe kann darüber hinaus Testszenarien vollautomatisch ablaufen lassen und protokollieren. Diese Testszenarien lassen sich wahlweise tabellarisch sowie in XML, CAPL [3], C# oder grafisch definieren.

Modellierung der elektronischen Deichsel in CANoe CANoe eignet sich in dieser Projektkonstellation insbesondere zur frühzeitigen Validierung der Steuergeräte, da die Abstimmung von Terminen und Testmöglichkeiten mit den Versuchsfahrzeugen oft kritisch ist. Der Ansatz der RBS ermöglicht parallele Entwicklungspfade, die anschließend leicht zusammengeführt werden können. Am KIT wurde ein umfassendes Modell der elektronischen Deichsel entwickelt, mit dem einzelne Steuergeräte, sowie die vollständige Kommunikation mit dem Partnerfahrzeug simuliert werden können. Die Software-Module ZST, NAV und HMI wurden dazu als Netzknoten modelliert. Die Detailtiefe der einzelnen Module variiert innerhalb des Modells. Während alle den Systemzustand steuernden Nachrichten in vollem Funktionsumfang abgebildet wurden, genügt zur Validierung der Datenintegrität in den übrigen Nachrichten die Zuweisung konstanter Testparameter. Die Nutzung von CANoe in Verbindung mit der modellbasiert programmierbaren dSpace-Plattform hat sich als besonders hilfreich erwiesen. Die entwickelten Simulink-Modelle können nach Austausch der plattformspezifischen I/O-Blocks unmittelbar für CANoe kompiliert und in das Restbusmodell integriert werden. Durch die Zugriffsmöglichkeit auf die seriellen

Schnittstellen des PCs in CANoe, konnte auch die Funkstrecke unverändert integriert und in Hinblick auf Datenintegrität getestet werden.

Zusammenfassung Die elektronische Deichsel hat sich nicht nur in Hinblick auf den innovativen Schwerpunkt Hinderniserkennung und Integration von Geo-Informationen in einem stimmigen Sicherheits- und Bedienkonzept als komplex erwiesen. Die Spezifikation und Pflege von Datenschnittstellen ist in einem sich kontinuierlich ändernden prototypischen System eine begleitende Aufgabe, die von allen Seiten ernst genommen werden muss. Eine sauber spezifizierte modulare System- und Softwarearchitektur erweist sich bei der Kooperation mehrerer Firmen schnell als wesentliche Grundlage für einen schnellen Projektfortschritt. Rapid-Prototyping-Systeme in Verbindung mit einer RBS-Software stellen jedoch einen projektbegleitenden Werkzeugkasten zur effizienten Validierung von Teilfunktionen und ganzen Steuergeräten dar, um im abschließenden Feldtest erfolgreich zu sein. W (oe) » www.vector.com Literatur [1] Winner, H.; Hakuli, St.; Wolf, G. (2012). Handbuch Fahrerassistenzsysteme. 2. Auflage. ISBN 978-3-8348-1457-9. Vieweg + Teubner Verlag, Springer Fachmedien Wiesbaden GmbH. [2] Zhang, X.; Geimer, M.; Noack, P.O.; Grandl, L. (2010). Development of an intelligent masterslave system between agricultural vehicles. pp. 250-255. IEEE. Intelligent Vehicles Symposium. 6/21-6/24/2010. San Diego, CA, USA [3] Marc Lobmeyer/Roman Marktl: Programming ECU Tests More Efficiently – Tips and Tricks for the Use of CAPL. In: CAN Newsletter (2014), H. 2, S. 42-43

Dipl.-Ing. Bernhard Jahnke ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Mobile Arbeitsmaschinen des Karlsruher Instituts für Technologie (KIT). Dipl.-Ing. Hans-Werner Schaal ist Business Development Manager im Bereich Automotive Ethernet, Car2x und offener CAN-Protokolle wie J1939 und ISO 11783 bei der Vector GmbH.

Bild 4: Kommunikationsarchitektur im Prototyp. © Carl Hanser Verlag, München

Impressum Verlag: Carl Hanser Verlag GmbH & Co. KG, Kolbergerstr. 22, 81679 München © Lizenzausgabe mit Genehmigung des Carl Hanser Verlags, München. Alle Rechte, auch die des Nachdrucks, der photomechanischen und der elektronischen Wiedergabe sowie der Übersetzung dieses Sonderdrucks behält sich der Verlag vor.

10/39

KOMMUNIKATION KOMMUNIKATION

KOMMUNIKATION KOMMUNIKATION

ist, ist,sind sindEngpässe Engpässewährend während der der Testphase Testphase vorprogrammiert. vorprogrammiert. Einen EinenAusweg Auswegaus ausdiesem diesemDilemma Dilemma biebietet tetein einSoftware-Werkzeug, Software-Werkzeug,mit mitdessen dessen Hilfe Hilfeman manauf aufeinfache einfacheArt Artund und Weise Weise ei-einen nenPrototypen Prototypendes des zukünftigen zukünftigen GesamtGesamtsystems systemserstellt. erstellt.Optimalerweise Optimalerweisebietet bietet das dasWerkzeug Werkzeugauch auchnoch nochumfangreiche umfangreiche Testfunktionen. Testfunktionen.

Beispielkonfiguration Beispielkonfigurationfür fürein ein einfaches, einfaches,simuliertes simuliertesCAN CAN-open-Netzwerk open-Netzwerkmit mitzentraler zentraler Steuerung Steuerungund undI/O-Knoten I/O-Knoten

Eine EinePrototypenumgebung Prototypenumgebungmit mit Toolunterstützung Toolunterstützungaufbauen aufbauen

Prototyping Prototypingund undTest Test von von CANopen-Systemen CANopen-Systemen

Mit Mit wenig Aufwand zum Ziel CANopen CANopenhat hatsich sichals alsStandard Standard für für die die kostengünstige kostengünstige und flexible Vernetzung Vernetzung von von Komponenten Komponentenin inzahlzahlreichen reichenAnwendungsbereichen Anwendungsbereichen von von der der Fabrikautomation bis zum Nutzfahrzeug Nutzfahrzeug etabliert. etabliert.Ein Einspezialisierspezialisiertes tesPrototypingPrototyping-und undTest-Tool Test-Tool kann kann nicht nicht nur bei der Entwicklung komplexer komplexer CANopen-Projekte CANopen-Projektewertvolle wertvolle Dienste Diensteleisten, leisten,sondern sondernauch auch beim beim grundsätzlichen grundsätzlichen Einstieg in die Thematik Thematik helfen. helfen.

� � KOMPAKT KOMPAKT Die DieErstellung Erstellungvon vonPrototypen Prototypen bei bei CANCANopen-vernetzten open-vernetztenSystemen Systemen ist ist stets stets mit mit erheblichem erheblichem Aufwand Aufwand verbunden. verbunden. DieDieser ser ist ist allerdings allerdings oftmals oftmals unerlässlich, unerlässlich, um umnicht nichterst erstinineiner einerspäten spätenProjektphaProjektphase seAussagen Aussagenzur zurFunktionalität Funktionalitätund undLeisLeistungsfähigkeit tungsfähigkeit zu zu erhalten. erhalten. Spezielle Spezielle Software-Werkzeuge Software-Werkzeuge unterstützen unterstützen den den Anwender Anwender beim beim Erstellen Erstellen von von PrototyPrototypen. pen.Insbesondere Insbesonderedie diekommunikationskommunikationstechnischen technischenAnforderungen Anforderungen sind sind damit damit einfach einfachabzudecken. abzudecken.Durch Durchdie dieTestfunkTestfunktionalität tionalitätkann kannder derSystementwickler Systementwickler in in jeder jederPhase Phaseseines seinesProjektes Projektesdie diebis bisdahin dahin fertig fertiggestellten gestelltenKomponenten Komponentenüberprüüberprüfen fenund undverifizieren. verifizieren.

Sonderdruck Sonderdruckaus ausder derFachzeitschrift Fachzeitschrift 10/40

� � Die Die Bandbreite der Aufgaben bei der der

Entwicklung Entwicklung von CANopen-Systemen CANopen-Systemen reicht reicht von der Entwicklung einzelner einzelner Steuergeräte Steuergeräte bis hin zur Konfiguration Konfiguration und und Inbetriebnahme Inbetriebnahme von GesamtsysteGesamtsystemen. men. Für Für Systemhersteller ist der ErsteinErsteinsatz satz eines eines Systems wie CANopen zuzunächst nächst mit einem nicht kalkulierbaren kalkulierbaren Einstiegsaufwand Einstiegsaufwand verbunden. Dabei lässt lässt sich sich ein ein großer Teil der EntwicklungsaufEntwicklungsaufgaben gaben dem Bereich Verifikation und ValiValidierung dierung zurechnen. Das Risiko zu spät spät entdeckter entdeckter Fehler minimiert man hier hier sinnvollerweise sinnvollerweise durch umfassende Tests Tests zu zu einem einem möglichst frühen Zeitpunkt. Zeitpunkt.

Systemverifikation Systemverifikation über über Testaufbauten

Häufig Häufig besteht die Möglichkeit zum TesTesten ten jedoch jedoch erst zu einem sehr späten ZeitZeit-

punkt, punkt, wenn wenn die die Systemkomponenten Systemkomponenten tatsächlich tatsächlich verfügbar verfügbar sind. sind.Treten Treten dann dann Probleme Probleme auf, auf, droht droht Gefahr Gefahrfür fürden denFerFertigstellungstermin tigstellungstermindes desSystems. Systems. In Inder derPraxis Praxisführt führtman mandie dieTests Testsnicht nichtananhand hand des des realen realen Systems Systemsdurch, durch,sondern sondern bedient bedientsich sichTestaufbauten. Testaufbauten.Diese Dieseenthalenthalten ten neben nebenspeziellen speziellenMessMess-oder oderDiagnoDiagnose-Einrichtungen se-Einrichtungenfür fürden denTestbetrieb Testbetriebununter teranderem anderemAktoren, Aktoren,um ummöglichst möglichstreale reale Systemumgebungen Systemumgebungen zu zu simulieren. simulieren. InIn Abhängigkeit Abhängigkeit von vonder derProjektgröße Projektgrößekann kann ein ein solcher solcher Testaufbau Testaufbau aufwändig aufwändig und und kostenintensiv kostenintensiv werden. werden. Da Da in in der derRegel Regel nur nur ein ein einziger einziger Testaufbau Testaufbau vorhanden vorhanden

� � AUTOR AUTOR Dipl.-Ing. Dipl.-Ing.Mirko MirkoTischer Tischerarbeitet arbeitet bei beider derVector VectorInformatik InformatikGmbH GmbHinin Stuttgart. Stuttgart.

Prototypen Prototypenfür fürüber überCAN CANvernetzte vernetzteGeGesamtsysteme samtsystemesollen sollenininerster ersterLinie LinieTestTestund und Validierungsaktivitäten Validierungsaktivitätenunterstütunterstützen. zen.Weiterhin Weiterhinististwichtig, wichtig,EinzelkomEinzelkomponenten ponenten über über reale realeoder odersimulierte simulierte Steuergeräte Steuergeräteabzubilden. abzubilden. Damit Damit lässt lässt sich sich die dieFunktionsfähigkeit Funktionsfähigkeitrealer realer SteuergeräSteuergeräteteim imLaufe Laufeder derSystementwicklung Systementwicklung relarelativ tivleicht leichtprüfen. prüfen. Einen EinenPrototypen Prototypenfür fürein einkomplexes komplexesGeGesamtsystem samtsystemzuzuerstellen, erstellen, ististein ein aufwänaufwändiges digesUnterfangen, Unterfangen,sodass sodasssich sichder derEinEinsatz satzentsprechender entsprechenderWerkzeuge Werkzeugebezahlt bezahlt macht. macht.Hilfe Hilfebeim beimErstellen Erstellender derKommu Kommu - nikation nikationdes desPrototypensystems Prototypensystemsleistet leistet CANoe.CANopen CANoe.CANopenvon vonVector VectorInformatik. Informatik. Damit Damiterstellt erstelltder der Anwender Anwender über über wenige wenige Konfigurationsschritte Konfigurationsschritte einen einenPrototyp, Prototyp, der der inin seinen seinen KommunikationseigenKommunikationseigenschaften schaftendem demspäteren späterenrealen realenSystem System entspricht. entspricht. Das DasVerhalten Verhaltender derCANopen-SteuergeräCANopen-Steuergerätete istist inin Beschreibungsdateien Beschreibungsdateien(EDS: (EDS:

DieDie Software unterstützt den Anwender beim Erstellen, Aufzeichnen undund Auswerten der der TestSoftware unterstützt den Anwender beim Erstellen, Aufzeichnen Auswerten Testläufe derder unterschiedlichen Systemebenen. läufe unterschiedlichen Systemebenen.

Electronic Data Sheet) definiert, diedie man Electronic Data Sheet) definiert, man zunächst zunächstauswählt auswähltbzw. bzw.erstellt. erstellt.ImIm nächsten Schritt werden diedie später über nächsten Schritt werden später über den denBus Busausgetauschten ausgetauschtenApplikationsApplikationsdaten miteinander verbunden, beispielsdaten miteinander verbunden, beispielsweise der Eingang 'Druckventil' desdes Geräweise der Eingang 'Druckventil' Gerätestes mit der Adresse 5 (Druckmesser) mitmit mit der Adresse 5 (Druckmesser) der Variablen 'Gasdruck' imim Gerät mitmit derder der Variablen 'Gasdruck' Gerät Adresse 1010 (Steuerung). SoSo lassen sich allealle Adresse (Steuerung). lassen sich PDO-Verbindungen (Process Data Object) PDO-Verbindungen (Process Data Object) imim Prototypensystem festlegen. Prototypensystem festlegen. Das Tool berechnet automatisch dasdas re-reDas Tool berechnet automatisch sultierende sultierendeMapping, Mapping,dasdasnachträglich nachträglich beibeiBedarf ist.ist. Aus diesen Bedarfveränderbar veränderbar Aus diesen Konfigurationsinformationen (DCF – DeKonfigurationsinformationen (DCF – Device Configuration File) generiert derder An-Anvice Configuration File) generiert wender wendernun nundiediePrototypenumgebung. Prototypenumgebung. Das heißt, CANoe erzeugt fürfür jedes reale Das heißt, CANoe erzeugt jedes reale Steuergerät einein Pendant mitmit identischen Steuergerät Pendant identischen

Kommunikationseigenschaften. Kommunikationseigenschaften. Beim Beim Start vonvon CANoe steht derder KommunikatiStart CANoe steht Kommunikationsteil derder Prototypenumgebung bereits onsteil Prototypenumgebung bereits zurzur Verfügung. Verfügung.

Definition Definition desdes Applikationsverhaltens Applikationsverhaltens

DasDas Applikationsverhalten Applikationsverhalten derder einzelnen einzelnen beteiligten beteiligten Steuergeräte Steuergeräte lässt lässt sichsich nicht nicht direkt direkt ausaus denden EDS-Dateien EDS-Dateien ableiten, ableiten, da da diese diese nurnur diedie Struktur Struktur eines eines ObjektverObjektverzeichnisses zeichnisses abbilden. abbilden. DieDie Formulierung Formulierung desdes Applikationsverhaltens Applikationsverhaltens ist ist daher daher im-immer mer mitmit zusätzlichem zusätzlichem ProgrammieraufProgrammieraufwand wand verbunden. verbunden. DieDie in CANoe in CANoe integrierintegrierte te Programmierspache Programmierspache CAPL CAPL dient dient dem dem schnellen schnellen Programmieren Programmieren desdes SteuergeSteuergeräteverhaltens. räteverhaltens. Alternativ Alternativ ist ist es möglich, es möglich, dasdas Steuergeräteverhalten Steuergeräteverhalten in einer in einer DLLDLL zu zu kodieren, kodieren, diedie man man in die in die PrototypenumgePrototypenumgebung bung unter unter CANoe CANoe einbindet. einbindet. Auch Auch MatMatlab/Simulink-Modelle lab/Simulink-Modelle sind sind integrierbar. integrierbar.

Testen Testen in in mehreren mehreren Stufen Stufen

DerDer Prototyp Prototyp in der in der CA-CANoe.CANopen-UmgeNoe.CANopen-Umgebung bung entspricht entspricht dem dem späteren späteren realen realen System. System.

Nach Nach Fertigstellung Fertigstellung desdes PrototypensysPrototypensystems tems folgen folgen diedie notwendigen notwendigen Tests Tests für für dasdas gesamte gesamte Projekt. Projekt. CANoe CANoe unterstützt unterstützt denden Anwender Anwender hierhier sowohl sowohl beim beim Erstellen Erstellen derder Tests Tests alsals auch auch beibei derder Aufzeichnung Aufzeichnung und und Auswertung. Auswertung. DieDie fürfür einein CANopenCANopenSystem System erforderliche erforderliche Testfunktionalität Testfunktionalität umfasst umfasst mehrere mehrere Stufen. Stufen. �� Protokollebene: · Protokollebene: · DieDie Tests Tests aufauf dieser dieser Ebene Ebene stellen stellen sicher, sicher, dass dassdiedieCANopen-spezifischen CANopen-spezifischen KomKommunikationsprotokolle munikationsprotokolle derder einzelnen einzelnen Ge-Geräte räte innerhalb innerhalb desdes Gesamtsystems Gesamtsystems ge-gemäß mäßderderSpezifikation Spezifikation implementiert implementiert sind. sind.

03-2008 03-2008 Hüthig GmbH, Heidelberg, Heidelberg, im im Auftrag Auftragdes desKunden KundenVector VectorInformatik Informatik 10/41

KOMMUNIKATION

� Kommunikationsebene: Hier geht es nicht um die Richtigkeit des Protokolls, sondern um die korrekte logische Abfolge der (unabhängigen) Protokollsequenzen, zum Beispiel bei der Konfiguration von PDOs. Die Beschreibung der PDO-relevanten Einträge im Objektverzeichnis muss eine bestimmte Reihenfolge einhalten. � Applikationsebene: · Applikative Tests prüfen den Zusammenhang zwischen den Prozessgrößen. Damit solche Zusammenhänge überhaupt feststellbar sind, bedarf es mehrerer Voraussetzungen. Einerseits sind die Prozessgrößen über PDOs auszutauschen und andererseits muss das System komplett konfiguriert sein. So lässt sich zum Beispiel der Zustand eines Ventils in Abhängigkeit einer Temperatur oder eines Drucks prüfen. Zur Formulierung des Tests ist also Anwender-Know-how erforderlich.

Testprozeduren erstellen und ausführen

Testabläufe formuliert der Anwender unter CANoe mithilfe der integrierten Programmiersprache CAPL. Jedes CAPL-Testmodul repräsentiert einen separaten Test bestehend aus einzelnen Testfällen, die wiederum mehrere Testschritte umfassen. Während des Testlaufs arbeitet CANoe die einzelnen Testfälle sequenziell ab. Eine geeignete Testablaufsteuerung erlaubt das Überspringen oder Wiederholen einzelner Tests. Gleichzeitig lässt sich – quasi im Hintergrund – die Einhaltung weiterer Bedingungen und Einschränkungen überwachen. Sinnvoll ist dieses Vorgehen, wenn während des Wartens auf eine bestimmte Nachricht von Interesse ist, ob eine bestimmte andere Nachricht zyklisch am Bus gesendet wird. Insbesondere bei automatisierten Tests ist es wichtig, die Ergebnisse der einzel-

nen Testschritte detailliert zu protokollieren. Weitere CAPL-Funktionen übernehmen das Schreiben von Testergebnissen in eine XML-Datei zur späteren Weiterverarbeitung. Testabläufe für CANoe lassen sich auch unter XML spezifizieren. Dies bietet Vorteile, wenn eine Vielzahl gleichartiger Testabläufe mit einem Werkzeug zu generieren sind. CANoe nutzt deshalb eine Reihe von in XML spezifizierten Testpatterns und verarbeitet diese entsprechend.

�

infoDIRECT

779iee0308

www.iee-online.de � Link zum Testwerkzeug

Mehr Informationen zur kompletten Vector Lösung für CANopen finden Sie unter: www.canopen-solutions.de oder in einem persönlichen Gespräch mit einem CANopen-Experten: Vector Informatik GmbH Ingersheimer Str. 24 > 70499 Stuttgart > Tel. +49 (0) 7 11 80 67 00

10/42

MED Management Requirements Engineering

Lean Requirements Engineering T

raditionelle Entwicklungsprozesse, die Innovation und Qualität über einen schwerfälligen Prozess erreichen, sind nicht mehr zeitgemäß. Die Trend-Umfrage 2015 von Vector Consulting Services zeigt ganz klar drei wesentliche Ziele in der Produktentwicklung :

+ + +

Komplexität beherrschen Innovation rasch umsetzen Konnektivität und durchgängige Prozesse.

Studien unserer Experten bestätigen zudem, dass gerade in kritischen softwareintensiven Systemen die Kosten für Nacharbeiten über den Produktlebenszyklus hinweg durch eine Verbesserung des Requirements Engineering um 30 bis 50 Prozent gesenkt werden können. Wie das ganz konkret gehen kann, zeigen wir anhand einer Fallstudie aus der Medizintechnik. Zunehmend setzen Unternehmen ihre Entwicklung auf Diät. Kostensenkung ist das dominierende Ziel, aber es geht auch um kürzere Projektzeiten, schnellere Umsetzung von Innovationen und das Bestehen im weltweiten Wettbewerb. Lean und agil bedeuten, gegebene Ziele mit einem schlanken und flexiblen Prozess zu erreichen. Die Fallstudie zeigt, wie Lean Requirements Engineering (LeanRE) ganz entscheidenden

Software-intensive kritische Systeme in der Medizintechnik stehen unter einem immensen Marktdruck. Einerseits müssen sie kompromisslos innovativ sein, andererseits wächst der Effizienzdruck durch immer kürzere Zykluszeiten. Die Antwort heißt mehr Produktivität durch schlanke und effiziente Entwicklungsprozesse.

11/0

MEDengineering 3-4/2015

Einfluss auf die Kostenoptimierung hat. Grundlage dafür war die Umsetzung von Lean Development in der Medizintechnik. Um langwierige Entwicklungs- und Zulassungsprozesse abzukürzen ändern viele Unternehmen ihre Entwicklungsansätze in Richtung iterativer und Concurrent-Engineering-Ansätze. Ohne ein systematisches Requirements Engineering allerdings ist die Wahrscheinlichkeit hoch, dass ein Projekt scheitert. Werden beispielsweise die Qualitätsanforderungen missverstanden, entstehen Probleme in der Benutzbarkeit und der Performanz. Ärzte und Krankenpfleger sind Entscheidungsträger für oder gegen ein Produkt. Ist das Produktportfoliomanagement von der Entwicklung entkoppelt, passen die Funktionen nicht zu den Marktanforderungen. Anforderungsänderungen werden erst zu spät erkannt und führen zu unnötigen Non-Conformance-Kosten. Da klinische Abläufe aufgrund der hohen kombinatorischen Komplexität und einer eher geringen Standardisierung sowie ihres Ad-hoc-Charakters nur schwer zu modellieren sind, muss das Requirements Engineering spezifische Techniken für die Medizintechnik und das Gesundheitswesen entwickeln. Wir wollen den Nutzen des systematischen Requirements Engineering anhand der Entwicklung einer bildgebenden Plattform für die Medizintechnik darstellen. Dabei ging es um ein verteiltes IT-System, das je nach Anwendungsfall für Krankenhäuser optimiert wird. Es umfasste mehr als fünftausend Anforderungen und hatte mehrere hundert Entwickler an unterschiedlichen Standorten weltweit. Lean Development wurde mit Requirements Engineering kombiniert, um die Anforderungen kundenorientiert zu spezifizieren und schrittweise zu verfeinern. Der Anspruch einer klaren Feature-Orientierung wurde mit Produktlinien des Requirements Engineering umgesetzt. Startpunkt für die Verbesserung war eine Analyse der bisherigen Vorgehensweise. Es wurde festgestellt, dass sie an verschiedenen Stellen nicht mehr skalierte, insbesondere bei vier Punkten: Die Struktur der Arbeitsergebnisse in der Entwicklung hatte zu wenig Bezug zu den Produkteigenschaften, wie sie am Markt gefordert, kommuniziert

58

KONTAKT Vector Consulting Services GmbH D-70499 Stuttgart Tel.: +49-711-80670-1525 Fax: +49 711 80670-444 www.vector.com/medizin

www.med-eng.de

Der Grenznutzen der neuen und geänderten Funktionen muss zu jedem Zeitpunkt nachvollziehbar sein.

und genutzt werden und erlaubte damit keine Bewertung des Marktnutzens und spezifischer Optimierungen, beispielsweise für wirksameres Produktmarketing. Die gewachsene Architektur war komplex, da sie sich unabhängig von Produkteigenschaften und Feature-Sichten entwickelt hatte. Die etablierte Vorgehensweise nach dem V-Modell war zwar sinnvoll für eine schrittweise und klar spezifizierte Ergebnisstruktur, insbesondere auch aus Sicht der Zulassung, aber sie war zu wenig flexibel für spätere Änderungen. Außerdem war die notwendige Handhabung von Änderungen auf Basis einer Rückverfolgung (Traceability) sehr komplex und verursachte einen hohen manuellen Zusatzaufwand. Auf Basis dieser Beobachtungen wurde der Lebenszyklus behutsam angepasst. Im Unterschied zu typischen Inkrementstrukturen, die aus den Anforderungen anhand von Abhängigkeiten abgeleitet werden, war unser Schwerpunkt ein direkter Bezug zur Anforderungsentwicklung. Der implementierte Ansatz „Feature-oriented Requirements Engineering“ auf Basis der Grundprinzipien von Lean RE hatte hier die folgenden Schwerpunkte:

+

+

+

Feature Modell, das für Abhängigkeitsbeziehungen nach innen (zum Beispiel Variantenmanagement, Test, Dokumentation) und nach außen (zum Beispiel Marketing, Produktmanagement) gepflegt wird und im Zentrum aller Engineering-Artefakte steht. Nutzenorientierte Bewertung aller Features, um den wirtschaftlichen Aspekt des Lean Development ab der Anforderungsermittlung über die Priorisierung bis zur Lieferung immer im Fokus zu halten. Der Grenznutzen der neuen und geänderten Funktionen muss zu jedem Zeitpunkt nachvollziehbar sein. Grafische Modellierung der Workflows, um jede Anforderung nachvollziehen und Abhängigkeiten sowie Fehler schnell identifizieren zu können. Der Kundenutzen muss anhand der Workflows in der Sprache der Nutzer greifbar sein, denn nur damit ist ein marktorientierte Produktentwicklung und Positionierung möglich.

www.med-eng.de

Architekturbasierte Modellierung schafft eine klare Verknüpfung zwischen der Außensicht und der Innensicht und damit Konsistenz ohne Overheads. Aus dem Feature Modell wurde das bestehende Architekturmodell angepasst, um die Verknüpfung zu jedem Zeitpunkt sicher zu stellen, und um Variabilität modellieren und vereinfachen zu können. Unsere Erfahrungen mit Lean RE im Umfeld der Medizintechnik lassen sich gut übertragen. Hier die wesentlichen Erfahrungswerte in der Umsetzung von Lean Requirements Engineering in die praktische Projektarbeit: 1. Trennung von Problem- und Lösungsraum. Die Entwicklung einer Lösung beeinflusst die Sicht auf eine Problemstellung. Mit der sauberen Trennung des Problem- und Lösungsraums werden die späteren Änderungswünsche effektiv reduziert. Damit hatten wir die Möglichkeit, eine Impact-Analyse durchzuführen, damit die Änderungen in der Architektur abgeschätzt werden können. 2. Mehr Verständnis von Kundenanforderungen. Kunden haben oft ein implizites komplettes Verständnis für die Anforderungen. Jedoch sind sie manchmal kaum in der Lage, diese präzise zu artikulieren. Sie wollen einen Nutzen erreichen, der allerdings noch in Spezifikationen umgesetzt werden muss. Dazu sollten Anforderungen so früh wie möglich verfeinert werden. Wir nutzen dazu ein Glossar, das immer den Bezug zur Benutzersprache gewährleistet, sowie Rapid Prototyping zur Erstellung von Konzepten für Benutzerschnittstellen. 3. Storyboards für Workflows mit hohem User-Interface-Anteil. Dabei dient das Storyboard als Container für Anforderungen, User-Interface-Visualisierung sowie Testfälle. Es erlaubt, den Erfolgsfall sowie die Fehlerfälle darzustellen, und wird mit Time-Boxing iterativ verfeinert. 4. Strukturierte Anforderungen zur Planung und Budgetierung. Am Projektanfang muss der Aufwand zur Strukturierung investiert werden. Entsprechend der eignen Erfahrung sollten Projektmanager etwa 8-10 Prozent des Projektbudgets veranschlagen. Damit werden Abhängigkeiten zwischen

59

MEDengineering 3-4/2015

» 11/1

MED Management Requirements Engineering Fazit

Startpunkt für die Verbesserung war eine Analyse der bisherigen Vorgehensweise.

Funktionen besser verstanden und dadurch Fehler aus unverstandener Komplexität verringert. Nach unseren Erfahrungen ergibt sich die geeignete Anforderungsstrukturierung nach der dritten bis vierten Verfeinerung. Damit erreicht man eine Stabilität für die weitere Entwicklung des Projekts. Die Anforderungen sollten am besten entlang bestimmter funktionaler, also klinischer, Domänen hierarchisch organisiert werden. 5. Entwicklung eines geeigneten Modells zur Nachverfolgbarkeit. Ad-hoc-Verknüpfungen zwischen Anforderungen und Ergebnissen von der Spezifikation bis zu den Testfällen und der Dokumentation ohne klare Strategie reduzieren die Qualität und erhöhen Nacharbeiten. Daher muss die Nachverfolgbarkeit mit einer klaren Zielstellung und inhaltlichen Orientierung aufgebaut sein. Sie sollte die nötigen Artefakte, die verknüpft werden müssen, definieren, deren Granularität vorgeben sowie Mechanismen zur Methodik und deren Umsetzung in Werkzeuge beschreiben. Dies ist bei medizinisch-technischen Anwendungen von entscheidender Bedeutung für die Zulassung zum Markt. Wesentlich ist die Pflege der Abhängigkeitsbeziehungen. Wir empfehlen, die Verantwortungen vorab festzulegen und den nötigen Aufwand einzuplanen. Damit ist eine frühzeitige Einflussanalyse sowie Fortschrittsmessung, Kostenkontrolle (Earned Value) und Testfortschritt auf Basis der Abdeckung erreichter Anforderungen möglich.

Die Einführung und systematische Umsetzung von Lean Requirements Engineering braucht Aufwand sowohl in der Entwicklung als auch an ihren Schnittstellen, also Produktmanagement, Produktmarketing und Vertrieb. Häufig wird dieser Aufwand als zu hoch und zu zeitraubend gesehen, so dass die Anforderungen weiterhin ad-hoc in das Projekt hineinpurzeln und dort bruchstückhaft und mit vielen Nacharbeiten umgesetzt werden, bis einmal mehr das Projekt seine Ziele verfehlt oder abgebrochen werden muss. Aus verschiedenen Veränderungsprojekten kennen wir das Dilemma: Verbesserungen in Methodik, Prozessen, Ausbildung und Werkzeugen werden nicht angegangen, da der Anfangsaufwand, um diese Verbesserungen anzustoßen als zu hoch betrachtet wird. Daher ist es notwendig den Nutzen von Lean Requirements Engineering quantitativ zu erfassen und den Nachweis zu führen, dass sich der Aufwand für das Requirements Engineering lohnt. Eine durchgeführte Kosten-Nutzen-Rechnung in der betrachteten Fallstudie zeigt, dass der Feature-orientierte Requirements Engineering Ansatz etwa 15 bis 20 Prozent eines jährlichen F&E Budgets einsparen kann. Der Nutzen eines guten Lean Requirements Engineering kann an verschiedenen Faktoren festgemacht werden. Einige dieser Faktoren, wie Termintreue oder weniger Nacharbeiten, schaffen einen unmittelbar greifbaren Nutzen. Andere, wie beispielsweise die Kundenzufriedenheit sind eher opportunistisch und werden in Form nachhaltig guter Kundenbeziehungen und weiterer Projekte greifbar. Insgesamt zeigen unsere Erfahrungen, dass eine Verdoppelung des Aufwands für Requirements Engineering hin zu zehn Prozent des Projektaufwands in den Bereichen Methodik, Prozesse, Training und Werkzeugunterstützung konkret realisierbarem Projektnutzen von über 20 Prozent schaffen. Das ist ein ROI von mehr als 4, und damit sind nur die direkt messbaren Vorteile berücksichtigt.

6. Disziplinierte Nutzung von Standards und Reviews. Nur mit klaren internen Vorgaben zum Requirements Engineering, den Arbeitsergebnissen sowie Vorgehensweisen und Verantwortungen sind die Ergebnisse nachher konsistent und können produktübergreifend für die Lösungsentwicklung, wie sie im klinischen Bereich heute üblich ist, wirtschaftlich genutzt werden. Wir empfehlen den Einsatz von Industriestandards, die an die Notwendigkeiten des Projekts angepasst werden. Dokumentenvorlagen erlauben die Einhaltung von Dokumentationsstandards. Zudem stellen Standards die nötige Routine für die Reviews von Anforderungen sicher, die häufig im Projektdruck vernachlässigt werden – mit der Folge von aufwendiger und zeitraubender Nacharbeit.

11/2

MEDengineering 3-4/2015

Arnold Rudorfer ist Programmmanager für die Entwicklung einer Systemplattform bei Siemens Healthcare Diagnostics.

Dr. Christof Ebert ist Geschäftsführer der Vector Consulting Services.

60

www.med-eng.de

Improving Engineering Efficiency with PLM/ALM

be understood and optimized with the impacted engineers.

are the right engineering processes and if they are auto-

Rising cost pressure is forcing manufacturers and their suppliers to jointly and consistently master product development.

An efficient electronics development builds upon stream-

mated and instrumented with appropriate tools [1,2]. PLM/

lined processes that are understood and practiced by all

ALM integration has been a problem in the industry for a

engineers, because workflows are well orchestrated and

long time. On the one hand, customers generally do not re-

optimally support engineering tasks. Success with ALM and

place their favorite point solutions, such as Jazz and

PLM implies that processes and tools are simultaneously

TeamCenter, requirements management with PTC Integrity,

Our industry case study shows how a leading automotive OEM over time has achieved effective interaction of engineering processes, tools and people on the basis of product and application life-cycle management (PLM / ALM). Its scope is first an introduction to PLM/ALM on the basis of a model driven engineering (MDE) for one or several products or product families. Second, PLM and ALM need tool support to the degree necessary to ease handling and drive reuse and consistency. Third, introducing MDE needs profound change management. Starting from establishing the relevant engineering processes, we show how they can be effectively automated for best possible usage across the enterprise and even for suppliers. We practically describe how such a profound change process is successfully managed together with impacted engineers and how the concepts can be transferred to other companies. Concrete results for efficiency improvement, shorter lead time and better quality in product development combined with better global engineering underline the business value.

improved.

development tools like Matlab/Simulink or Rhapsody, and

We will show with this article how engineering processes

replace them with a single suite from one vendor. Even where

can be improved and automated, thus enhancing efficien-

the PLM/ALM part is replaced with a single suite, there are

cy, quality and lead time. Such changes need leadership

often other tools to integrate with, such as defect tracking,

and good orchestration to be successful. We therefore

change management, document management, etc.

show how a sustainable change process is successfully

To work efficiently, engineers need to handle a multitude of

managed together with impacted engineers and how the

processes and different forms of knowledge to be shared

concepts can be transferred to other companies.

with colleagues across business processes and even beyond the borders of the enterprise [1]. PLM/ALM helps to inte-

11/4

1. Improving Efficiency with Better Engineering Processes

stakeholders with individual knowledge about projects,

2. Product Life-Cycle Management

grate those along the entire life-cycle of a release or prod-

Companies and entire industries are changing very fast at

products and processes. As a result, engineering results

Product Life-Cycle Management (PLM) and its equivalent

uct or beyond to an entire portfolio as is illustrated in Fig-

this time.

such as specifications, documentation and test cases are

in software, namely Application life-cycle management

ure 1. Many companies have realized in this fierce climate

Software and IT are the main drivers of innovation. Soft-

inconsistent, items like signals and parameters are arbi-

(ALM), is the overall business process that governs a prod-

that their traditional rather organically grown tools land-

ware-intensive systems as used in automobiles, aircraft,

trarily labeled, changes create lots of extra work to make

uct or service from its inception to the end of its life in order

scape with isolated unconnected processes not only won’t

medical, transportation, utilities and industrial automation

sure that nothing is overlooked, and reuse is hardly possible

to achieve the best possible value for the business of the

scale up but also limit their engineering productivity due to

deliver today 50-70 percent of the value of these solutions,

due to the many heterogeneous contents. This pattern is

enterprise and its customers and partners. PLM/ALM com-

manual data exchange, too much rework, inconsistencies

and this will further grow. The products and solutions must

amplified when collaboration across supplier networks

bines processes, people and tools for the effective engi-

and insufficient reuse across products and platforms

meet increasing quality requirements, but must be devel-

comes into the picture, as it is today normal in systems de-

neering of products – from their inception until end of service.

(Figure 1, left side). A federation of processes and support-

oped cost-efficiently, should be easily adaptable to new en-

velopment.

It involves tacit knowledge of experts and explicit knowl-

ing tools with clear responsibilities improves efficiency by

vironments and must effectively exploit the advantages of

A brief example shows the significance. A supplier is intro-

edge, codified in procedures, process and tools. PLM/ALM

more consistency, quality, reuse and not the least employee

modern technologies. At the same time new competitors

ducing MDE based on some methodology, processes and a

stretches from know-how to know-what and know-why.

motivation (Figure 1, right side).

are pushing new solutions on the market, and the technol-

modern tool environment that enables seamless collabora-

There is a huge misconception that PLM/ALM is a product

PLM/ALM needs both process and tools support. Figure 2

ogy landscape is increasingly cluttered.

tion across development centers and with partners and

not a process. By definition, it is the process by which orga-

shows this relationship based on a study at London Busi-

This economic climate enforces two trends in engineering

customers. In advance, cost-effectiveness was evident be-

nizations manage the creation, deployment, and operation

ness School [1,2]. The horizontal axis portrays the degree of

across industries, namely fast innovation and also cost ef-

cause the system was going to provide faster access to

of software over its full lifecycle. In practice, PLM/ALM has

tools support in an engineering environment, while the ver-

ficiency. Companies invest in growth through innovation by

data and less defects and budget overruns due to improved

been associated with tooling suites aimed at managing the

tical axis shows to which degree the processes are opti-

developing new products and solutions. At the same time

change and configuration control. After the introduction

tasks of this lifecycle, but vendors have rarely delivered on

mized. All four combinations of high versus low have an

they are aware of the volatile market situation and thus

phase however, a MDE tools environment was available,

the promise of integrating the management of the full ap-

associated impact on engineering productivity. Obviously

challenge their development teams worldwide to be as lean

but did not deliver useful models. Engineers were still draw-

plication lifecycle. PLM/ALM is only cost-effective if there

the upper right quadrant shows best performance impact,

and efficient as possible. A senior R&D manager of a lead-

ing their previous style pictures, without much modeling

ing automotive tier 1 supplier summarized it as follows:

methodology. What happened? The tool was designed to

“Cars sell in quantities we have never seen. Markets around

support development and was integrated into the compa-

the world are keen to get latest technology with their cars

ny-wide PDM system. Electronic developers but also prod-

such as energy efficiency, functional safety or internet ac-

uct managers and project leaders could not work with it

cess. But we have learned our lessons from the recent re-

and created parallel systems for their documents, which

cession and made engineering and production flexible to

they exchanged between one another using traditional

immediately react if sales drop.”

methods. The solution would have been simple if it had

There are numerous levers for engineering efficiency im-

been made clear, before introducing the new tool, which

provement. Many companies operate with distributed

processes had to be supported and how these processes

PLM: Connecting processes, persons and tools Traditional

PLM

Design Impl.

Unit test

Integration

with heterogeneous interfaces, redundant and inconsistent

An objective-driven tool introduction, which achieves mea-

data management and insufficient transparency which re-

sureable improvements and is accepted by engineers, re-

sults have been achieved and what needs still to be done.

quires good preparation and implementation. Normally,

Configurations

The underlying root cause is the lack of a shared conceptual

multiple departments or entire divisions are affected by a

model of the product. In consequence, activities such as

change of engineering and tools processes. Before debat-

PDM, CM, defects, documents, etc.

project management, pre-development and product engi-

ing tools solutions, the processes have to be under control

neering are rarely integrated well due to the diversity of

and the envisaged workflows and work organization must

Project management Project data

Marketing

Economic thinking and behaviors

Communication, negotiation

Leadership

Team work, collaboration

Self management

Technology understanding

Maturity / accountability / trust

Design CAD, Code, modelling Collaboration ERP, Wikis, File systems

Tools

Project management Supplier management Requirements management

Architecture, development

Validation, integration

Service

had to be first improved and then automated.

Innovation and change

Product mnmt

teams leading to fragmented processes and tool chains

Strategy

Processes

Organically grown tools

Marketing

Req. Spec.

Competences

People

Fragmented tasks

Change control, configuration management

Figure 1: PLM integrates processes, people and tools for effective engineering

11/5

Improving Engineering Efficiency with PLM/ALM

namely 20%. Introducing the right process first and em-

> Variant management and product line engineering for

create additional frictions and delays. Our consulting proj-

way of developing and acquiring information. Further the

phasizing its understanding in engineering has a higher val-

effective reuse > Support for quality requirements such as functional

ects show that the root cause is often the same: Implemen-

information was spread over several data sources and a

tation of efficient processes with adequate tools support

common version control was not really possible.

ue (upper left field), than pushing an engineering tool without profound process understanding (lower right field).

safety from requirements to concept, models, realization

with sustainable results requires profound change man-

Objectives and Solution Approach: The objectives were to

Note that the values of course depend on the specific sce-

to validation, proof and acceptance

agement – which is rarely taken into account. To manage

increase the engineering efficiency, the quality and consis-

nario and environment. What matters here is the ratio be-

such change and to ensure that impacted engineers not

tency of the working products and to shorten the existing

tween the four fields.

There are different ALM/PLM environments available today

only pay lip service but actively support and buy into the

lead times in the electronic engineering. The solution ap-

Tuning processes, improving project management, and

on the market, such as the general purpose solutions from

new processes and tools, their needs and typical work flows

proach was to implement a seamless information manage-

establishing visibility on new product introduction – tech-

Dassault, Siemens, and PTC which had evolved from me-

must be understood to avoid that process overheads and

ment of engineering data from function to software and

niques well described by common improvement frame-

chanical engineering with design and product data man-

heavy tools solutions hinder their creativity. This implies

hardware. That is, centralized information (i.e. model)

works, such as CMMI [4] – will not yield sustainable bene-

agement, and IBM and Vector with specific solutions hav-

pro-active preparation way before a tool decision is made

management in a distributed and decentralized engineer-

fits if not adequately supported by tools. The prospect of

ing grown from software centric applications. We will focus

and good leadership, coaching and support through pilots

ing process. The main characteristics of such a solution

new, high-margin products, combined with the delayed

in this case study on Vector’s PREEvision, a leading auto-

and roll-out.

were alignment of processes, single source of information

impacts of resource allocation decisions, seduce product

motive PLM solution, due to its use by the company which

We will show a case study from a leading automotive OEM

for collaborative teams, reusability of information, using

managers into starting more projects than their develop-

we portray. Like the other state of the practice PLM/ALM

how to successfully introduce PLM/ALM and modeling.

commercially available tools, and continuous development

ment resources can handle.

environments, it provides a complete tool suite of integrat-

Initial Situation: The main drawbacks of the initial situation

with consistent underlying models.

The scope of a PLM/ALM system is on the one hand the

ed data and process management modules [3] (Figure 3).

were non-connected tool chains and a document driven

Change process: To adequately support the introduction and

creation and management of engineering data in one com-

These state of the practice PLM/ALM solutions provide a

subsystem and component engineering process with a lot

change process we recommend a change methodology that

mon engineering data backbone and on the other hand the

repository and editor of different models (Figure 3, left

of manually managed interfaces. Therefore the organiza-

is adapted to specific business goals (Figure 4). PLM/ALM

management of processes. PLM/ALM as a concept and

hand side) and ways to link models to reality (Figure 3, right

tion had to deal with a time-consuming and expensive re-

introduction is a long term activity which has to be funded

solution applies to software engineering as well as to sys-

hand side). This allows both a process-oriented way of

views/rewriting process, a lot of redundancies and incon-

by sufficient competence and budget and competent inter-

tems or hardware products. It applies to different types

working (rigid) and a repository-based way of working

sistencies which often were not detected by these reviews,

nal resources. The necessity of a change must be accepted

and sizes of companies, because it is not prescribing a solu-

(flexible, all engineers share a bunch of models of the prod-

not standardized naming conventions and an ineffective

broadly in the organization and the reliable commitment of

tion suitable only for big companies but rather a clear focus

uct). Compared to the more traditional code generation

on processes along the life-cycle. We use it for complex

oriented MDE no process consisting of planned model

solutions with multiple hardware and software compo-

transformations is defined or required.

nents as well as simple software services.

Based on a rich and extendable data model for features

Today such environments need to satisfy a variety of needs

representing the logical and the physical system architec-

for integrated systems engineering, namely > Integrated business logic and one comprehensive data

ture and the software architecture, PLM/ALM systems

model for the entire E/E development process from

uration and change control, issues are connected to system

requirements, through system, SW- and HW-design to test.

data objects, the related realization date is fixed in the re-

provide highly integrated use cases. For instance in config-

> Architecture Design and Management

lease planning module, the implementation time and effort

> Collaboration environment for requirements and test

are planned in the project management module, the change

Engineering, modeling of functions, components,

of the related software parts are managed in the source

networks and communication

code management module and finally the test are planned

Tools without processes are nothing; processes without tools are not good enough

and executed in the test data module. Being able to not only reuse information but also guide engineers through complex tasks generates immediate re-

High

+ 8%

+ 20%

specifically during last-minute changes and corrections under time pressure. Or, consider the time and effort necessary to move engineers from one project to another. Having standardized PLM/ALM solutions around a standard product life-cycle reduces the learning curve to allow focusing on real technical challenges instead of organization

Low

Process focus

turns by making engineers more flexible and avoiding errors,

0

+ 2%

overhead. 3. Industry Case Study

Low

High

Figure 2: Tools without processes nothing; processes without Toolaresupport tools are not good enough

11/6

Integrated Development with PREEvision Product Lines

(Reuse, 150% Model, Variant Management)

Requirements (Links, Attributes)

Logical Architecture (Domains, log. Functions, Activity Chains)

Customer Features

Feature Function Network

Architecture and Design

(Use Cases)

SW Architecture

Mapping

(AUTOSAR, SW Components and Compositions)

(Decoupling of Layers, Variant Management)

SW Implementation

HW Power Concepts

(Simulink „Gray Box“, Parameter Values, Basis SWCs)

(incl. Fusing Concepts, …)

Communication

HW Grounding Concepts

(Data Element, Signal, PDU, Frame, Bus Schedule, …)

HW Components

HW Wiring Harness

(Internal Structure of ECUs, Sensors, Actuators, …)

(Cables, Connectors, Pins, …)

HW Network

HW Geometry

(Bus Topologies & Conventional Communication Connections)

(Packaging, Environmental Requirements, …)

HW Schematics (Electric Functions, Components, …)

Often the expected benefits from modeling and PLM/ALM

Consistency Checks

Reporting

(Document and HTML Generation)

Metrics

(Calculation of Quality Characteristics)

tools are often not visible. They are perceived as complex and employees are frustrated and continue working with their current work practices. New processes and interfaces

Figure 3: PREEvision solution

11/7

Improving Engineering Efficiency with PLM/ALM

users and initiating “Jump Start Projects”. In these projects

Introduce model-based development intelligently and

ness case is clear: With a degree of 30 % for modeling, error

the main requirements of the customer and it must have

the client’s engineers were supported by well known and

step by step, focus on critical components, continuity of

rates and development costs are reduced significantly.

the potential to grow with the growing needs of the user

well with local specific engineering knowledge experienced

requirements to code and test cases, and improving

What did we achieve with PLM? Since we consider knowl-

base. The change partner must be reliable and the chemis-

consultants, which have been trained in PLM/ALM before.

processes in parallel.

edge management a regular management activity, we fol-

try between the main actors should secure the probability

Such "Jump Start Projects" are focused and have a pre-

the top management is a key. The process tool has to fulfill

lowed through like in other improvement projects by look-

defined duration (typical two months).

improvement. Measure the implementation, and try in

ing into performance results from real projects, as well as

Lessons Learned: Utilizing a consistent product life-cycle

each project ten to twenty percentage points improve-

some process-related aspects, such as knowledge utiliza-

But if they are true success is not necessarily guaranteed.

and process repository is a necessary condition for reducing

ment, at the spots where you want to put accents, for

tion. We found improved quality, reduced cycle time, im-

Resistance out of the organization, lack of money, changes

cycle time, as they reduce frictions of unclear interfaces

example 20% less cost variations, or 10% less cost in the

proved engineering flexibility, reduced overheads improved

in priorities, pressure from the user groups, theoretic dis-

and responsibilities as well as cutting rework because of in-

test.

communication, increasing alignment of processes and

cussions – these are not the exceptions, these are normal

consistent assumptions and cutting retrieval time for spe-

influences in such a project. The partners have to be able to

cific documents and work products. In implementing PLM/

These lessons learned apply to various type of change

tially improved visibility and aligned terminologies and roles

deal with it and put the best personnel in the position of

ALM and modeling support we found the following lessons

during the introduction and roll-out of PLM/ALM. They can

already brought huge gains, as they facilitate a borderless

learned: > Concept: First improve the process then the tools based

be generalized for PLM/ALM introduction, or they can be

solution building inside the company.

specifically adapted for a micro-level change, such as a

What is next in PLM/ALM? Knowledge management must

change of a modeling methodology.

be better linked to business. Aligned business objectives

to realize a true long term partnership. These are all necessary conditions for success. If one is a false, failure result.

project leaders and methods/process engineers. Our customer made good experiences with an iterative-incremental development process – short implementation cycles,

on concrete improvement objectives that are set,

early validation with a small group of well experienced pilot

measured and used to correct deviations. Ensure consis-

tools, and faster ramp-up time and skill management. Ini-

and metrics must guide and monitor the development pro-

tency of features and products with a strong systems

5. Summary and Conclusions

cesses, the product lines and the project teams. Take as an

engineering. Specifically in distributed collaborative

For most companies, there is a wealth of untapped oppor-

example a mobile phone or game design with lots of em-

In the rollout phase normally a small group of convinced

environments we see huge benefits from a single data

tunities to cut costs from their development projects. This

bedded software. Being a commodity, business-oriented

pilot users are facing a big group of engineers, which are

backbone for consistent requirements, specs and models

efficiency levers are sometimes obvious, such as incom-

targets cover return rates or brand loyalty. Defects increase return rate and reduce brand loyalty with devastat-

users and a professional change management guaranteed mature deliveries for productive use.

to invest on the one hand more upfront time for learning

across all changes > Development: Evaluate tools under realistic conditions.

plete and wrong information exchange in a distributed product engineering project. At times they are less obvious,

ing business impacts. Looking to projects, products and

the new environment and to have challenging objectives for

Agree specific requirements to the process and tools

for instance if engineering teams work on different vari-

processes will improve the design away from overly narrow

their normal work products on the other hand .Further-

which are then used to drive changes. Support the inter-

ants that emerge only late during system test or product

focus on manufacturing aspects towards usability engi-

more, migration to a new way of working often includes

faces to the various components and processes through

pilots, such as it was reported from a recent multinational

neering. Knowledge and experience from past projects will

"clean up" of older specifications, which also requires ef-

traceability, automatic consistency checks and test

airplane project.

be embedded into the underlying design processes. We

fort. And there is the small group of engineers, who are

automation.

Inefficiencies are rampant when engineers are distributed

stress the need for adequate knowledge management as a

globally and many different tools being used. Concrete

basis for success in product and solution development – an aspect going well beyond most PLM/ALM approaches of

open for the change in principle, but they are in the conflict

convinced, that the current, traditional way of working is

> Deployment: Manage the changes as they impact the

the optimum and that there is no need for a change at all.

entire organization. Pilot changes, coach and train

efficiency and quality improvements with reduced rework

We managed this situation with special trainings for key

engineers, highlight power users that will set the pace.

and faster throughput have been showed by applying con-

today.

sistent PLM/ALM and modeling support. The efficiency and

We should not expect that all product and process knowl-

effectiveness of engineering processes directly influence

edge and modeling methodology can be codified and made

engineering cycle time. For instance earlier defect detec-

available via PLM/ALM. Personal contact will always be

tion in requirements or specs means faster and more com-

necessary to provide context and analysis. The support sys-

prehensive defect correction.

tem should therefore be extended to facilitate interperson-

Without consistent model-based methods and adequate

al communication and evolve towards a global who-is-who

PLM/ALM tools support engineering will be in deep prob-

not only at the operational product/project management

lems within a short time-frame. Increasingly complex re-

level but also at the tactical and strategic level.

quirements must be developed efficiently and with high

Correctness and completeness of the information is anoth-

quality throughout from system engineering to compo-

er aspect that needs to be worked on. We are convinced

nents. Working at a higher level of abstraction and auto-

this cannot be achieved by imposing a reporting discipline

mation will improve productivity and quality. Model-based

only. It can only truly be achieved by ensuring that the pro-

development will play a crucial role in this evolution. The

vider of information is directly benefiting from making the

companies we work with share the same goals: Mastering

information available. This can be achieved to continuing to

complexity, improve product quality, shorten development

evolve the system to ensure information can be captured

time, and plan functions in different variations and versions

as early as possible when it is required at the lowest opera-

for better reuse. The biggest challenges they see are their

tional level, e.g. by supporting period project reporting in

own learning curves and to keep consistency across fea-

presentation format to avoid information is presented first

tures and products. Systems engineering still is undervalued

a set of slides for the project review before it is entered in

and too often decoupled from application development.

the system.

Roadmaps are maintained only for subsystems, and thus

Embarking on a state of the practice PLM/ALM solution

create variants with an overwhelming complexity. The busi-

combined with strong change management triggered by

Vector change model for successful PLM introduction PLM Concept > Analysis: products, processes, tools > Benchmarking: competitors, suppliers, trends > Requirements: Use cases, gaps > Business Case > Measurable objectives

PLM Development > Life-cycle processes: roles, work products, workflows, data models, interfaces > Evaluation criteria > Planning > Commitments (pilot, deployment) > Tool decision

PLM Deployment > > > > > > > >

Piloting Adaptations Power user Incremental introduction Communication Migration of legacy tools Validation vs. requirements Tracking objectives, cost / benefit

Change management

11/8

> Operations: Support users and ensure continuous

PLM Operations > Tool and process support > Incremental coverage of all product lines > Coaching > Ensuring sustainability > Optimization > Enhancements

Figure 4: Vector change model for successful PLM introduction

11/9

external support had helped to sustainably achieve the anticipated efficiency effects in the different engineering processes across the product life-cycle. Keywords: ALM, Application Lifecycle Management, PLM, Product Lifecycle Management, Efficiency, Industry Voice Literature: [1] Ebert, C. and J. De Man: Effectively Utilizing Project, Product and Process Knowledge. Information and Software Technology (IST), ISSN: 09505849, Vol 50, No. 6, pp. 579-594, 2008. [2] Ebert, C. and R. Dumke: Software Measurement. Springer, Berlin, Heidelberg, New York, 2007, revised edition 2016 [3] PREEvision. http://www.vector.com/PREEvision [4] Chrissis, M.B., M.Konrad and S.Shrum: CMMI. Guidelines for Process Integration and Product Improvement, ed. 3. Addison-Wesley, Reading, USA, 2011. Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world to sustainably improve product strategy and product development and to manage organizational changes. Prior to that, he held global management positions for ten years at Alcatel-Lucent. Dr. Ebert serves on a number of advisory and industry bodies, teaches at the University of Stuttgart and has authored several books including his most recent book “Global Software and IT” published by Wiley. Contact him at [email protected]

Contact: Dr. Christof Ebert, Vector Consulting Services Ingersheimer Strasse 24, D-70499 Stuttgart, Germany. Ph.: +49-711-80670-1525 Fax: +49-711-80670-444 Company: www.vector.com/consulting

11/10

Technische Fachartikel

zur Entwicklung von Embedded Electronics

Mehr Informationen

www.vector.com

6. Auflage | Deutsch

V 6.0 10/2016 - pressbook_de

Besuchen Sie unsere Website für: > News > Produkte > Demo Software > Support > Schulungen > Adressen

Vector – Automotive. Embedded. Engineering.