MICROSAR Produktinformation Deutsch - assets.vector.com · MICROSAR 4 1 MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software MICROSAR ist die AUTOSAR-Lösung von Vector

MICROSAR

Produktinformation

MICROSAR

2

Inhaltsverzeichnis

1 MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software ............................................................................ 4

2 MICROSAR.OS ........................................................................................................................................................................ 10

3 MICROSAR.COM – AUTOSAR Basissoftware-Module für die Kommunikation ............................................................... 13

4 MICROSAR.CAN – AUTOSAR Basissoftware-Module für die CAN-Kommunikation ....................................................... 17

5 MICROSAR.FR – AUTOSAR Basissoftware-Module für die FlexRay-Kommunikation .................................................... 21

6 MICROSAR.LIN – AUTOSAR Basissoftware-Module für die LIN-Kommunikation ........................................................... 24

7 MICROSAR.ETH – AUTOSAR Basissoftware-Module für Ethernet-basierte Kommunikation ....................................... 27

8 MICROSAR.CHARGE – Basissoftware-Module für die Kommunikation mit externer Infrastruktur .............................. 32

9 MICROSAR AVB – Basissoftware-Module für die Audio-/Video-Kommunikation via Ethernet ..................................... 35

10 MICROSAR.MEM – AUTOSAR Basissoftware-Module für das Memory Management .................................................... 38

11 MICROSAR.SYS – Systembezogene Basissoftware Module für AUTOSAR ..................................................................... 41

12 MICROSAR.DIAG – AUTOSAR-kompatible Umsetzung der Diagnose Standards UDS, OBD und J1939 ...................... 46

13 MICROSAR.MCAL – AUTOSAR-Treiber zur Ansteuerung der Mikrocontroller-Peripherie .............................................. 52

14 MICROSAR.EXT – AUTOSAR-Treiber zur Ansteuerung von externen Bausteinen ........................................................... 57

15 MICROSAR.IO – AUTOSAR Input Output Hardware Abstraktion ..................................................................................... 60

16 MICROSAR.RTE – Die optimierte Ablaufumgebung für Softwarekomponenten nach dem AUTOSAR-Standard ....... 62

17 MICROSAR AMD – AUTOSAR-Monitoring und -Debugging ............................................................................................... 65

18 MICROSAR Lösungen ............................................................................................................................................................. 69

19 MICROSAR Safe – Sicherheit nach ISO 26262 bis ASIL D für Steuergeräte-Software ................................................... 70

20 MICROSAR Security – Zugriffssicherheit für AUTOSAR-Steuergeräte ............................................................................ 74

21 MICROSAR.HSM – AUTOSAR Basis-Software-Module für Hardware Security Module ................................................. 77

22 MICROSAR Gateway – Basissoftware für Gateway Steuergeräte ................................................................................... 82

23 MICROSAR Multi-core – Die AUTOSAR Lösung für Mehrkern-Prozessoren ................................................................... 87

24 MICROSAR Variantenhandling - Lösungen für flexible Konfigurationen in AUTOSAR .................................................... 90

25 MICROSAR J1939 – AUTOSAR Basissoftware-Module speziell für Nutzfahrzeuge ........................................................ 93

26 MICROSAR vVIRTUAL Target – Virtuelle Integration mit vVIRTUALtarget ..................................................................... 96

27 MICROSAR POSIX – Anbindung von AUTOSAR Classic an POSIX-Betriebssysteme .................................................... 100

28 MICROSAR.OTA – Basissoftware-Module für den Software-Download ........................................................................ 104

29 MICROSAR.IPC – AUTOSAR Basissoftware-module für Interprozessorkommunikation .............................................. 106

30 MICROSAR.SIP und MICROSAR.EIP – Der Schnelleinstieg in Ihr AUTOSAR Projekt ..................................................... 111

31 AUTOSAR Eval Package – Komplettpaket zur Evaluierung von AUTOSAR-Basissoftware und -Tools ....................... 115

32 Weiterführende Informationen ............................................................................................................................................ 119

V2.12.0 04/2019

Bitte denken Sie über Ihre Verantwortung gegenüber der Umwelt nach, bevor Sie dieses Dokument ausdrucken.

MICROSAR

3

MICROSAR

4

1 MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software

MICROSAR ist die AUTOSAR-Lösung von Vector für Ihre Steuergeräte-Software. MICROSAR besteht aus der MICROSAR.RTE

und den MICROSAR Basissoftware-Modulen (BSW), die den gesamten Umfang des AUTOSAR-Standards sowie viele Erweite-

rungen und Add-Ons abdecken. Jedes AUTOSAR BSW-Modul ist einem MICROSAR-Paket zugeordnet. Die detaillierten Be-

schreibungen der einzelnen Pakete entnehmen Sie bitte den folgenden Kapiteln. Die von Ihnen benötigten BSW-Module werden

von Vector für Sie individuell in einem „Software Integration Package“ (SIP) kombiniert und freigegeben.

Bild 1: Die MICROSAR Pakete enthalten alle Module des AUTOSAR 4.3 Standards.

Die Tabelle zeigt die Pakete von MICROSAR.

Paket Inhalt

MICROSAR AMD Monitoring und Debugging von Anwendung und MICROSAR-BSW

MICROSAR AVB Basissoftware-Module für die Audio- und Videokommunikation via Ethernet

MICROSAR MCAL Treiber zur Ansteuerung der Mikrokontroller-Peripherie

MICROSAR CAN Basissoftware-Module für die CAN-Kommunikation

MICROSAR COM Basissoftware-Module für die Netzwerk-unabhängige Kommunikation und Gateways

MICROSAR EXT Treiber zur Ansteuerung von externen Bausteinen

MICROSAR FR Basissoftware-Module für die FlexRay-Kommunikation

MICROSAR DIAG Basissoftware-Module für die Diagnose

MICROSAR.IO Bindeglied zwischen Mikrokontroller-Peripherie und Anwendung

MICROSAR ETH Basissoftware-Module für Ethernet-basierte Kommunikation

MICROSAR.LIBS AUTOSAR-Libraries

MICROSAR.LIN Basissoftware-Module für die LIN-Kommunikation

MICROSAR

5

Paket Inhalt

MICROSAR.MEM Basissoftware-Module für die Verwaltung von nichtflüchtigem Speicher

MICROSAR.OS Das Echtzeitbetriebssystem nach dem AUTOSAR-Standard

MICROSAR.RTE Optimierte Ablaufumgebung für Softwaremodule nach dem AUTOSAR-Standard

MICROSAR Safe (MICROSAR.CRYPTO, MICROSAR.HSM)

Sicherheit nach ISO 26262 bis ASIL D für Steuergeräte-Software, beinhaltet die Pakete MICROSAR.CRYPTO,

MICROSAR HSM und einzelne Module aus anderen Paketen.

MICROSAR.SYS Systembezogene Basissoftware-Module für AUTOSAR Steuergeräte

MICROSAR V2G Basissoftware-Module für die Kommunikation mit externer Infrastruktur

MICROSAR XCP Messen und Kalibrieren eines AUTOSAR-Steuergeräts mit XCP inkl. Transport-Layer für Ethernet, FlexRay und CAN

MICROSAR.OTA OTA steht für Over The Air.

Über die Pakete hinaus beinhaltet MICROSAR auch Lösungen für verschiedenste Fragestellungen, bei denen Module aus den

unterschiedlichsten Paketen betroffen sein können. Diese Lösungen sind in der folgenden Tabelle aufgelistet und werden im

Anschluss an die Beschreibung der Pakete näher erläutert.

Lösung Inhalt

MICROSAR.AMD

Das AMD-Paket vereinfacht das Testen und Analysieren von BSW- und Anwendungsfunktionen, indem es wichtige

Statusinformationen und Ereignisse an Tools wie CANape oder CANoe überträgt. Darüber hinaus bietet AMD die

Möglichkeit, Laufzeitmessungen an der BSW und den Anwendungsfunktionen durchzuführen.

MCROSAR GW

Gateways verbinden Steuergeräte über die heterogene Netzwerkarchitektur des Fahrzeugs hinweg.

Dabei muss ein Gateway die Leistungsbalance zwischen Durchsatz, Latenz und Ressourcenverbrauch managen und

gleichzeitig Flexibilität und Erweiterbarkeit in Funktion und Konfiguration bieten.

MICROSAR.HSM MICROSAR.HSM steht für effiziente Verarbeitung von kryptographischen Algorithmen sowie der Schlüsselverwaltung

für z.B. Secure Boot und Secure OnBoard Communication (SecOC).

MICROSAR J1939 J1939 ist ein etabliertes Kommunikationsprotokoll, das CAN für die Kommunikation in Nutzfahrzeugen und Genera-

toren und durch abgeleitete Standards in Land-, See-, Bau- und Forstfahrzeugen verwendet.

MICROSAR Multicore

Die Hauptmotivation für Multi-Core ist es, die verfügbare Rechenleistung zu erhöhen und Partitionierung für sicher-

heitskritische Anwendungen zu realisieren.

Beides kann mit der Multi-Core-Lösung MICROSAR, bestehend aus Basissoftware und Tooling, erreicht werden.

Die MICROSAR Multi-Core-Basissoftware konzentriert sich auf die zeiteffiziente Bereitstellung von BSW-Diensten

auf allen Cores. Ergänzt wird es durch das Tooling, das den Prozess des Deployments und der Laufzeitauswertung

unterstützt.

MICROSAR.OTA Das Paket MICROSAR.OTA enthält BSW-Module zur Verarbeitung, Speicherung und Aktivierung von Software-

updates für Ihr Fahrzeug. OTA steht für „Over the Air“.

MICROSAR POSIX

MICROSAR POSIX bietet Lösungen um AUTOSAR Basissoftware unter einem POSIX Betriebssystem zu betreiben.

So können Standardfunktionen, z.B. Diagnose oder bewährter Anwendungscode In POSIX-basierte Projekte über-

nommen werden.

MICROSAR Safe MICROSAR Safe ist Funktionale Sicherheit nach ISO 26262. Für den Einsatz der MICROSAR BSW in sicherheitsrele-

vanten Funktionen bietet Vector eine komplette Lösung für Ihr AUTOSAR-Steuergerät.

MICROSAR Security

MICROSAR Security ist die Vector Lösung für Automotive Cyber Security. Wir unterstützten Sie mit Embedded-Soft-

ware, Dienstleistungen und Werkzeugen, um eingebettete Systeme gegen Cyber-Angriffe abzusichern. Schützen Sie

Ihr Produkt wirkungsvoll und effizient und nutzen dazu unsere Kompetenz und unser Wissen.

MICROSAR Variant Handling

Um Logistikkosten bei AUTOSAR-Steuergeräten einzusparen, sind die MICROSAR Module mit Identity Manager er-

hältlich. Damit werden mehrere Konfigurationen (z.B. Linke- oder rechte Tür) im Steuergerät abgelegt. Dies ermög-

licht den mehrfachen Verbau eines identischen Steuergerätes innerhalb einer Baureihe oder in unterschiedlichen Bau-

reihen.

Das Add-On Post-Build Loadable erlaubt es, viele Parameter der BSW-Konfiguration nachträglich zu modifizieren,

ohne die Steuergerätesoftware neu zu übersetzen. So können z.B. Routing Tabellen oder Sendearten geändert und

erweitert werden, ohne dafür die Build-Umgebung des Steuergerätes zu benötigen oder eine neue ECU-Variante vom

Zulieferer zu beauftragen.

MICROSAR vVIRTUALtarget

Die Virtualisierungslösung vVIRTUALtarget ist eine PC-basierte Integrationsplattform für Automotive Steuergeräte.

Virtuelle Steuergeräte können integriert und getestet werden, auch wenn die Zielhardware noch nicht verfügbar ist.

vVIRTUALtarget unterstützt interaktive und automatisierte Tests über alle Entwicklungsphasen hinweg.

MICROSAR

6

1.1 Anwendungsgebiete

Die BSW-Module aus den MICROSAR-Paketen sichern die Grundfunktionalität des Steuergeräts. Sie enthalten die Implemen-

tierung der AUTOSAR-Standardservices, die Sie für Ihre Funktionssoftware benötigen. Weil die AUTOSAR-Architektur eine

konsequente Hardware-Abstraktion verfolgt, können Sie mit MICROSAR Ihre Funktionssoftware plattform-unabhängig ent-

wickeln.

Die Module aus den Paketen MICROSAR.OS und MICROSAR.MCAL sind hardwareabhängig. Vector bietet Ihnen diese Module

für eine große Anzahl unterschiedlicher HW-Plattformen und Compiler an, so dass z.B. ein schneller Wechsel des Controller-

Derivats möglich ist. Das Betriebssystem MICROSAR.OS ist sowohl für Single-Core- als auch für Multi-Core-Prozessoren ver-

fügbar. Darüber hinaus verfügt Vector durch ständigen Kontakt zu den OEMs über eine Reihe von OEM-spezifischen BSW-

Modulen und Erweiterungen, wie z.B. den Diagnose-Modulen.

Alle benötigten MICROSAR BSW-Module konfigurieren Sie entsprechend den Anforderungen aus Ihrem Projekt und integrieren

sie nach dem Generieren mit der Funktionssoftware. So erhalten Sie die komplette Steuergeräte-Software. Besteht die Funk-

tionssoftware aus AUTOSAR-konformen SWCs, so benötigen Sie eine Laufzeitumgebung (RTE). Die MICROSAR.RTE realisiert

die Kommunikation der SWCs untereinander sowie deren Zugriff auf die Daten und Services aus den BSW-Modulen. Neben

der Verwaltung des gesamten Ereignis- und Informationsflusses stellt die MICROSAR.RTE die Konsistenz des Informations-

austauschs sicher und koordiniert Zugriffe über Core- oder Speicherschutzgrenzen.

Steuergeräteprojekte ohne eine SWC-Architektur (und damit auch ohne Rte) werden durch die Vector Erweiterung vBre (Vec-

tor Basic Runtime Environment) optional unterstützt. vBre vereinfacht die BSW-Integration durch das Bereitstellen eines kon-

figurierbaren BSW-Schedulings, dem Management von Critical Sections sowie der Erzeugung von Typdefinitionen für Service

Layer BSW-Module, welche normalerweise durch die RTE erzeugt würden. Die vBre beschleunigt und vereinfacht somit den

Aufbau von AUTOSAR 4 basierten Projekten, welche keine RTE verwenden.

1.2 Eigenschaften

Die Entwicklung der MICROSAR Basissoftware-Module erfolgt nach dem SPICE-basierten Vector Entwicklungsprozess für

Standard-Module. Alle MICROSAR Pakete bieten Ihnen die folgenden Eigenschaften:

> Effiziente Speichernutzung sowie geringe Laufzeiten

> Für den Serieneinsatz verfügbar

> Für AUTOSAR 4.x und 3.x erhältlich

> Assistenten und zeitnahe Prüfungen unterstützen Sie bei der konsistenten Konfiguration Ihrer Basissoftware

> Hochskalierbar, passend zu Ihrem Anwendungsfall

> Optimal integrierbar in Ihren Entwicklungsprozess

> AUTOSAR-Monitoring für Test und Analyse von Steuergeräten

> Frei wählbarer Konfigurationszeitpunkt (pre-compile, link-time oder post-build)

> Unterstützung von Mehrfachsteuergeräten

> Optionale Lieferung von Sourcecode

> Durch MICROSAR Safe auch für sicherheitsrelevante Funktionen (ISO 26262) geeignet

1.3 Serieneinsatz

Die MICROSAR BSW-Module werden bereits in unzähligen Serienprojekten eingesetzt. Mit MICROSAR profitieren Sie von der

langjährigen Erfahrung von Vector bei der Implementierung von Embedded Standard-Software. Vor der Lieferung werden alle

MICROSAR Softwaremodule systematischen Integrationstests für Ihren konkreten Anwendungsfall (HW-Plattform, Compiler,

Derivat, OEM, mit/ohne Rte, …) unterzogen. Auf Wunsch wird der Umfang dieser Tests auf Softwaremodule von Drittherstel-

lern (z.B. MCAL-Treiber) erweitert.

1.4 Unterstützung von AUTOSAR 4.x und 3.x

Sowohl für AUTOSAR 4.x als auch für 3.x erhalten Sie von Vector die komplette Basissoftware aus einer Hand. Bei der Migration

Ihrer Projekte profitieren Sie von einem einheitlichen Entwicklungsworkflow für AUTOSAR 4.x und 3.x:

MICROSAR

7

> Die Konfigurationswerkzeuge DaVinci Developer und DaVinci Configurator Pro sind für beide AUTOSAR Versionen aus-

gelegt. Somit vermeiden Sie einen Werkzeugwechsel.

> MCAL-Treiber aus unterschiedlichen AUTOSAR-Releases lassen sich mit MICROSAR kombinieren.

Im Falle einer Migration von AUTOSAR 3 nach AUTOSAR 4 unterstützen wir Sie bei der Anpassung Ihrer Anwendungssoftware

an die im AUTOSAR 4.x-Standard geänderten Schnittstellen.

Ein weiterer Vorteil von MICROSAR liegt in den vielen Erweiterungen der BSW-Module für AUTOSAR 3.x, die erst in AUTOSAR

4.x spezifiziert sind. Beispiele hierfür sind das Multi-Core Betriebssystem, sowie die Unterstützung für J1939, XCP und Ether-

net/IP.

1.5 Konsistente und einfache Konfiguration

Mit AUTOSAR wird das manuelle Entwickeln bzw. Anpassen der Grundfunktionalität einer Steuergeräte-Software durch das

Konfigurieren der BSW-Module ersetzt. Die intuitiven, benutzerfreundlichen und sehr gut aufeinander abgestimmten AUTO-

SAR-Werkzeuge von Vector (DaVinci Werkzeuge) unterstützen den Anwender dabei. Der Multi User Support der DaVinci Werk-

zeuge unterstützt das gleichzeitige Arbeiten mehrerer Anwender an einem Projekt. Als Input für die Konfiguration benötigen

die DaVinci Werkzeuge eine „ECU Extract of System Description“-Datei. Auch eine Konfiguration auf Basis gängiger Netz-

werkbeschreibungsdateien (DBC, FIBEX, LDF) ist weiterhin möglich.

Alle DaVinci Werkzeuge überprüfen während der Konfiguration die Gültigkeit einzelner Parameter sowie komplexer Parame-

tergruppen untereinander. Bei ungültigen Konfigurationen bieten sie – wenn möglich – Korrekturvorschläge an. Diese Erweite-

rung der AUTOSAR-Methode vereinfacht die Integration der Basissoftware in Ihr Steuergerät und reduziert die Integrations-

zeit.

Die DaVinci Werkzeuge unterstützen Sie optimal bei der Konfiguration der Rte und der BSW-Module. In einem Bottom-up-

Prozess werden beispielsweise die SWC Service Ports (inkl. Runnables) automatisch passend zur BSW-Konfiguration erzeugt.

Diese Automatisierung nimmt Ihnen Aufgaben ab, die sich häufig wiederholen und bei manueller Durchführung fehleranfällig,

zeitaufwändig und somit kostenintensiv sind.

Bild 2: Mit dem DaVinci Configurator Pro konfigurieren Sie die BSW-Module und die Rte.

MICROSAR

8

Bild 3: Mit dem DaVinci Developer definieren Sie die Funktionssoftware (SWCs).

Weitere Details über die DaVinci Werkzeuge von Vector entnehmen Sie bitte den jeweiligen Produktinformationen.

1.6 Skalierbarkeit

Zusätzlich zu den Vorgaben von AUTOSAR bieten die MICROSAR BSW-Module eine Reihe von funktionellen Erweiterungen.

Durch zusätzliche Konfigurationsmöglichkeiten können z.B. nicht benötigte Funktionen abgeschaltet werden. Dadurch wird der

MICROSAR Code für Ihren Anwendungsfall optimiert. Durch diese Skalierbarkeit sind die MICROSAR Module die optimale Lö-

sung sowohl für kleine als auch für anspruchsvolle Anwendungen. MICROSAR wird bereits in einem breiten Spektrum an Steu-

ergeräten eingesetzt, wie z.B. Lenkwinkelsensoren, Tür-Steuergeräte, Motor-Steuergeräte, Zentrale Gateways, u.s.w. Möglich

ist auch der Einsatz von MICROSAR mit weiteren Betriebssystemen wie Linux oder QNX.

1.7 Frei wählbarer Zeitpunkt für die BSW-Konfiguration

Der Konfigurationszeitpunkt aller MICROSAR Basissoftware-Module ist frei wählbar. Sie wählen für jedes BSW-Modul den

Konfigurationszeitpunkt zwischen pre-compile, link-time oder post-build aus.

1.8 Lieferumfang

Der Standard-Lieferumfang enthält die folgenden Bestandteile:

> Softwaremodule

> Kommandozeilen-basierter Generator (für Windows XP/Windows 7)

> BSW Module Description

> Dokumentation

Zusätzliche oder andere Lieferumfänge sind im Folgenden für jedes Modul separat angegeben. Für eine komfortable Konfigu-

ration der MICROSAR Module empfehlen wir unseren DaVinci Configurator Pro. Details hierzu erfahren Sie in der separaten

Produktinformation.

MICROSAR

9

1.9 Lieferung von Sourcecode

Die MICROSAR Module werden mit ganz wenigen Ausnahmen als Sourcecode geliefert. Der Sourcecode ermöglicht Pre-com-

pile-Optimierungen und vereinfacht das Testen.

1.10 Lizenz und Wartung

Vector bietet Ihnen eine flexible Lizenzierung - individuell nach Ihren Anforderungen. Im Rahmen eines Pflegevertrags erhalten

Sie Software-Updates und bleiben damit auf dem aktuellen Stand der Entwicklung.

1.11 Zusätzliche Dienstleistungen

> Beratung beim System-Design

> Erweiterung der MICROSAR BSW-Module nach Kundenwunsch

> Entwicklung kundenspezifischer Softwarekomponenten (SWC)

> Unterstützung bei der Anpassung bestehender Funktions-Software

> Komplette Softwareintegration in Ihr Steuergerät – auch mit Software von Drittherstellern

> Migration bestehender Software in ein AUTOSAR-basiertes Konzept

> Hotline, spezielle Workshops und Schulungen zum Thema Embedded Software und AUTOSAR

1.12 Die komplette AUTOSAR-Lösung von Vector

Die AUTOSAR-Lösung von Vector besteht aus den DaVinci Werkzeugen, der MICROSAR-Basissoftware und der MICRO-

SAR.RTE. Die Eigenschaften der BSW-Module aus den MICROSAR Paketen finden Sie in den nachfolgenden Kapiteln. Details

zum Funktionsumfang der einzelnen DaVinci Tools finden Sie in den jeweiligen Produktinformationen.

1.13 Kontakt und Verfügbarkeit

Die MICROSAR BSW-Module sind für eine Vielzahl der gängigen Mikrocontroller und in OEM-spezifischen Ausprägungen ver-

fügbar. Weitere Informationen finden Sie unter www.microsar.de/availability/ oder auf Anfrage:

> Email: [email protected]

> Telefon: +49 711 80670-400

1.14 Schulungen

Im Rahmen unseres Schulungsangebotes bieten wir Ihnen für MICROSAR verschiedene Schulungen und Workshops in unseren

Seminarräumen sowie inhouse bei Ihnen an. Mehr Informationen zu den einzelnen Schulungen und die Termine finden im Inter-

net unter www.vector-academy.de.

http://www.microsar.de/availability/

http://www.vector-academy.de/

MICROSAR

10

2 MICROSAR.OS

Bei MICROSAR.OS handelt es sich um ein präemptives Echtzeit-Multitasking-Betriebssystem mit optimierten Eigenschaften

für die Verwendung auf Mikrocontrollern. Die langjährigen Erfahrungen von Vector bei der Entwicklung von Betriebssystemen

und Treibern für Mikrocontroller sind in diesem kleinen, robusten Betriebssystemkern gebündelt.

LeanHypervisor ist ein Modul um einen sicheren Start mehrerer Betriebssystem Partitionen in einem Mehrkernprozessor oder

SoC sicherzustellen. Es initialisiert die System MPU und startet die verschiedenen Partitionen.

Bild 4: MICROSAR.OS Modul nach AUTOSAR 4.3

2.1 Die Vorteile von MICROSAR.OS im Überblick

> Klein, schnell, ressourcensparend und mit kurzen Boot-Zeiten

> MICROSAR.OS ist für AUTOSAR 4.x und 3.x erhältlich

> Als Multi-core Betriebssystem verfügbar

> Grafisches Konfigurationswerkzeug zum einfachen Konfigurieren des Betriebssystems

> Os: Verfügbar für viele 16-, 32- und 64-Bit-Mikrocontroller

> LeanHypervisor: Sicherer Start mehrerer Betriebssystem Partitionen

> LeanHypervisor: Implementierung nach ISO26262 ASIL D

> LeanHypervisor: Freiwählbarer Master Core


MICROSAR.OS basiert auf der AUTOSAR-OS-Spezifikation, einer Erweiterung des praxiserprobten Betriebssystem-Standards

OSEK/VDX-OS. Dieser Standard wurde von Vector um Funktionen für Zeitüberwachung und Speicherschutz erweitert. So

bietet der implementierte High Resolution Timer Mechanismus Zeitauflösungen von weniger als 1ms ohne Erhöhung der Inter-

rupt-Last. In Abhängigkeit vom Controller sind damit Auflösungen bis in den Mikrosekundenbereich möglich. Der High Resolu-

tion Timer ist in jeder Lieferung enthalten, solange es keine Limitierung durch die Hardware gibt.

MICROSAR

11

Die Implementierung von MICROSAR.OS durch Vector erfolgt in voller Konformität mit der AUTOSAR-OS-Spezifikation und

unterstützt alle Skalierbarkeitsklassen.

Der LeanHypervisor ist nach ISO26262 ASIL D implementierte, programmiert während des Systemstarts die System MPU und

startet dann die Betriebssystem-Partitionen. Geschützt durch die System Memory Protection Unit laufen die Betriebssystem-

Partitionen ohne das Risiko der gegenseitigen Störung durch fehlerhafte Datenänderungen. So können Partitionen mit unter-

schiedlichen ASILs parallel betrieben werden. Der Master-Kern ist frei wählbar. Falls die Hardware nach einem Reset keinen

nach ASIL geeigneten Kern startet, kann die Schutzinitialisierung einem anderen ASIL-fähigen Kern zugewiesen werden

2.3 Module und ihre Add-Ons

>

Echtzeitbetriebssystem, implementiert nach dem OSEK/VDX-OS Standard

> erweitert um Schedule Tables

>

Echtzeitbetriebssystem mit Zeitsynchronisation und Überwachung des zeitlichen Verhaltens einzelner Tasks und Inter-

rupt Service Routinen

> Durch die Timing Protection wird sichergestellt, dass die während der Entwurfsphase getroffenen Annahmen hinsicht-

lich der Ausführungszeit eingehalten werden. Ein defekter Anwendungsteil kann somit die Laufzeit der anderen laufen-

den Prozesse nicht beeinträchtigen.

> Messen von Ausführungszeiten und die Interrupt Sperrzeiten von Anwendungen. Diese Messdaten können später als

praxis-basierte Werte beim Entwurf und bei der Integration künftiger Anwendungen verwendet werden.

>

Echtzeitbetriebssystem mit Speicherschutzmechanismen auf Mikrocontrollern mit entsprechender Hardware-Unterstüt-

zung

> Der Speicherschutz stellt sicher, dass Anwendungskomponenten sich nicht gegenseitig die Daten zerstören. Dadurch

wird die Integration von Anwendungen einfacher und zuverlässiger.

>

Kombination von Scalability Class SC2 und SC3.

Add-Ons

Die folgenden Add-Ons sind für alle OS unabhängig von der Scalability Class verfügbar (SC1 bis SC4).

> Multi-Core (symmetric): Das Add-On Multi-Core (symmetric) kommt dort zum Einsatz, wo ein Mehrkern-System nach

AUTOSAR-Spezifikation entwickelt werden soll und die Kerne denselben Befehlssatz aufweisen. Es basiert auf der AU-

TOSAR-Spezifikation 4.x, kann aber auch in AUTOSAR 3.x Projekten eingesetzt werden.

> Multi-Core (asymmetric): Das Add-On Multi-Core (asymmetric) kommt dort zum Einsatz, wo ein Mehrkern-System

nach AUTOSAR-Spezifikation entwickelt werden soll und die Kerne einen unterschiedlichen Befehlssatz aufweisen. Es

basiert auf der AUTOSAR-Spezifikation 4.x, kann aber auch in AUTOSAR 3.x Projekten eingesetzt werden.

>

In einer Multi-Core-Anwendung initialisiert das Modul LeanHypervisor beim Start die System Memory Protection Unit

(MPU) und verwaltet den Start der Kerne. Jeder Kern kann sein eigenes Betriebssystem-Image haben. Jede Kombination

von POSIX-, Classic- oder Adaptive AUTOSAR-Betriebssystemen ist möglich.

Geschützt durch die System Memory Protection Unit können die verschiedenen Partitionen störungsfrei betrieben wer-

den, so dass Partitionen mit unterschiedlichen ASILs parallel betrieben werden können.

Der Masterkern ist frei wählbar. Die Schutzinitialisierung kann einem ASIL-konformen Core zugewiesen werden, falls der

nach dem Einschalten oder Reset gestartete Core die ASIL-Anforderungen nicht erfüllt.

LeanHypervisor macht Partitionen unabhängig. Jede Partition kann sich auf ihre Anforderungen an den Schutz des loka-

len Speichers konzentrieren. Außerdem müssen Partitionen keinen synchronisierten Wartestatus für die Grundinitialisie-

rung implementieren. Diese Reduzierung der externen Abhängigkeiten erleichtert die Entwicklung der einzelnen Partition.

MICROSAR

12

LeanHypervisor wird nach ASIL D als Safety Element out of Context (SooC) entwickelt. LeanHypervisor benötigt nach

dem Start der Partitionen keine CPU-Last.

2.4 High Resolution Timer (HRT)

AUTOSAR-Betriebssysteme verwenden in der Regel einen Periodischen Timer (PIT), um die Systemzeit zu generieren. Die Zeit-

auflösung ergibt sich dann aus der Zykluszeit, mit der der Systemzähler ausgelöst wird. Jeder Trigger entspricht einem Inter-

rupt. Im Allgemeinen muss der Integrationsingenieur einen Kompromiss zwischen Interrupt-Last und Zeitauflösung finden.

Manchmal erfordert eine Anwendung eine Zeitauflösung, die höher ist als ein akzeptabler Kompromiss.

2.5 Grafisches Konfigurations- und Generierungstool

Für die leichte und komfortable Konfiguration des Betriebssystems empfehlen wir den DaVinci Configurator Pro. Er enthält

eine Konsistenzprüfung und den Aufruf des Generators. Der Generator ist als Kommandozeilen Tool ausgeführt, um die In-

tegration in eine automatisierte Entwicklungsumgebung zu ermöglichen.

2.6 Lieferumfang

Der Lieferumfang von MICROSAR.OS umfasst:

> Betriebssystem-Kern als Sourcecode

> Kommandozeilen-basierter Generator

> BSW Module Description

> Beschreibungsdateien für DaVinci Configurator Pro

> Dokumentation

MICROSAR

13

3 MICROSAR.COM – AUTOSAR Basissoftware-Module für die Kommunikation

Die Basissoftware-Module (BSW) aus MICROSAR.COM enthalten die AUTOSAR-Dienste für die Steuergeräte-Kommunika-

tion. Sie unterstützen beliebig viele Kommunikationskanäle. Diese Dienste sind busunabhängig und werden in jedem Kommu-

nikations-Stack benötigt. Entsprechend der AUTOSAR-Architektur übernehmen sie die Kontrolle und vollständige Einbindung

der busspezifischen Kommunikationsmodule für CAN, CAN-FD, J1939, FR, LIN und ETH in die Steuergerätesoftware.

Bild 5: Die MICROSAR.COM Module nach AUTOSAR 4.3

3.1 Die Vorteile von MICROSAR.COM im Überblick

> Code- und Laufzeit-optimiert durch anwendungsspezifische Konfiguration


> Enthält zahlreiche Erweiterungen über den AUTOSAR-Standard hinaus, siehe Kapitel "Funktionen

> Erweiterter Support für Nm-Koordinatoren

> Modul NM: Kompatibilität zum OSEK Nm ist konfigurierbar

> Unterstützt gleichzeitigen Betrieb von AUTOSAR Nm und OSEK Nm in Nm-Migrationsprojekten

> Sehr effizienter Signalzugriff über Funktionsmakros (für AUTOSAR 3)


Mit MICROSAR.COM entwickelt der Anwender seine Funktions-Software vollkommen busunabhängig. Alle notwendigen Auf-

gaben zur Übertragung von Nachrichten und für die busübergreifenden Netzwerkmanagement-Aktivitäten übernehmen die

konfigurierbaren BSW-Module COM, NM, PduR und IpduM aus MICROSAR.COM.

Für ein Gateway-Steuergerät benötigen Sie keine zusätzliche Software. Die BSW-Module Com und PduR aus MICROSAR.COM

ermöglichen das Routing von Signalen sowie von TP- oder Applikations-Botschaften.

MICROSAR

14


Jedes Modul aus MICROSAR.COM kann Erweiterungen von Vector aufweisen, die über den AUTOSAR-Standard hinausgehen

und über zusätzlich Add-Ons verfügen.

>

Die Dienste aus dem Modul Com organisieren die Übertragung der Nachrichten entsprechend ihrer Sendeart (zyklisch,

ereignisgetriggert, …). Eine wichtige Aufgabe ist dabei die Umsetzung der busunabhängigen Signale aus der Funktions-

software in PDUs.

Erweiterung zum AUTOSAR-Standard

> Ungültigkeitserklärung von TX-Signalen bei RX-Signal Timeout

> Optimierungen zur Reduktion der Mainfunction Laufzeiten (Empfangsseitig: Cachen von Empfangsereignissen, Sen-

deseitig: Konfiguration mehrerer Zeitdomänen.)

> Deferred Event Caching of Rx IPDUs. Hierbei handelt es sich um die Optimierung der Rx Mainfunction Laufzeit durch

eine ereignisgesteuerte Verarbeitung der Rx PDUs. Die Optimierung erlaubt den Verzicht auf das zyklische Absuchen

aller PDUs in der Mainfunction Rx.

Add-Ons

> GW for Com: Das Modul Com ist mit Gateway-Funktion lieferbar. Das Routing ist für Signale und Signalgruppen mög-

lich. Das Routing im Com ist anhand einer Konfigurationsbeschreibung möglich, ohne dass ein reales Signal oder eine

Signalgruppe vorhanden sein muss.

> Com Add-On HighEndFeatures: Dieses optionale Erweiterungspaket aktiviert die folgenden Funktionen für die Com-

Module:

> Description Based Routing: Diese zusätzliche Routing-Option erlaubt das routen von PDU-Abschnitten (definiert

über Start-Bit und Länge) inkl. Behandlung der Sendeart (periodisch, ereignisgesteuert, bei Änderung). Sie schafft

damit eine performante Alternative zum Signalrouting und zum Zyklus-verlangsamenden PDU-Routing. Die Funktion

benötigt die oben genannte Option GW for Com.

>

Der PDU Router (PduR) stellt den Modulen Com, Dcm und den Complex Drivers eine Schnittstelle zu den Kommunikati-

onsmodulen (Interface, Transport Protokoll und Netzwerk Management) der einzelnen Bussysteme zur Verfügung. Die

Schnittstelle dient zur Datenübertragung und zum Empfang mittels PDUs. Der PduR realisiert auch ein Gateway zwi-

schen den Kommunikationsmodulen der unterschiedlichen Bus-Systeme. Über das MICROSAR-Modul CDD können TP-

und IF-PDUs in den COM-Stack integriert werden:

> oberhalb oder unterhalb des PDU-Routers

> oberhalb des Communication Interfaces

Add-Ons

> GW for PDU

> TP- und Botschafts-Routing,

> Routing anhand von Metadaten beim Range-Routing

> Routen von variablen Adressen ("dynamisches Gateway")

> Routen von dynamischen PDU-Längen.

>

Das Network Management Interface (Nm) bündelt die busübergreifenden Netzwerkmanagement-Aktivitäten aller Kom-

munikationskanäle des Steuergeräts. Als NM-Koordinator synchronisiert es das Wecken und Schlafen der Kommunikati-

onskanäle.

Erweiterung zum AUTOSAR Standard

> Synchrones sleep und wake-up von mehreren Netzwerken über unterschiedliche Nm-Koordinatoren

> Backup Koordinator

MICROSAR

15

> Unterstützung von OSEK Nm (konfigurierbar)

> Mischbetrieb von OSEK- und AUTOSAR-Nm auf einem Kanal

>

Das Modul I-PDU Multiplexer (IpduM) unterstützt die Mehrfachnutzung von Frames mit verschiedenen Dateninhalten,

anhand statischer Konfigurationen für klassische Bus-Systeme, sowie auch anhand dynamischem Dateninhalts-Mapping

für CAN-FD.

>

Informationen zur Secured OnBoard Communication (SecOC) entnehmen sie bitte dem Kapitel "MICROSAR Security".

> Transformer:

Erlaubt die effiziente Übertragung komplexer Datenstrukturen und großer PDUs über das Netzwerk.

> ComXf: Ermöglicht die Bildung effizienter Signalgruppen mit hohem Signalaufkommen. Die Platzierung wird aus dem

System Extract abgeleitet.

> SomeIpXf: bietet eine Serialisierungsstrategie für zahlreiche Datentypen an. Für eine besonders effiziente Übertra-

gung kann hierbei auch der LdCom eingesetzt werden.

> E2eXf: Ermöglicht die End-To-End Verschlüsselung für Netzwerk-Kommunikation beim Einsatz des AUTOSAR Trans-

former Concept (also mithilfe der Serialisierung durch COMXF oder SOMEIPXF).

>

Diese Funktion erlaubt das Spiegeln von internen Bussen auf den Diagnosezugang. Dadurch ist es möglich, die normaler-

weise unzugänglichen Nachrichten auf dem Bus zu lesen und Probleme zu identifizieren. Die Funktion erlaubt in der Ba-

sisversion das Spiegeln eines internen CAN oder LIN Kanals auf den Diagnose CAN.

Add-Ons

> ETH: mehrere interne CAN, LIN, FlexRay und ETH Kanäle auf den Diagnose Ethernet zu spiegeln

> FR: CAN, LIN oder FlexRay Kanäle auf den Diagnose CAN oder Diagnose FlexRay zu spiegeln.

3.3.1 Paket-übergreifende Add-Ons

Es gibt auch Optionen, die sich auf ein oder mehrere Pakete auswirken. Im Detail sind das:

> MICROSAR.IDM – Identity Manager, Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling "

> MICROSAR.MC – Multi-Core, Details hierzu finden Sie im Kapitel „MICROSAR Multi-Core“

> MICROSAR.SAFE – Safety nach ISO 26262, Details hierzu finden Sie im Kapitel „MICROSAR Safety“

> MICROSAR.PBL – Post-Build Loadable, Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling ".

3.4 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Mehr Details finden Sie in der separaten

Produktinformation.

Das MICROSAR.COM Modul PduR sowie die Module CanIf, LinIf, FrIf, EthIf, SoAd lassen sich durch Konfiguration mit dem

DaVinci Configurator Pro einfach an Ihre Complex Driver anbinden.

MICROSAR

16

Bild 6: Konfiguration der Kommunikationsmodule mit dem DaVinci Configurator Pro

MICROSAR

17

4 MICROSAR.CAN – AUTOSAR Basissoftware-Module für die CAN-Kommunikation

Das Paket MICROSAR.CAN enthält die in der AUTOSAR-Architektur definierten BSW-Module für die CAN-Kommunikation:

CanIf, CanNm, CanTp, CanSm und optional Module für J1939 und Xcp.

Bild 7: Die MICROSAR.CAN Module nach AUTOSAR 4.3

4.1 Die Vorteile von MICROSAR.CAN im Überblick


> Enthält zahlreiche nützliche Erweiterungen

> Code- und Laufzeit-optimiert durch bedarfsspezifische Konfiguration

> Modulübergreifende Konfiguration aller kommunikationsspezifischen Softwaremodule

> Schnelles Wakeup-Handling während des ECU-Startups

> CanTp: Kompatibilität zu ISO 15765-2 ist konfigurierbar

> OSEK Nm ist als kompatibel konfigurierbares Modul zu CANNM erhältlich

> CanNm, CanSm: Abschalten des Kommunikations-Stacks in Abhängigkeit vom Teilnetzstatus

> CAN FD: Unterstützung von bis zu 64 Byte Nutzdaten bei erhöhter Bandbreite. Verfügbar für viele CAN FD Controllers.


Das Einsatzgebiet von MICROSAR.CAN ist die Kommunikation in CAN-Netzwerken. Weiterhin eignet es sich z.B. als Basis für

das Kalibrieren mit Xcp, für Gateways oder das Re-Programmieren. Sie können MICROSAR.CAN auch mit der Option J1939

erweitern, um den Betrieb eines AUTOSAR-Steuergeräts in einem J1939-Netzwerk zu ermöglichen. Zur Verfügung stehen die

Transport Protokolle BAM und CMDT.


Jedes Modul aus MICROSAR.CAN enthält die in AUTOSAR 4.x definierten Funktionen. Darüber hinaus kann ein Modul Erwei-

terungen von Vector aufweisen, die über den AUTOSAR-Standard hinausgehen und über zusätzlich Optionen verfügen.

MICROSAR

18

>

Das Modul CanIf bietet einen abstrahierten (PDU-basierten) Zugriff auf den CAN-Treiber. Es steuert den CAN-Treiber

(Can) sowie den Transceiver-Treiber CanTrcv).


> Double Hash Search Algorithmus zur effizienten Filterung der Empfangsbotschaften

>

Das Modul CanNm ist innerhalb eines CAN-Netzwerkes für den koordinierten Übergang zwischen dem Wach- und dem

Schlaf-Zustand verantwortlich.


> Pre-Compile Optimierungen z.B. für Einkanalsysteme

>

Das CanTp-Modul ist konform zum ISO-Standard 15765-2. Als Transportprotokoll für CAN übernimmt es das Segmen-

tieren der Daten in Senderichtung, Sammeln der Daten in Empfangsrichtung und Überwachen des Datenstroms.



> Unterstützt Mixed Addressing (11 bit CAN ID); typischerweise für CAN/LIN Gateway Anwendungen

> Optimiertes Routing mit z.B. Burst Transmission zusammen mit dem PDUR aus MICORSAR COM

> Konfigurierbare Kompatibilität zu ISO 15765-2

>

Das Modul CanSM übernimmt die busspezifische Fehlerbehandlung.


> Unterstützung des ECU Passive Mode

>

Das Modul CanTSyn realisiert die Zeitsynchronisation über CAN. Der Zugriff auf die synchronisierte Zeitbasis durch

SWCs erfordert den Synchronized Time-Base Manager (StbM).


> Time Synchronization over CAN (CanTSyn) implementiert das Generalized Precision Time Protokoll (gPTP) nach IEEE

802.1AS. Damit kann eine Uhrensynchronisation zwischen CAN-Steuergeräten realisiert werden. Als übergeordneter

Zeit-Koordinator steht das BSW-Modul Synchronized Time Base Manager (StbM) aus MICROSAR.SYS zur Verfügung.

>

Xcp ist ein Protokoll für die Kommunikation zwischen einem Master (PC-Tool) und einem Slave (Steuergerät). Es ist vom

ASAM standardisiert und wird hauptsächlich zum Messen, Kalibrieren, Flashen und Testen von Steuergeräten verwendet.

XCP unterstützt die Bussysteme CAN, FlexRay, Ethernet und LIN.

4.3.1 Folgende Funktionalitäten bzw. Module sind zusätzlich erhältlich:

>

J1939 unterstützt das Hinzufügen von Steuergeräten zu Netzwerken on-the-fly. Das J1939Nm-Modul ist für das Aus-

handeln einer eindeutigen Steuergeräte-Adresse zuständig („AddressClaim“) und nicht wie andere NM-Modulen für das

Aufwachen und Einschlafen des Busses.

Add-On

> Dynamic Nm: Steuergeräte, die ihre Adresse ändern oder mit Steuergeräten kommunizieren, die ihre Adresse ändern.

>

MICROSAR

19

Das J1939Tp-Modul beinhaltet die Transportprotokolle BAM (Broadcast Announce Message) und CMDT (Connection

Mode Data Transfer) des SAE J1939-Standards.

Add-Ons

> ISOBUS: Extended Tp (ETP) und Fast Packet Tp (FPTP). Basierend auf ISO 11783-2 und NMEA2000

>

Das Modul J1939Rm realisiert das Anfordern von Daten über das so genannte Request-Handling im SAE J1939-Proto-

koll.


Es gibt auch Add-Ons, die sich auf ein oder mehrere Pakete auswirken. Im Detail sind das:

> MICROSAR.PBL – Post-Build Loadable, Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling "



4.4 Konfiguration


Produktinformation.

4.5 Weitere MICROSAR Produkte für einen kompletten CAN-Kommunikations-Stack

Entsprechend der AUTOSAR-Architektur bildet MICROSAR.CAN zusammen mit den BSW-Modulen aus den separat erhältli-

chen Paketen MICROSAR.COM, MICROSAR.MCAL und MICROSAR.EXT einen kompletten Kommunikations-Stack für CAN. Für

die Anbindung von MICROSAR.CAN an die Applikation und an die Hardware benötigen Sie noch folgende BSW-Module:

> Hardwarespezifischen CAN-Treiber (Can) aus MICROSAR.MCAL

> Hardwarespezifische Transceiver-Ansteuerung (CanTrcv) aus MICROSAR.EXT, auch für den Teilnetzbetrieb.

> Allgemeine Kommunikationsmodule (Com, Nm, PduR, IpduM) aus MICROSAR.COM

Die Module in MICROSAR.MCAL und MICROSAR.EXT sind für viele Mikrocontroller und Transceiver erhältlich.

4.6 Weitere relevante MICROSAR Produkte für CAN

> DCM und DEM aus MICROSAR.DIAG

> Det, EcuM und ComM aus MICROSAR.SYS

> MICROSAR XCP erlaubt das Messen und Kalibrieren nach ASAM XCP. Das Modul wurde dabei besonders auf die Ver-

wendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für CAN-Steuergeräte enthält MICRO-

SAR XCP die passende Transportschicht CANXCP.

> Über den AUTOSAR Standard hinaus unterstützt MICROSAR XCP das generische Auslesen von Messobjekten. In der

Folge müssen keine Adressen in der a2l-Datei definiert und aktualisiert werden. Mit einer vom Build des Steuergeräts

unabhängigen a2l-Datei können damit die Daten aus beliebigen Versionen oder Varianten ausgelesen werden. Das Gene-

rische Messen erfordert die Verwendung von CANoe.AMD oder CANape als XCP Tools.

> In vielen Fällen dürfen in Serienprojekten aus Sicherheitsgründen die Mess- und Kalibrierschnittstellen nicht mehr ver-

wendet werden. Das Modul VX1000If ermöglicht es, den Vector VX1000 Mess- und Kalibrier-Hardware Treiber in einem

deaktivierten Zustand in der BSW auch im Rahmen von Serienprojekten zu belassen. Über ein API kann die VX1000 Trei-

ber Funktion für Prüf und Entwicklungszwecke wieder freigegeben werden. Die Lieferung muss im Rahmen eines MICRO-

SAR SIPs erfolgen um eine Freigabe für die Nutzung dieser Vorgehensweise im Serieneinsatz zu erhalten. Eine Aktivie-

rung des VX1000 Treibers im Serieneinsatz zur Laufzeit ist jedoch auch bei Verwendung des Moduls VX1000If nicht ge-

stattet.

> Weitere Informationen zu J1939-Steuergeräte in Nutzfahrzeugen finden Sie im Kapitel "MICROSAR J1939".

MICROSAR

20

4.7 Die Vector Toolchain für die Entwicklung von CAN-Steuergeräten

Bild 8: Vector bietet Ihnen ein umfassendes Portfolio für Ihre CAN-Projekte

MICROSAR

21

5 MICROSAR.FR – AUTOSAR Basissoftware-Module für die FlexRay-Kommunikation

Vector bietet Ihnen mit MICROSAR.FR ein AUTOSAR-konformes Paket für die FlexRay Kommunikation Ihres Steuergeräts.

Dieses enthält die in der AUTOSAR-Architektur definierten BSW-Module FrIf, FrNm, FrSm und wahlweise FrTp oder FrIsoTp.

Optional kann MICROSAR.FR mit XCP erweitert werden.

Bild 9: Die MICROSAR.FR Module nach AUTOSAR 4.3

5.1 Die Vorteile von MICROSAR.FR im Überblick


> Aktiviert/deaktiviert Teilnetze und stellt Daten je nach Teilnetzstatus bereit

> Geringe Codegröße und kurze Laufzeit durch optimierte Verwaltung der Joblisten des FlexRay Interfaces

> Wahlweise Verwendung der Transportprotokolle FrTp (AUTOSAR) oder FrIsoTp (ISO 10681)

> Unterstützung des ECU passive Mode im FlexRay State Manager

> Frühzeitiges Erkennen von Synchronisationsverlusten


Das Einsatzgebiet von MICROSAR.FR ist die Kommunikation in FlexRay-Netzwerken inklusive Teilnetzbetrieb. Weiterhin eignet

es sich z.B. als Basis für das Kalibrieren mit Xcp, für Gateways oder das Flashen.


Die BSW-Module in MICROSAR.FR enthalten die in AUTOSAR 4.x definierten Funktionen, wobei FRISOTP eine Ergänzung zu

AUTOSAR 3.x ist.

>

Das Modul FrIf bietet einen abstrahierten (PDU-basierten) Zugriff auf die FlexRay-Hardware. Darüber hinaus bietet es

Unterstützung zur Synchronisation mit der globalen FlexRay-Zeit.


MICROSAR

22

> Unterstützung der folgenden APIs: CancelTransmit und L-PDU-Rekonfiguration

> Dual Channel Redundancy für die redundante Übertragung von Frames sowie PDU-spezifische Voting-Funktion für die

SWCs


>

Das Modul FrNm ist für die Netzwerkverwaltung bei FlexRay verantwortlich. Es synchronisiert den Übergang zum Bus-

Ruhezustand (bus sleep).



>

Das Modul FrSM steuert und überwacht das Aufwachen und Aufstarten von Knoten im FlexRay-Cluster.


> Unterstützung des ECU Passive Mode, Sofortiges Startup nach passivem Wakeup, Erweiterte Fehlerbehandlung über

State Change Notification, konfigurierbare zeitlich Verzögerung des FlexRay-Startups bei passivem Wakeup sowie

konfigurierbare Anzahl an Wakeup-Patterns

>

FrTp ist ein FlexRay-Transportprotokoll und basiert auf dem Standard ISO 10681-2.



>

FrArTp ist ein FlexRay-Transportprotokoll. In Anlehnung an die ISO 15765-2 (CanTp) enthält es eine Frame-Kompatibili-

tät zum CAN-Bus.

>

Das Modul FrTSyn realisiert die Zeitsynchronisation über FlexRay. Der Zugriff auf die synchronisierte Zeitbasis durch

SWCs erfordert den Synchronized Time-Base Manager (StbM).


> Time Synchronization over FlexRay (FRTSYN) implementiert das Generalized Precision Time Protokoll (gPTP) nach

IEEE 802.1AS. Damit kann eine Uhrensynchronisation zwischen FR-Steuergeräten realisiert werden. Als übergeordne-

ter Zeit-Koordinator steht das BSW-Modul Synchronized Time Base Manager (STBM) aus MICROSAR.SYS zur Verfü-

gung.

>

Das Modul FrXcp enthält die FlexRay-spezifischen Anteile des XCP-Moduls (Xcp).





5.4 Betriebssystem

Die FlexRay Basissoftware-Module können ganz ohne Betriebssystem verwendet werden. Sinnvollerweise wird ein AUTOSAR-

OS oder ein konventionelles OSEK-OS (z.B. Vector osCAN) verwendet. Ideal geeignet für FlexRay-Anwendungen ist das

MICROSAR.OS von Vector.

MICROSAR

23

5.5 Konfiguration


Produktinformation.

5.6 Weitere MICROSAR Produkte für einen kompletten FlexRay-Kommunikations-Stack

Entsprechend der AUTOSAR-Architektur bildet MICROSAR.FR zusammen mit den BSW-Modulen aus den separat erhältlichen

Paketen MICROSAR.COM, MICROSAR.MCAL, MICROSAR.SYS und MICROSAR.EXT einen kompletten Kommunikations-Stack

für FlexRay. Für die Anbindung von MICROSAR.FR an die Applikation und an die Hardware benötigen Sie noch folgende BSW-

Module:

> Hardwarespezifischen FlexRay-Treiber (Fr) aus MICROSAR.MCAL

> Hardwarespezifische Transceiver-Ansteuerung (FrTrcv) aus MICROSAR.EXT

> Allgemeine Kommunikationsmodule (Com, Nm, PduR, IpduM) aus MICROSAR.COM

Die Module in MICROSAR.MCAL und MICROSAR.EXT sind für viele Mikrocontroller bzw. Transceiver erhältlich.

5.7 Die Vector Toolchain für die Entwicklung von FlexRay-Steuergeräten

Bild 10: Vector bietet Ihnen ein umfassendes Portfolio für Ihre FlexRay-Projekte

MICROSAR

24

6 MICROSAR.LIN – AUTOSAR Basissoftware-Module für die LIN-Kommunikation

MICROSAR.LIN enthält die in der AUTOSAR-Architektur definierten BSW-Module für die LIN-Kommunikation: LinIf, LinSM und

LinNm. LinTp ist gemäß AUTOSAR Bestandteil von LINIF. Weil nicht jeder LIN-Kommunikations-Stack ein Transport-Protokoll

benötigt, ist das LIN Transport-Protokoll optional erhältlich. Ebenso ist XCP für den MICROSAR.LIN - Master als ASAM-Erwei-

terung verfügbar. Mit der AUTOSAR-Version 4.4 ist LIN als Master und als Slave erhältlich.

Bild 11: Die MICROSAR.LIN Module nach AUTOSAR 4.3

6.1 Die Vorteile von MICROSAR.LIN im Überblick


> Enthält zahlreiche nützliche Erweiterungen

> Minimierter Scheduling Jitter beim mehrkanaligen Master

> Optimiertes Routing von Diagnose Anfragen an LIN-Slaves

> Schnelles Starten des LIN-Kanals

> Zuverlässige Umschaltung der Schedule Tables

> Basiert auf der langjährigen Erfahrung von Vector mit Serien-Software für LIN


Das Einsatzgebiet von MICROSAR.LIN ist die Kommunikation für einen LIN-Master in einem LIN-Netzwerk. Weiterhin eignet

es sich z.B. als Basis für Gateways oder das Re-Programmieren.


Die BSW-Module aus MICROSAR.LIN enthalten die in AUTOSAR 4.x definierten Funktionen.

>

Das Modul LinIf bietet einen abstrahierten (PDU-basierten) Zugriff auf die LIN-Hardware. Darüber hinaus übernimmt es

die Schedule Table Bearbeitung. Dieses Modul ist als Master und als Slave erhältlich.

MICROSAR

25


> Konfigurierbares Wakeup Delay

> Getrennt konfigurierbares Speicher-Mapping der Konfigurationsdaten von LinIf und LinTp. Dies ist für Controller mit

segmentiertem Speicher besonders interessant.

> Benachrichtigung über Schedule Table End

> konfigurierbare schedule tables zur Reduzierung der maximalen Task-Laufzeiten bei mehrkanaligen Systemen

> Wakeup über den LIN-Tranceiver. Nach einem externen Wecken entfällt durch diese Funktion das Versenden eines (un-

erwünschten) zweiten WakeUp-Pulses durch den Master.

>

Das LinNm-Modul enthält ein Hardware-unabhängiges Protokoll, das den Übergang zwischen Normalbetrieb und Bus-

Sleep-Modus des LIN-Netzwerks koordiniert. Dieses Modul ist nur als Master erhältlich. Der LIN-Slave verwendet benö-

tigt kein LinNm mehr.

>

Das Modul LinSM schaltet die Schedule Tables sowie die PDU-Gruppen im Modul Com um und bedient das LIN-Interface

bezüglich Sleep und Wake-up. Dieses Modul ist als Master und als Slave erhältlich.


> Erweiterte Abfrage der LINSM Sub-Modi für die kontrollierte Umschaltung der LIN Schedule Tables

> Optimiertes Startup Verhalten durch automatische Auswahl einer Schedule Table (konfigurierbar)

>

Das Modul LinTp übernimmt die Aufteilung der Daten in Senderichtung, Sammlung der Daten in Empfangsrichtung und

Kontrolle des Datenstroms. Laut der AUTOSAR-Spezifikation ist LinTp Teil des LinIf. Dieses Modul ist als Master und als

Slave erhältlich.

6.3.1 Vector Module als Erweiterung zum AUTOSAR Standard

>

Das Modul vLinXcp enthält die LIN-spezifischen Anteile des XCP-Moduls (Xcp).





6.4 Konfiguration


Produktinformation.

6.5 Weitere MICROSAR Produkte für einen kompletten LIN-Kommunikations-Stack

Entsprechend der AUTOSAR-Architektur bildet MICROSAR.LIN zusammen mit den BSW-Modulen aus den separat erhältlichen

Paketen MICROSAR.COM, MICROSAR.MCAL und MICROSAR.EXT einen kompletten Kommunikations-Stack für LIN. Für die

Anbindung von MICROSAR.LIN an die Applikation und an die Hardware benötigen Sie noch folgende BSW-Module:

> Hardwarespezifischer LIN-Treiber (Lin) aus MICROSAR.MCAL

> Hardwarespezifische Transceiver-Ansteuerung (LinTrcv) aus MICROSAR.EXT

> Allgemeine Kommunikationsmodule und Gateway-Funktionen (Com, PduR) aus MICROSAR.COM

Die Module in MICROSAR.MCAL und MICROSAR.EXT sind für viele Mikrocontroller bzw. Transceiver erhältlich.

MICROSAR

26

6.6 Weitere relevante MICROSAR Produkte für LIN

> DET, ECUM und COMM aus MICROSAR.SYS


wendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für LIN-Steuergeräte enthält MICRO-

SAR XCP die passende Transportschicht vLinXcp. Da XCP-on-LIN nicht offiziell definiert ist, handelt es sich bei dieser

XCP-on-LIN-Implementierung um eine Vector-Erweiterung des ASAM Standards.

> Über den AUTOSAR Standard hinaus unterstützt MICROSAR XCP das generische Auslesen von Messobjekten. In der










stattet.

6.7 Die Vector Toolchain für die Entwicklung von LIN-Steuergeräten

Bild 12: Vector bietet Ihnen ein umfassendes Portfolio für Ihre LIN-Projekte

MICROSAR

27

7 MICROSAR.ETH – AUTOSAR Basissoftware-Module für Ethernet-basierte Kommunikation

Mit dem Internet Protokoll und den darüberliegenden Transportprotokollen UDP und TCP stehen sehr verbreitete Standards

zur Verfügung, um Daten mit hoher Geschwindigkeit über Ethernet auszutauschen.

Das Paket MICROSAR.ETH (Ethernet) enthält die AUTOSAR BSW-Module inklusive eines nach Automotive-Standard entwi-

ckelten TCP/IP-Stacks für die Ethernet-basierte Kommunikation von Steuergeräten. AUTOSAR 4.0 spezifiziert erstmalig

Ethernet als Netzwerktechnologie. Mit AUTOSAR 4.1 wurden die Spezifikationen in diesem Bereich erheblich modifiziert und

erweitert. Weitere Ergänzungen, wie z.B. die Konfiguration von Ethernet-Switches und die Zeitsynchronisation zwischen Steu-

ergeräten, sind in AUTOSAR 4.2 spezifiziert. Die BSW-Module von MICROSAR.ETH sind entsprechend AUTOSAR 4.x sowie als

Ergänzung zu AUTOSAR 3.x verfügbar.

Bild 13: Die MICROSAR.ETH BSW-Module nach AUTOSAR 4.3

7.1 Die Vorteile von MICROSAR.ETH im Überblick

> BSW-Module nach AUTOSAR 4.x erhältlich sowie Vector-spezifische Erweiterungen

> Nach Automotive-Standard entwickelter TCP/IP-Stack. IETF Konformität wird regelmäßig mit 3rd Party OPEN ALLI-

ANCE TC8 Test nachgewiesen.

> Keine Open Source Software.

> Nahtlose Integration von z.B. Vehicle-to-Grid-Kommunikation (MICROSAR.V2G) und Audio/Video Bridging (MICRO-

SAR.AVB) in den AUTOSAR Ethernet- und TCP/IP-Stack

> Einfache Einbindung kundenspezifischer Funktionen/Module auf allen Ebenen


Mit MICROSAR.ETH im Steuergerät (Server) und einem gängigen PC oder Diagnosetester als Client, können Sie

> das Fahrzeug gemäß ISO 13400-2 (DoIP) diagnostizieren und

> Steuergeräte schnell und parallel re-programmieren.

MICROSAR

28

Durch den größeren Datendurchsatz von Ethernet lassen sich die gesamten Software-Download- und Diagnose-Zeiten erheb-

lich verkürzen. Ein im Fahrzeug vorhandenes Gateway kann die Diagnoseanfragen an Fahrzeug-interne Netzwerke weiterlei-

ten. Damit können Sie über DoIP beispielsweise mehrere CAN-Steuergeräte parallel re-programmieren. In Kombination mit

weiteren MICROSAR-Paketen realisiert MICROSAR.ETH die dafür benötigte Gateway-Funktionalität. Wird MICROSAR.ETH

im Flash Bootloader (FBL) eingesetzt, kann ein Steuergerät, das mit dem Ethernet-Netzwerk verbunden ist (z.B. das Gateway

selbst), direkt über DoIP re-programmiert werden.

Zum Messen und Kalibrieren von Ethernet-Steuergeräten steht Ihnen MICROSAR XCP on Ethernet zur Verfügung, mit dem Sie

auch hier von der erhöhten Bandbreite profitieren. XCP-Routing erweitert ein Gateway um die Möglichkeit, über den Ethernet-

(Fahrzeug-)Zugang auch CAN- und FlexRay-Steuergeräte mittels XCP zu kalibrieren.

Neben den Anwendungsgebieten Diagnose, Messen und Kalibrieren, bei denen die Ethernet-basierte Kommunikation zwischen

externer Infrastruktur und dem Fahrzeug stattfindet, bietet MICROSAR.ETH auch die Möglichkeit, Fahrzeug-interne Ethernet-

Netzwerke effizient zu nutzen. Mittels "Scalable Service-Oriented Middleware over IP" (SOME/IP) können Sie beispielsweise

Daten Service-orientiert übertragen. Für die Verwaltung von Services kommt unter anderem das BSW-Modul Service Discovery

(Sd) zum Einsatz, das mit AUTOSAR 4.1.1 eingeführt wurde. Neben der reinen Service-Orientierung bietet SOME/IP auch eine

dynamische Datenserialisierung, deren Implementierung als RTE-Transformer zur Verfügung steht. Weitere Informationen

zum SOME/IP-Transformer finden Sie in den Kapiteln zu MICROSAR.RTE und MICROSAR.COM.

Natürlich können Sie Daten auf Ethernet weiterhin auch Signal- und PDU-basiert übertragen.

Teile aus MICROSAR.ETH dienen außerdem als Basis für die Vehicle-to-Grid-Kommunikation und das Audio/Video Bridging.

Weitere Details zu diesen Anwendungsgebieten finden Sie in den Kapiteln zu MICROSAR.V2G und MICROSAR.AVB.


>

Das Modul EthIf ermöglicht eine busunabhängige Ansteuerung der Ethernet-Treiber (Eth) und Ethernet-Transceiver-

Treiber (EthTrcv).

Das Ethernet Interface (EthIf) ermöglicht eine Hardware-unabhängige Ansteuerung der Ethernet-Treiber (EthDrv) und

Ethernet-Transceiver-Treiber (EthTrcv). Seit AUTOSAR 4.1 ist dieses Modul zusätzlich für die VLAN-Behandlung zustän-

dig. Die Hardware-unabhängige Ansteuerung von Ethernet-Switch-Treibern (EthSwtDrv und EthSwtDrv EXT) ist seit

AUTOSAR 4.2 Bestandteil des EthIf.

>

Für das Starten oder Herunterfahren der Kommunikation in Ethernet-Clustern stellt das Modul EthSM dem Communi-

cation Manager (ComM) eine abstrakte Schnittstelle zur Verfügung. Der EthSM greift über das EthIf auf die Ethernet-

Hardware zu.

Für das Starten oder Herunterfahren der Kommunikation in Ethernet-Clustern stellt der Ethernet State Manager

(EthSm) dem Communication Manager (COMM) eine abstrakte Schnittstelle zur Verfügung. Der EthSm greift über das

EthIf auf die Ethernet-Hardware zu.

>

Das Modul EthTSyn realisiert die Zeitsynchronisation über Ethernet und referenziert den IEEE-Standard 802.1AS (PTP).

Der Zugriff auf die synchronisierte Zeitbasis durch SWCs erfordert den Synchronized Time-Base Manager (StbM).

Time Synchronization over Ethernet (EthTSyn) implementiert das generalized Precision Time Protokoll (gPTP) nach IEEE

802.1AS. Damit kann eine Uhrensynchronisation zwischen Ethernet-Steuergeräten realisiert werden.

Das Modul EthTSyn realisiert die Zeitsynchronisation über Ethernet und referenziert den IEEE-Standard 802.1AS (PTP).

Der Zugriff auf die synchronisierte Zeitbasis durch SWCs erfordert den Synchronized Time-Base Manager.

> Initialisierung aller notwendigen Hardware-Schnittstellen

> Ethernet-Frames mit Ethertype 0x88F7 werden aus dem ETHIF dem ETHTSYN zugeleitet

> Unterstützung von gPTP (Generalized Precision Time Protocol) nebst AUTOSAR Erweiterungen

> Unterstützung von General und Event Messages

> Unterstützung zur Berechnung der Laufzeitverzögerung: Pdelay_Req, Pdelay_Resp, Pdelay_Resp_Follow_Up

> Unterstützung des Transports des synchronen Zeitstempels: Sync, Follow_Up

MICROSAR

29

>

Der Socket Adaptor (SoAd) setzt die in AUTOSAR definierte Kommunikation über PDUs in Socket-orientierte Kommuni-

kation um. In AUTOSAR 4.0 enthält der SoAd darüber hinaus die in ISO 13400-2 definierte Diagnosefunktionalität

(DoIP). Ab AUTOSAR 4.1 ist dieses Plug-In herausgelöst und als eigenständiges Modul (DOIP) spezifiziert. Außerdem sind

im SoAd Erweiterungen für das XCP-Routing implementiert.

Mit dem Add-on "SoAd BSD" können der SoAd und die darüberliegenden Module auch in einer Nicht-AUTOSAR-Umge-

bung, wie beispielsweise Linux, eingesetzt werden.

>

Mit dem Modul vEXI werden XML-Dokumente interpretiert und in ein Binär-Format konvertiert. Damit lassen sich die

Dateien effizienter verarbeiten und übertragen um Kommunikationsbandbreite einzusparen. Es kommt im Vehicle2Grid-

Umfeld zum Einsatz.

>

Seit AUTOSAR 4.1.1 enthält das Diagnostics over IP (DOIP)-Modul die gleichnamige Diagnosefunktionalität nach ISO

13400-2. Bis einschließlich AUTOSAR 4.0.3 ist diese Funktionalität Bestandteil des Socket Adaptors (SoAd).

>

Dieses Modul enthält alle Protokolle für die UDP- und TCP-basierte Kommunikation. Es unterstützt IPv4 und IPv6 sowie

den parallelen Betrieb von IPv4 und IPv6 in einem Steuergerät. Die folgenden Protokolle sind enthalten:

> UDP und TCP

Für einige Anwendungsfälle, beispielsweise bei der Kommunikation mit Fahrzeug-externer Infrastruktur, werden zusätz-

liche Funktionen eines TCP/IP-Stacks benötigt. Hierfür sind im Modul TCPIP bereits über den AUTOSAR Standard hin-

ausgehende Funktionen enthalten.

Im Zusammenhang mit der Ethernet-Switch-Unterstützung in AUTOSAR 4.2 wurde das TCPIP-Modul um einen DHCPv4-

Server ergänzt, der IP-Adressen Switch Port-basiert vergibt. Dieser DHCPv4-Server ist als TCPIP-Add-on verfügbar.

Add-Ons

Mindestens eines der Add-Ons ist für ein funktionsfähiges TCPIP nötig.

> TCPIP v4: IPv4, ICMPv4, ARP und DHCPv4 (Client)

> TCPIP v6: IPv6, ICMPv6, NDP und DHCPv6 (Client)

> vIpSec – Vector Internet Security: Informationen zur Vector Internet Security (vIpSec) entnehmen sie bitte dem Kapi-

tel "MICROSAR Security".

>

Sd: Service Discovery (Sd) ist erstmals in AUTOSAR 4.1.1 spezifiziert. Über das in diesem Modul implementierte Protokoll

teilt ein Steuergerät seinen Kommunikationspartnern die Verfügbarkeit seiner Dienste mit. Zusätzlich können sich Steu-

ergeräte registrieren, um automatische Benachrichtigungen zu erhalten, z.B. bei einem Signalupdate.

>

Mittels UDP Network Management (UdpNm) realisieren Sie das synchrone Einschlafen von Ethernet-Steuergeräten.

7.3.1 Vector Module als Erweiterung des AUTOSAR-Standards

>

Informationen zur Vector Ethernet Firewall (vEthFw) entnehmen sie bitte dem Kapitel "MICROSAR Security".

>

Das Vector Ethernet Testability Module (vEtm) implementiert eine standardisierte Gegenstelle für Protokoll-Konformi-

tätstests. Über dieses Modul kann eine extern angeschlossene Testumgebung definierte Aktionen im TCP/IP-Stack aus-

lösen, wie beispielsweise das Versenden eines UDP Pakets oder der Aufbau einer TCP-Verbindung. Das vEtm-Modul wird

in AUTOSAR 4.3 spezifiziert und ist als Erweiterung verfügbar.

>

MICROSAR

30

Informationen zur Vector Transport Layer Security vTls (Client) entnehmen sie bitte dem Kapitel "MICROSAR Security".

>

Das Modul vEcuAuth implementiert die Authentifizierung gemäß der IEEE 802.1X.




7.4 Konfiguration


Produktinformation.

Die Ethernet- und TCP/IP-spezifischen Konfigurationsparameter werden für AUTOSAR 3.x als Erweiterung in der „ECU Con-

figuration Description (ECUC)“ gespeichert. Dies gilt auch innerhalb von AUTOSAR 4.x für die nicht spezifizierten Konfigurati-

onsparameter.

7.5 Weitere relevante MICROSAR Produkte

Entsprechend der AUTOSAR-Architektur bildet MICROSAR.ETH zusammen mit den BSW-Modulen aus den separat erhältli-

chen Paketen MICROSAR.MCAL und MICROSAR.EXT einen kompletten Kommunikations-Stack für Ethernet und TCP/IP.

> Für die Anbindung von MICROSAR.ETH an die Hardware benötigen Sie noch folgende BSW-Module:

> HW-spezifischer Ethernet-Treiber (EthDrv aus MICROSAR.MCAL)

> HW-spezifische Transceiver-Ansteuerung (ETHTRCV aus MICROSAR.EXT)

> Optional: HW-spezifischer Ethernet-Switch-Treiber (EthSwt aus MICROSAR.MCAL und EthSwt EXT aus MICRO-

SAR.EXT)

> Die Module in MICROSAR.MCAL und MICROSAR.EXT sind für viele Mikrocontroller, Transceiver als auch Switches erhält-

lich.

> Sollen PDUs an andere Software-Module des AUTOSAR-Stacks weitergeleitet werden, benötigen Sie meistens zusätzlich

das PDU-Router (PDUR)-Modul aus dem MICROSAR.COM Paket.

> Zur Steuerung des Ethernet- und TCP/IP-Stacks können die Module aus dem Paket MICROSAR.SYS verwendet werden:

> ComM: Zentrale Koordinationsstelle zum Starten und Herunterfahren der Kommunikations-Stacks

> Nm: Zentrale Koordinationsstelle für das Netzwerk-Management

> BswM: Mode-Management Modul, unter anderem zur Steuerung von Service Discovery

> StbM: Übergeordneter Zeit-Koordinator mit dem eine Zeitsynchronisation zwischen unterschiedlichen Netzwerken und

Bussystemen realisiert werden kann

> Det: Erkennung und Auswertung von Fehlern während der Entwicklungszeit

> Dem: Das Dem-Modul aus dem Paket MICROSAR.DIAG können Sie zur Verwaltung der erkannten Systemereignisse

(Fehler und Umgebungsdaten) einsetzen.


wendung in Verbindung mit CANoe.XCP/AMD sowie CANape optimiert. Für Ethernet-Steuergeräte bietet MICROSAR

XCP die passende Transportschicht ETHXCP.

> VX1000If: In vielen Fällen dürfen in Serienprojekten aus Sicherheitsgründen die Mess- und Kalibrierschnittstellen nicht

mehr verwendet werden. Das Modul VX1000If ermöglicht es, den Vector VX1000 Mess- und Kalibrier-Hardware Treiber

in einem deaktivierten Zustand in der BSW auch im Rahmen von Serienprojekten zu belassen. Über ein API kann die

VX1000 Treiber Funktion für Prüf- und Entwicklungszwecke wieder freigegeben werden. Die Lieferung muss im Rahmen

eines MICROSAR SIPs erfolgen um eine Freigabe für die Nutzung dieser Vorgehensweise im Serieneinsatz zu erhalten.

Eine Aktivierung des VX1000 Treibers im Serieneinsatz zur Laufzeit ist jedoch auch bei Verwendung des Moduls VX1000If

nicht gestattet.

MICROSAR

31

> Die Vehicle-to-Grid-Anwendungsfälle sind über die Module des MICROSAR.V2G Pakets abgedeckt. Ebenfalls auf MICRO-

SAR.ETH aufbauend, stehen die Module aus MICROSAR.AVB für Audio/Video Bridging zur Verfügung.

7.6 Weitere relevante Produkte für Ethernet

Mit der CANoe-Option „.Ethernet“ erweitern Sie Ihre bestehende CANoe Installation komfortabel um die Möglichkeit, Ether-

net-basierte Kommunikation zu analysieren und zu simulieren.

Als Hardware-Interface, insbesondere bei Verwendung von 100BASE-T1 (ehemals BroadR-Reach®) als physikalische Schicht,

bietet sich das VN5610 Netzwerk-Interface an. Dieses bietet neben zwei Ethernet-Kanälen (individuell für 100BASE-T1 bzw.

100BASE-TX/1000BASE-T konfigurierbar) auch zwei Highspeed CAN Kanäle. Für Test- und Simulationsaufbauten mit mehr

Ethernet-Verbindungen ist die VN5640 bestens geeignet. Sie bietet 16 Ethernet-Kanäle (12-mal 100BASE-T1 und vier-mal

100BASE-TX/1000BASE-T) und ist sehr flexibel konfigurierbar.

7.7 Die Vector Toolchain für die Entwicklung von Ethernet-Steuergeräten

Bild 14: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet-Projekte

MICROSAR

32

8 MICROSAR.CHARGE – Basissoftware-Module für die Kommunikation mit externer Infrastruktur

Das Paket MICROSAR.CHARGE enthält BSW-Module für das intelligente Laden von Elektro- und Hybridfahrzeugen und für

die Kommunikation mit der Infrastruktur über Internettechnologien, wie z.B. HTTP. Alle Module aus diesem Paket sind nicht in

AUTOSAR spezifiziert. Allerdings sind sie nahtlos in die Vector AUTOSAR-Lösung integriert. Die Erweiterungen werden sowohl

für AUTOSAR 4.x als auch für AUTOSAR 3.x angeboten. Als Basis für MICROSAR.CHARGE werden Module aus dem MICRO-

SAR.ETH Paket benötigt.

Bild 15: Die MICROSAR.CHARGE BSW-Module, eingebettet in eine AUTOSAR 4.3 Umgebung

8.1 Die Vorteile von MICROSAR.CHARGE im Überblick

> Implementierung aller notwendigen Protokolle für Smart-Charging-Communication (vScc)

> Unterstützung der Kommunikation über Internet-Mechanismen und -Protokolle

> Nahtlose Integration aller BSW-Module in eine AUTOSAR-Umgebung

> Einfache Einbindung von kundenspezifischen Funktionen durch generische Schnittstellen


MICROSAR.CHARGE ermöglicht Ihnen im Zusammenspiel mit einer entsprechenden Ladesäule das intelligente Laden von

Elektro- und Hybridfahrzeugen. Unterstützt werden die Standards

> ISO 15118 und

> DIN SPEC 70121

> CHAdeMO

> GB/T 27930

mit den dazugehörigen Möglichkeiten zum Wechsel- und Gleichstromladen (AC und DC), Wireless Power Transfer (WPT), Au-

tomatic Charging Device (ACD) und Bi-directional Power Transfer (BPT).

Mit den Modulen des Pakets MICROSAR.CHARGE kann Ihr Steuergerät zusätzlich über gängige Internet-Protokolle mit einem

Server kommunizieren.

MICROSAR

33

Bei Bedarf kann die Kommunikation auch verschlüsselt stattfinden.

8.3 Vector Module als Erweiterung des AUTOSAR Standards

Die folgenden BSW-Module sind in MICROSAR.CHARGE enthalten und stellen eine Erweiterung zu AUTOSAR dar.

>

Das Modul vDNS enthält einen DNS-Resolver. Dieser ist für die Auflösung einer Domain, z.B. vector.com, in eine gültige

IP-Adresse zuständig

>

Das Modul vHttp übermittelt beispielsweise Browseranfragen an einen Server. Das Modul enthält einen HTTP-Client. Es

kommt im Vehicle2Grid-Umfeld zum Einsatz.

>

Mit dem Modul vXmlSecurity erzeugen oder validieren Sie XML-Signaturen welche an EXI-kodierten Daten angehängt

sind oder angehängt werden und auf dem W3C XML-Security-Standard basieren. Das wird benötigt, wenn „Plug and

Charge“ nach ISO 15118 verwendet wird.

>

Mit dem Modul vExi werden XML-Dokumente interpretiert und in ein Binär-Format konvertiert. Damit lassen sich die

Dateien effizienter verarbeiten und übertragen um Kommunikationsbandbreite einzusparen. Es kommt im Vehicle2Grid-

Umfeld zum Einsatz.

>

Dieses Modul ist zuständig für die Smart-Charging-Communication nach ISO 15118 und DIN SPEC 70121.

Add-Ons

> AC: Wechselstromladen

> DC: Gleichstromladen

> ACD: Automatic-Charging-Device (Laden mittels Pantographen)

> WPT: Wireless-Power-Transfer (Induktivladen)

> BPT: Bidirectional-Power-Transfer (Energie-Rückspeisung)

> <OEM>: Stellt vom <OEM> spezifizierte Applikationsschnittstellen bereit

> –

Dieses Modul beinhaltet die standardisierte Ladekommunikation für das Gleichstromladen gemäß der Spezifikation

GB/T 27930 für China. Für diesen Ladestandard kann optional eine Diagnose-Unterstützung entwickelt werden.

>

Dieses Modul beinhaltet die standardisierte Ladekommunikation für das Gleichstromladen gemäß der Spezifikation

CHAdeMO.

Darüber hinaus sind die folgenden Module für AUTOSAR 3.x erhältlich. Für AUTOSAR 4.x sind sie nur auf Anfrage verfügbar.

>

Das Modul XML Engine enthält einen Parser zum Verarbeiten und einen Generator zum Erstellen von gültigen XML 1.0-

Dokumenten. Es kommt im Vehicle2Grid-Umfeld zum Einsatz

>

Dieses Modul enthält einen JSON-Parser. JSON ist ein JavaScript-basiertes Datenaustauschformat und kann anstelle

von XML verwendet werden.

8.4 Konfiguration

Die Module des MICROSAR.CHARGE Pakets werden mit dem „DaVinci Configurator Pro“ konfiguriert. Mehr Details finden Sie

in der separaten Produktinformation.

MICROSAR

34

Die spezifischen Konfigurationsparameter werden als Erweiterung in der „ECU Configuration Description“ gespeichert.


MICROSAR.CHARGE baut auf dem MICROSAR.ETH Paket auf und benötigt den darin enthaltenen Ethernet- und TCP/IP-

Stack als Basis für die Kommunikation. Dies umfasst folgende Module:

> Ethernet Interface (EthIf) zur Abstraktion der darunterliegenden Hardware

> Ethernet State Manager (EthSM) zum Ein- und Ausschalten der Ethernet-basierten Kommunikation

> Den TCP/IP-Stack (TcpIp) mit der entsprechenden IP Version (IPv4 und/oder IPv6)

Zusätzlich werden ein Ethernet-Treiber (Eth (EXT)) und ein Ethernet-Transceiver-Treiber (EthTrcv) aus MICROSAR.EXT benö-

tigt. Hier sind für den Fall von Smart-Charge-Communication spezielle Treiber und Transceiver-Treiber für Powerline-Kommu-

nikation (PLC) verfügbar.

Falls die Steuerung der Smart-Charging-Communication über eine AUTOSAR-Softwarekomponente realisiert ist, empfehlen

wir die Verwendung der MICROSAR.RTE und MICROSAR.CRYPTO.

Für die Erkennung und Auswertung von Fehlern während der Entwicklungszeit steht Ihnen das Modul DET aus MICROSAR.SYS

zur Verfügung.

Das Modul DEM aus dem Paket MICROSAR.DIAG können Sie zur Verwaltung der erkannten Systemereignisse (Fehler und

Umgebungsdaten) einsetzen.


Mit der entsprechenden CANoe-Option für Ethernet erweitern Sie Ihre bestehende CANoe-Installation komfortabel um die

Möglichkeit, Ethernet-basierte Kommunikation zu analysieren und zu simulieren. Mit dem Smart-Charging-Communication

Add-On können Sie in CANoe zudem den SCC-Datenverkehr analysieren. Damit sind Sie in der Lage, basierend auf der ISO

15118 oder der DIN SPEC 70121, komplexe Fahrzeug- und Ladesäulen-Simulationen aufzubauen.

Für das VT-System bietet Vector eine Einschubkarte für Powerline-Kommunikation an.

8.7 Die Vector Toolchain für die Entwicklung von Ethernet/CHARGE-Steuergeräten

Bild 16: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet/CHARGE-Projekte

MICROSAR

35

9 MICROSAR AVB – Basissoftware-Module für die Audio-/Video-Kommunikation via Ethernet

MICROSAR.AVB (Audio/Video Bridging) über Ethernet ermöglicht eine schnelle und zuverlässige Übertragung von Audio/Video

Daten. Das Paket MICROSAR AVB enthält verschiedene BSW-Module, die auf dem Ethernet-Interface, z.B. aus MICRO-

SAR.ETH, aufsetzen. Die auf AUTOSAR 4.x basierte Lösung unterstützt vAvTp (Audio/Video Transport Protocol), vRtp (Trans-

port Protocol for Real-Time Applications), vSrp (Stream Reservation Protocol), EthTSyn (Time Synchronization over Ethernet)

und auf Anfrage BMCA (Best Master Clock Algorithm). Damit ergibt sich die Möglichkeit, AVB-Endpunkte sowie Bridge-Funk-

tionalität zu implementieren.

Bild 17: Die MICROSAR AVB BSW-Module nach AUTOSAR 4.3

9.1 Die Vorteile von MICROSAR AVB im Überblick

> Die BSW-Module sind für AUTOSAR optimiert, können aber auch in anderen Umgebungen eingebunden werden

> Problemlose Integration in den Ethernet-Stack MICROSAR.ETH. Dies ermöglicht z.B. die parallele Verwendung von AVB,

DoIP und TCP/IP.

> Einfaches Einbinden von kundenspezifischen Funktionen und Modulen

> Unterstützung diverser Ethernet-Controller, inkl. AVB-spezifischen Hardware-Funktionen

> Unterstützung von VLANs zur Trennung und Priorisierung von Daten, z.B. für Audio, Video und Diagnose


9.2.1 A/V-Streaming

MICROSAR vAvTp und vRtp ermöglichen den Austausch von Audio/Video Daten, inklusive deren Zeitstempel, zwischen ver-

schiedenen Endpunkten. Das vAvTp ist ein Schicht 2 Protokoll und ist nach der Spezifikation IEEE 1722/1722a umgesetzt. Das

vRtp hingegen ist ein Schicht 3 Protokoll und setzt auf UDP auf. vRtp ist nach der Spezifikation IETF RFC 3550 umgesetzt.

MICROSAR

36

9.2.2 Auswahl des genauesten Zeitgebers

Bevor eine systemweit genaue Zeit dargestellt werden kann, muss das Gerät mit dem genauesten Zeitgeber (Grand-Master)

festgelegt werden. Dieser wird typischerweise statisch vorgegeben oder dynamisch mittels BMCA ermittelt. Dabei kommt die

Spezifikation IEEE 802.1AS zum Einsatz.

9.2.3 Darstellung einer synchronen Systemzeit

Das Steuergerät mit der genauesten Zeit verteilt diese im Netzwerk. Somit arbeiten alle Endpunkte und Bridges mit der glei-

chen, vom Grand-Master vorgegebenen Zeit. Dadurch ist es möglich, einen A/V-Datenstrom zu übertragen und zeitsynchron

wiederzugeben. Das Protokoll zur Verteilung des Zeitstempels ist im AUTOSAR Basis-Software-Modul EthTSyn nach der Spe-

zifikation IEEE 802.1AS umgesetzt.

Um eine exakte Zeitmessung zu ermöglichen, ist zur Erhöhung der Genauigkeit eine erweiterte Hardware-Unterstützung not-

wendig, die im „Add-On Time Sync“ des Ethernet bzw. Switch-Treibers umgesetzt ist.

9.3 Vector Module als Erweiterung des AUTSOAR Standard

Die folgenden BSW-Module aus MICROSAR AVB enthalten die in den oben genannten IEEE-Spezifikationen definierten Funk-

tionen. Hinzu kommen alle notwendigen Software-Merkmale, die eine nahtlose Integration in eine AUTOSAR-Umgebung zu-

lassen.

>

Das Modul vAvTp ist in der IEEE 1722 spezifiziert und in AVB-Netzwerken zuständig für den Transport der Audio-/Video-

Daten inklusive der Präsentationszeit.

> Schnittstelle zum Modul EthIf für das Empfangen und Versenden von AVTP-Frames

> Unterscheidung zwischen Stream- und Control-Kanal

> Darstellung und Validierung des Zeitstempels

> Erkennung des transportierten Daten-Streams

>

> Registrierung von Datenströmen mit Identifizierung und Zugriffskontrolle

> Stellt sicher, dass alle AVB-Bridges für jede Stream-ID die passende Bandbreite reservieren

>

> Registrierung von Datenströmen mit Zugriffskontrolle für mehrere Ströme aus verschiedenen Endstationen

> Stellt sicher, dass die gesamte reservierte Bandbreite für ein Ethernet-AVB-Netzwerk einen vordefinierten Grenzwert

nicht überschreitet.

>

Das Modul vRtp ist eine echtzeit-fähiges Streaming Protokoll mit Uni-/Multicast Unterstützung. Das RealTime Control

Protocol (RTCP) zur Aushandlung und Einhaltung von Quality-of-Service-Parametern (QoS) ist ebenfalls enthalten. Ins-

gesamt werden folgende Profile unterstützt:

> IETF RFC 6184 RTP Payload Format for H.264 Video

> IEEE 1733 Layer 3 Transport Protocol for Time-Sensitive Applications in Local Area Networks.

Bereitstellung einer Ende-zu-Ende Netzwerktransportfunktion passend für Anwendungen, welche über Multicast oder

Unicast Netzwerkdienste Echtzeitdaten übermitteln, wie beispielsweise Audio, Video oder Simulationsdaten.

Unterstützung folgender Profile:

9.4 Konfiguration


Produktinformation.

Die AVB-spezifischen Konfigurationsparameter werden als Erweiterung in der „ECU Configuration Description“ gespeichert.

MICROSAR

37

9.5 Schnittstellen zu angrenzenden MICROSAR Produkten

Entsprechend der MICROSAR Architektur bildet MICROSAR AVB zusammen mit den BSW-Modulen aus den separat erhältli-

chen Paketen MICROSAR.MCAL, MICROSAR.EXT und MICROSAR.ETH einen kompletten Kommunikations-Stack für AVB im

Automobil. Für die Anbindung von MICROSAR AVB an die Hardware benötigen Sie noch folgende BSW-Module:

> HW-spezifischer Ethernet-Treiber (Eth aus MICROSAR.MCAL)

> HW-spezifische Transceiver-Ansteuerung (EthTrcv aus MICROSAR.EXT)

> Ethernet Treiber Abstraktions- und Steuerungsschicht (EthIf, EthSM aus MICROSAR.ETH)

Die Module in MICROSAR.MCAL und MICROSAR.EXT sind bereits für viele Mikrocontroller bzw. Transceiver erhältlich und wer-

den bei Bedarf auch für neue Mikrocontroller und Transceiver entwickelt.

9.6 Weitere relevante MICROSAR Module für Ethernet

> TcpIp, SoAd, DoIp, SomeIp aus MICROSAR.ETH

> Dcm und Dem aus MICROSAR.DIAG

> Det, EcuM, ComM und Nm, aus MICROSAR.SYS

> MICROSAR XCP


Mit der entsprechenden CANoe-Option ".Ethernet" erweitern Sie Ihre bestehende CANoe-Installation komfortabel um die

Möglichkeit, Ethernet- und AVB-basierte Kommunikation zu analysieren und zu simulieren.

Als Hardware-Interface, insbesondere bei Verwendung von BroadR-Reach® als physikalische Schicht, bietet sich das VN5610

Netzwerk-Interface an. Dieses bietet neben zwei Ethernet-Kanälen (individuell für BroadR-Reach® bzw. 100BASE-TX konfigu-

rierbar) auch zwei Highspeed CAN-Kanäle.

9.8 Die Vector Toolchain für die Entwicklung von Ethernet/AVB-Steuergeräten

Bild 18: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet/AVB-Projekte

MICROSAR

38

10 MICROSAR.MEM – AUTOSAR Basissoftware-Module für das Memory Management

Das Paket MICROSAR.MEM enthält alle AUTOSAR-Module für das Memory Management: NvM, MemIf, Ea und Fee. Sie unter-

stützen das Verwalten, Prüfen und Wiederherstellen von Daten aus nichtflüchtigen Speichern (Flash oder EEPROM). Die Ba-

sissoftware-Module (BSW) aus MICROSAR.MEM sind schnell, zuverlässig und robust.

Bild 19: Die MICROSAR.MEM Module nach AUTOSAR 4.3

10.1 Die Vorteile von MICROSAR.MEM im Überblick


> Besonders sichere Datentransaktionen

> Effiziente Datenzugriffe

> Effiziente und robuste Verwaltung von nichtflüchtigen Speichern

> Redundante Ablage von Management-Daten steigert die Zuverlässigkeit der Daten-Zugriffe

> Modulübergreifende Konfiguration des gesamten Memory-Stacks

> Plattform-optimierte Memory-Stack Lösung aus einer Hand erhältlich


MICROSAR.MEM enthält die Dienste zum Lesen, Schreiben und Löschen von persistenten Anwendungsdaten in Flash- und/o-

der EEPROM-Speichern. Dadurch hat die Funktionssoftware einen Hardware-unabhängigen Zugriff auf den Speicher. Die Ap-

plikation braucht nicht zu wissen, welcher Speicher konkret auf der Plattform vorhanden und ob dieser Speicher intern oder

extern mit dem Controller verbunden ist.


Die BSW-Module in MICROSAR.MEM enthalten die in AUTOSAR 4.x definierten Funktionen. In jedem Memory-Stack sind die

BSW-Module NvM und MemIf aus MICROSAR.MEM erforderlich. Sie übernehmen – ohne Kenntnisse der Speicherattribute –

den blockorientierten und technologie-unabhängigen Zugriff auf die Speicherbereiche. Je nach Anwendungsfall benötigt Ihr

Memory-Stack zusätzliche BSW-Module:

MICROSAR

39

> Bei Verwendung eines Flash Speichers: Flash-EEPROM Emulation (Fee) z.B. aus MICROSAR.MEM und einen für Ihre

Hardware geeigneten Flash Treiber (Fls) im Rahmen unserer Dienstleistung des MCAL Integration Package oder für ex-

terne Speicher (EXT) aus MICROSAR.EXT. Zur Verwaltung der Daten braucht das FEE-Modul mindestens zwei physikali-

sche Flash-Sektoren.

> Bei Verwendung eines EEPROMs: EEPROM Abstraction (EA) aus MICROSAR.MEM und einen für Ihre Hardware geeigne-

ten EEPROM Treiber (EEPDRV), beispielsweise für externe Speicher das Modul DRVEXT aus MICROSAR.EXT.

Der gemischte Einsatz von Flash- und EEPROM-Bausteinen in einem Steuergerät ist möglich.

Für spezielle Anforderungen erhalten Sie von Vector plattformoptimierte Lösungen, wie z.B. den Einsatz des BSW-Moduls EA

beim DataFlash oder ein hardwareoptimiertes Fee-Modul.

>

Das Ea-Modul bietet eine hardware-unabhängige Schnittstelle für den Zugriff auf EEPROM Daten und verwendet dafür

einen EEPROM Treiber (Eep). Neben dem Lesen, Schreiben und Löschen von Daten verteilt das Modul Ea Schreibzugriffe

auf verschiedene Bereiche des EEPROMs, so dass alle EEPROM-Zellen gleichmäßig beansprucht werden und sich damit

ihre Lebensdauer erhöht.


> Zusätzliche, konfigurierbare Transaktionssicherheit, wie sie standardmäßig im Modul Fee enthalten ist

> Redundante Ablage von Management-Daten zur Steigerung der Zuverlässigkeit der Datenzugriffe

>

Das Modul Fee bietet eine hardware-unabhängige Schnittstelle für den Zugriff auf Flash-Daten und verwendet dafür

einen Flash Treiber (Fls). Neben dem Lesen, Schreiben und Löschen von Daten verteilt das Modul Fee die Schreibzugriffe

auf verschiedene Bereiche des Flash-Speichers, so dass alle Flash-Zellen gleichmäßig beansprucht werden und sich

dadurch ihre Lebensdauer erhöht.

Die Variante "Small sector Fee" wird empfohlen, wenn ein Flash Speicher mit einer hohen Zahl an Sektoren mit kleiner

Sektor-Größe benutzt wird. Die Variante bietet die Vorteile, dass weniger Management Daten gespeichert werden müs-

sen, so dass mehr Platz für Nutzerdaten zur Verfügung steht. Auch die Evaluierung des gültigen Nutzerdatensatzes ist

deutlich schneller, so dass dem entsprechend das Hochstarten und auch die Schreibvorgänge schneller ablaufen.


> Leistungsfähige Verwaltung der Speicherdaten

> Gemeinsame Nutzung des FEE-Moduls durch Flash Bootloader (FBL) und Anwendung möglich - auch mit gemeinsa-

men Speicher-Blöcken. Dabei kann die Aktualisierung der Steuergerätesoftware ohne Anpassung des FBLs erfolgen.

> Redundante Ablage von Management-Daten zur Steigerung der Zuverlässigkeit der Datenzugriffe

> Flexible Platzierung der Fee-Sektoren im DataFlash

> Services für die Behandlung von Unterspannungs-Situationen

> Trennung von z.B. häufig geschriebenen Daten von äußerst wichtigen Daten durch Einführung von Partitionen. Damit

wird bei Fehlersituationen (z.B. Reset während des Schreibens bzw. Löschens von Daten) die Verfügbarkeit der Daten

noch weiter erhöht.

> Update-Unterstützung zur Anpassung des nichtflüchtigen Speichers nach Steuergeräte-Umprogrammierung mit

neuer Konfigurationstabelle (Inhalt und Größe)

>

Das Modul MemIf bietet einen einheitlichen Zugriff auf die Dienste von Ea und Fee. Dadurch können Sie mehrere Instan-

zen dieser Module verwenden.

>

Das NvM-Modul verwaltet, liest und schreibt Daten in einem nichtflüchtigen Speicher (Ea oder Fee). Beim Systemstart

und beim Herunterfahren synchronisiert es die Daten in den RAM-Bereichen der Applikation. Das Modul stellt Dienste

wie z.B. die Speicherung von redundanten Blöcken für eine höhere Datensicherheit zur Verfügung.

MICROSAR

40

Seit AR 4.0.3 stellt die RTE ergänzend ein einfacheres und flexibleres Interface auf Nv-Daten zur Verfügung (NvDataIn-

terfaces).


> Allokierung von RAM zur CRC-Speicherung

> Dedizierte Schnittstelle zum Diagnose-Modul DCM zum direkten Auslesen und Modifizieren von Datenblöcken

> Zusätzliche, konfigurierbare Transaktionssicherheit, wie sie standardmäßig im Modul FEE enthalten ist

10.4 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Dieser enthält einige arbeitserleichternde

Funktionen wie Optimierungshilfen, optische Darstellung der Flash-Auslastung u.s.w. Mehr Details finden Sie in der separaten

Produktinformation.

Bild 20: Konfiguration der MICROSAR.MEM Module mit DaVinci Configurator Pro

10.5 Weitere relevante MICROSAR Produkte für Ihren Memory-Stack

Entsprechend der AUTOSAR-Architektur bilden die Memory-Dienste aus MICROSAR.MEM zusammen mit weiteren plattform-

spezifischen BSW-Modulen aus dem separat erhältlichen Paket MICROSAR.MCAL und MICROSAR.EXT einen kompletten Me-

mory-Stack.

> Fls und/oder Eep aus dem MCAL Integration Package

> Ext aus MICROSAR.EXT für externe Speicherbausteine

Darüber hinaus lassen sich MCAL-Treiber von Halbleiterherstellern problemlos in den MICROSAR Memory-Stack integrieren.

Abhängig von der gewünschten Sicherheitsstufe können Sie Ihre Speicherdaten mit dem Checksummen-Modul (Crc) aus dem

Paket MICROSAR.LIBS absichern.

MICROSAR

41

11 MICROSAR.SYS – Systembezogene Basissoftware Module für AUTOSAR

Die Systemdienste aus den MICROSAR.SYS Basissoftware Modulen (BSW) decken einen wichtigen Teil der Grundfunktionali-

tät Ihres AUTOSAR-Steuergeräts ab. Sie werden von der Funktionssoftware (via Rte) und den übrigen BSW-Modulen aufge-

rufen. Die Module von MICROSAR.SYS bieten alle wichtigen Funktionen für das Zustands-Handling des Steuergerätes.

Bild 21: Die MICROSAR.SYS Module nach AUTOSAR 4.3

11.1 Die Vorteile von MICROSAR.SYS im Überblick


> Das Modul ECUM ist entweder in der ressourcensparenden Pre-compile- Variante oder als flexible Post-build–Lösung

enthalten. Nähere Informationen hierzu finden Sie im Kapitel "Identity Manager für AUTOSAR"

> Einfache Konfiguration der initialen BSWM und ECUM durch Assistenten mit DaVinci Configurator Pro

> Anlegen von Initialisierungs- Sequenzen

> Konfiguration einer ECU state machine (Startup, shutdown, …)

> Verwaltung der Kommunikationsmodi


Die Systemdienste enthalten das Power- und Mode-Management, die Kontrolle aller Kommunikationskanäle und Teilnetze, die

Überwachung der einzelnen Softwarekomponenten (SWC) der Funktionssoftware und innerhalb von AUTOSAR 3.x das

Scheduling aller BSW-Module.


Die BSW-Module in MICROSAR.SYS enthalten die in AUTOSAR 4.x definierten Funktionen:

>

MICROSAR

42

Der Basic Software Mode Manager verwaltet die Modusänderungswünsche aus den BSW-Modulen sowie den SWCs und

führt sie entsprechend der standardisierten Aktionslisten durch. Beispielsweise ist das Modul BSWM für das Ein- und

Ausschalten von PDU-Gruppen und NM-PDUs für die Diagnose zuständig.


> Unterstützung des Teilnetzbetriebs

>

Der „Communication Manager“ kontrolliert den Zustandswechsel der am Steuergerät angeschlossenen Kommunikati-

onskanäle sowie der im Steuergerät konfigurierten Teilnetze. Er hält das Steuergerät bei Bedarf wach und kommunikati-

onsfähig. Weiterhin koordiniert er den Zugriff aller SWCs auf die Kommunikationskanäle und Teilnetze. Optional unter-

stützt COMM den Bus Type „Internal“.


> Kompatibel zu OSEK Nm (für AUTOSAR 3.x)

> Unterstützung des Teilnetzbetriebs

>

Der Default Error Tracer sammelt Fehler während dem Entwicklungsprozess aus den SWCs und den BSW-Modulen. Op-

tional unterstützt DET auch Service Ports.

>

Der ECU State Manager ist für Startup, Shutdown und WakeUp zuständig. In AUTOSAR 3.x gibt es weitere fest defi-

nierte Betriebszustände, die der EcuM verwaltet. In AUTOSAR 4.x werden diese Betriebszustände flexibel vom Anwender

im BSWM definiert. Damit lassen sich individuelle Energiesparzustände realisieren oder unterschiedliches Hochfahrver-

halten erzielen.


> Das ECUM-Modul ist gemäß der AUTOSAR ECUM Flex Spezifikation implementiert und bietet daher ein hohes Maß an

Konfigurationsmöglichkeiten, um auch komplexe Zustandsübergänge zu unterstützen. Für die Entwicklung von Steuer-

geräten mit reduzierten Anforderungen an das Zustandsmanagement, kann sich das ECUM-Modul optional auch kom-

patibel zur AUTOSAR ECUM Fixed Spezifikation verhalten. In diesem Fall bietet das ECUM-Modul die folgenden Funk-

tionalitäten:

> EcuM Run Request Protokoll

> EcuM Zustandsmanagement

> EcuM Fixed kompatible Service SWC Schnittstellen

>

Der STBM ermöglicht eine zeitgenaue Synchronisation zwischen verschiedenen Teilen der ECU Software. Er stellt dazu

den BSW-Modulen und den SWCs eine oder mehrere gemeinsame Zeitbasen zur Verfügung. Seit AR 4.2 kann eine von

einem Time-Master vorgegebene Zeitbasis mit anderen Steuergeräten über Bussysteme synchronisiert werden. Für die

Bus-Systeme CAN, FR und ETH steht mit dem Tsyn-Modul ein Communication Service für die fahrzeugweite Zeitsyn-

chronisation von Steuergeräten zur Verfügung.

>

Mit dem Tm-Modul messen Sie z.B. Laufzeiten von Funktionen und realisieren das aktive Warten. Es bietet eine Auflö-

sung von 1µs bis 4,9 Tagen.

>

Das Modul WdgIf ermöglicht einen einheitlichen Zugriff auf Dienste des Watchdog-Treibers (Wdg) wie z.B. Modus-

Wechsel und das Triggern. Für sicherheitsrelevante Steuergeräte muss das Modul WdgIf nach ISO 26262 entwickelt sein.


> Präzises Überwachen der Einhaltung definierter Zeitfenster für den Watchdog (auch für hochauflösende Window-

Watchdogs)

MICROSAR

43

> WdgM – Watchdog Manager

Das Modul WdgM überwacht in einem Steuergerät die Zuverlässigkeit und Funktionssicherheit der Applikationen. Dazu

gehört das Überwachen der korrekten Ausführung von SWCs und BSW-Modulen und das Triggern der Watchdogs in den

erforderlichen Zeitabständen. Das WdgM-Modul reagiert mit mehreren Eskalationsstufen auf ein mögliches Fehlverhal-

ten. Wichtig für sicherheits-relevante Funktionen nach ISO 26262 ist die Überwachung der korrekten Ablaufreihenfolge

von kritischen Tasks (logical supervision). Für sicherheitsrelevante Steuergeräte muss das Modul WdgM nach ISO 26262

entwickelt sein.

Add-Ons

>Prog.Flow + Deadline Monitoring

Der Watchdog Manager bietet Program Flow und Deadline Monitoring zur Überwachung der SWCs


> Präzises Überwachen der Einhaltung definierter Zeitfenster für den Watchdog (auch für hochauflösende Window-

Watchdogs)

> Der Watchdog Manager überwacht das korrekte Verhalten der Funktionssoftware mit Hilfe der Module WdgIf und

Wdg (MICROSAR.MCAL).






11.4 Der Basis Software Manager (BSWM)

Der BSWM ist zentraler Bestandteil des Mode Management und nach dem AUTOSAR4-Standard implementiert. Zahlreiche

wertvolle Erweiterungen über den AUTOSAR-Standard hinaus erhöhen den Komfort beim konfigurieren Ihrer Steuergerä-

tesoftware.

Das BswM-Modul in AUTOSAR 4 erlaubt eine völlig freie Konfiguration von Arbitrierungsregeln, logischen Ausdrücken und Ak-

tionen, um auf Mode-Änderungen in anderen BSW-Modulen zu reagieren oder um selbst Mode-Änderungen anzufordern.

In der Praxis kann dies schnell beliebig komplex werden, da aufgrund der von AUTOSAR vorgegebenen Konfigurationsstruktur

selbst eine einfache Konfiguration eine Vielzahl von ineinandergreifenden Schritten erfordert:

> Aktionen (Actions) müssen zu Aktionslisten (Action Lists) zusammengefasst werden.

> Diese sind mittels einer Regel (Rule) an das wahre oder falsche Ergebnis eines vorher definierten logischen Ausdrucks

(Expression) gekoppelt.

> Der zugrundeliegende logische Ausdruck besteht wiederum aus einer oder mehreren Bedingungen (Condition), die auf

den eingegangen Modes (RequestPorts) basieren.

Auch Standardaufgaben wie das Konfigurieren einer Zustandsmaschine in Anlehnung an ECUM-Fix in AUTOSAR 3, der Aufruf

der entsprechenden Initialisierungsfunktionen der BSW-Module mit den passenden Parametern oder das An- und Abschalten

von PDU-Gruppen (I-PDU) stellen selbst erfahrene Entwickler vor eine Herausforderung.

Hierbei unterstützt Sie der DaVinci Configurator Pro mit intelligenten und mächtigen Assistenten, die viele der oben erwähnten

Aufgaben bereits automatisch erstellen können. Nachfolgend können Sie diese per Click automatisch konfigurieren lassen. Dies

gilt insbesondere für

> die ECU-Zustandsmaschine (ECU State Handling, siehe Bild)

> das Initialisieren der Basissoftwaremodule (Module Initialization)

> das Schalten der PDU-Gruppen (Communication Control).

MICROSAR

44

Bild 22: Vorkonfigurierte State Machine / Auto-Configuration der BswM mit dem DaVinci Configurator Pro. Ebenfalls zu sehen sind die Auto-Configura-

tion für Module Initialization und Communication Control sowie der Bereich für Ihre freie, projektbezogene Konfiguration des BSWM (Custom

Configuration).

Dabei handelt es sich nicht um eine statische Konfiguration. Vielmehr werden alle nötigen Projektparameter berücksichtigt.

Änderungen der Parameter werden hierbei vom Tool umgehend erkannt und der Anwender erhält einen Hinweis, dass eine

Neukonfiguration notwendig ist, beispielsweise wenn eine neue PDU-Gruppe erstellt wurde.

Auch für freie Konfigurationsaufgaben wie beispielsweise das Erstellen von Regeln oder Aktionslisten hilft der DaVinci Confi-

gurator Pro mit seinen Assistenten. Er führt Sie Schritt für Schritt durch die Konfiguration, hat Know-how über mögliche und

nötige Parameter, erkennt Fehler und schlägt sofort mögliche Korrekturen vor – akzeptiert aber auch Einstellungen, die Sie

bewusst anders haben wollen.

Der MICROSAR-BSWM leistet erheblich mehr, als der AUTOSAR-Umfang vorschreibt. So ist es beispielsweise zusätzlich mög-

lich, die Auswertung von Regeln (Rules) zur Laufzeit an- und abzuschalten. Sie können einen Timer realisieren, dessen Ablaufen

der BSWM auswerten kann. Über Aktionen (Actions) können Sie den Timer starten oder stoppen. Falls noch nicht alle zu ver-

bindenden SWCs zur Verfügung stehen, kann der BSWM selbst die benötigten Mode Declarations erzeugen und gestattet

Ihnen dadurch eine Art Bottom-up Konfiguration.

11.5 Watchdog für Anwendungen nach ISO 26262

Alle Watchdog-Module sind auch als SEooCs (Safety Element out of Context) für sicherheitsrelevanten Funktionen bis ISO

26262 / ASIL D erhältlich. Sie eignen sich für die Absicherung der Laufzeitüberwachung von Tasks sowie die Ablaufkontrolle

der SWCs. Mehr Details finden Sie im Kapitel über MICROSAR Safe.

11.6 Konfiguration


Produktinformation.

MICROSAR

45

Bild 23: Konfiguration des COMM Moduls mit DaVinci Configurator Pro.


> DIAG: Der Systemdienst für die Diagnose ist in dem Paket MICROSAR.DIAG separat erhältlich.

> OS: Als Betriebssystem steht Ihnen das separat erhältliche MICROSAR.OS zur Verfügung.

> LIBS: Das Paket LIBS enthält die Cyclic Redundancy Check Library (Crc), die Crypto Abstraction Library (Cal) sowie die

E2e und ist für AUTOSAR 4.x als separates Paket erhältlich. (Für AUTOSAR 3.x ist LIBS Bestandteil von MICRO-

SAR.SYS.)

MICROSAR

46

12 MICROSAR.DIAG – AUTOSAR-kompatible Umsetzung der Diagnose Standards UDS, OBD und J1939

MICROSAR.DIAG enthält die BSW-Module für die Umsetzung der Diagnose Protokolle UDS, OBD-II, WWH-OBD und J1939

gemäß AUTOSAR und ist damit die Diagnosesoftware für Ihr Fahrzeugprojekt. MICROSAR.DIAG übernimmt eine Reihe von

Aufgaben:

> OEM-spezifische Umsetzung der Fehlerspeicherung und -verwaltung

> OEM-spezifische Umsetzung des Diagnose-Protokolls für die Kommunikation zwischen Diagnosetester und Steuergerät

> Abschalten von bestimmten Funktionalitäten aufgrund von aktiven Fehlereinträgen

> Fehlerspeicherverwaltung über mehrere Kerne hinweg

> Versenden und Empfangen von Diagnose-Botschaften als Basis für OnBoard-Tester

Kombiniert mit CANdelaStudio, dem weitverbreiteten Spezifikationswerkzeug für die Erstellung von Diagnosedaten, erhalten

Sie eine komplette Diagnoselösung aus einer Hand.

Bild 24: Die MICROSAR.DIAG Module nach AUTOSAR 4.3

12.1 Die Vorteile von MICROSAR.DIAG im Überblick

> OEM-unabhängige Lösung für AUTOSAR 4.x und 3.x.

> Spezifische Lösungen für viele Fahrzeughersteller verfügbar

> Langjährige Serienerfahrung von Vector im Bereich Diagnose

> OBD-II und WWH-OBD (Euro VI) Unterstützung

> Konfigurierbar über AUTOSAR Diagnostic Extract, CANdela- und ODX-Format

> Varianten-Handling für die Diagnosekonfiguration bereits enthalten

> Offline Kalibrierung in Kalibriertools über A2L

> Generierung von optimierten Anwendungscode-Templates

MICROSAR

47


Über den AUTOSAR-Standard hinaus hat jeder OEM eigene Anforderungen für die Diagnose. Aus diesem Grund bietet Vector

MICROSAR.DIAG mit OEM-spezifischen Erweiterungen an. Es ist für den Serieneinsatz geeignet und steht bereits für viele

OEMs zur Verfügung. Für Steuergeräte ohne spezielle Diagnose-Spezifikation ist ein OEM-unabhängiges Paket von MICRO-

SAR.DIAG erhältlich.

MICROSAR DIAG kann für heutige und zukünftige gesetzliche Anforderungen wie EURO VI eingesetzt werden. Die Unterstüt-

zung von OBD-II (ISO 15031/ SAE J1979) sowie WWH-OBD (ISO 27145) ist als Option erhältlich.

Falls Ihr Steuergerät Varianten in der Diagnosekonfiguration erfordert, bietet MICROSAR.DIAG hierfür eine leistungsstarke

Lösung an. Sie definieren bis zu 31 unterschiedliche Bedatungen und legen diese Ressourcen-optimiert im Steuergerät ab. Da-

bei werden Redundanzen in der Steuergerätesoftware vermieden, weil identische Schnittstellen auf gleiche Daten, Services

oder DTCs im generierten Diagnose-Code zusammengefasst werden.


Die BSW-Module in MICROSAR.DIAG enthalten die in AUTOSAR 4.x und 3.x definierten Funktionen der drei BSW-Module Dcm,

Dem und Fim. Die DEM-Grundfunktionalität zwischen AUTOSAR 4.x und AUTOSAR 3.x ist weitgehend identisch. Die Unter-

schiede liegen in den Schnittstellen-Definitionen. Vector bietet Ihnen eine Migrationslösung an, mit der Sie Ihre AUTOSAR 3.x-

kompatiblen SWCs in ein AUTOSAR 4.x-Projekt übernehmen können.

>

Das Dem-Modul verwaltet den Fehlerspeicher eines Steuergeräts. Es ist in OEM-spezifischen Varianten und als OEM-

unabhängige Variante für AUTOSAR 4.x und 3.x erhältlich. Standardmäßig werden vom DEM-Modul die folgenden Funk-

tionen unterstützt:

> Verwaltung aller DTC-Status Bits gemäß UDS-Standard

> Definition individueller Snapshot- und Extended Data-Records

> Vordefinierte ExtendedRecords (z.B. OccurenceCounter)

> Fehlerentprellung über Counter- und Time-based Algorithmen

> Verdrängung von niederprioren Fehlern bei vollem Speicher

> Flexibles Verlernen (Aging) von Fehlern

> Varianten-Handling für die Diagnosekonfiguration

> Link-Time Konfiguration

> Komprimierte Konfigurationsdaten zur Optimierung der Code-Größe

> Unterstützung von Sammelfehlern

> Dem-Satellite bietet Multi-core Unterstützung auf Mehrkern-Prozessoren

> für Mixed-AUTOSAR–Projekte geeignet

> Post-build loadable und Post-build selectable. Details finden Sie im Kapitel "MICROSAR Variant Handling".

Add-Ons

> OBD-II (ISO 15031 / SAE J1979) mit Unterstützung für Master und Primary OBD-Steuergeräte

> WWH-OBD (ISO 27145)

Die Basisfunktionalität des Dem ist zwischen AUTOSAR 4.x und 3.x vergleichbar und unterscheidet sich im Wesentlichen nur

durch die angebotenen Schnittstellen. Vector bietet eine Migrationslösung mit der sie einfach Ihre AUTOSAR 3.x kompatiblen

Softwarekomponenten in Ihrem AUTOSAR 4.x Projekt verwenden können.

>

Das Dcm-Modul verarbeitet die UDS- und OBD-II-Services im Steuergerät.

Die OEM-unabhängige Variante des Dcm ist sowohl für AUTOSAR 4.x als auch für AUTOSAR 3.x erhältlich. Eine kom-

plette Liste der dabei unterstützten Services finden Sie in der Tabelle am Ende dieses Kapitels.

MICROSAR

48

Die Dcm-Module für spezifische OEMs setzen die Spezifikationen des jeweiligen OEMs um. Gerne informieren wir Sie

über die Details.


> Varianten-Handling für Diagnosekonfigurationen

> Nahtlose Zusammenarbeit mit dem Vector Flash Bootloader

> Generierung eines Anwendungscode-Templates für die Steuergerätesoftware (AUTOSAR 3.x)

Add-Ons

> Unterstützung von OBD-II (ISO 15031-5)

> WWH-OBD (ISO 27145)

>

Der MICROSAR FIM enthält standardmäßig den Funktionsumfang von AUTOSAR 4.x und 3.x.

>

Das speziell für Nutzfahrzeuge konzipiertes Modul J1939Dcm realisiert Diagnostic Messages des SAE J1939-73-Proto-

kolls z.B. zum Auslesen des Fehlerspeichers.

12.3.1 Vector Module als Erweiterung des AUTOSAR Standards

>

Der MICROSAR vDrm sendet Diagnoseanfragen zum eigenen oder zu anderen Steuergeräten und empfängt deren Ant-

wortbotschaften. Für die Anwendung stellt er eine API zum Senden und Empfangen der UDS Services bereit. Der vDrm

ist dabei in der Lage, parallele Verbindungen zu verwalten, andere Steuergeräte im Fahrzeugnetzwerk zu erkennen und

verfügt über eine Firewall zum Blockieren potentiell gefährlicher Diagnoseanfragen. Das Modul verhält sich wie ein ex-

tern angeschlossener Tester und stellt die Basis für die Implementierung von On-Board Testern.

>

Das Modul vDes beinhaltet eine Multi-Controller-Funktionalität für den Dem und ermöglicht dadurch Diagnose-Monito-

ring über mehrere Prozessoren. Der Diagnose-Master sammelt hierbei qualifizierte Diagnose-Events, welche vom Dem

auf dem Diagnose-Slave nach dem Empfang lokaler Botschaften kommuniziert werden.






12.4 Konfiguration und Bedatung

Die BSW-Module aus MICROSAR.DIAG passen Sie komfortabel durch die Konfiguration mit dem DaVinci Configurator Pro an

die Bedürfnisse Ihrer Anwendung an. Wahlweise erfolgt dies entweder mithilfe einer CANdela-, AUTOSAR Diagnostic Extract

oder einer ODX-Datei oder über eine „ECU Configuration Description“.

Für AUTOSAR 3.x erfolgt die Diagnose-spezifische Bedatung des Dcm ausschließlich über eine CANdela-Datei. Sie erstellen

diese schnell und einfach oder importieren sie aus den meisten gängigen ODX-Dialekten mit dem bewährten „Diagnose Auto-

rentool“ CANdelaStudio.

MICROSAR

49

Bild 25: Mit CANdelaStudio bedaten Sie die MICROSAR.DIAG Module.

Bild 26: Die Bedatung von MICROSAR.DIAG erfolgt mit CANdelaStudio und DaVinci Configurator Pro.

12.5 Lieferumfang

Zusätzlich zum Standard-Lieferumfang erhalten Sie einen Konverter für CANdela Diagnostic Descriptions.

12.6 Dienstleistungen für Diagnoseanwendungen:

> Kundenspezifische Erweiterungen von MICORSAR.DIAG

> Erstellung von kundenspezifischen Diagnose-Applikationen

> Integration der Diagnose in Ihre Steuergeräte-Software

12.7 Weitere relevante MICROSAR Produkte für DIAG

Sie kombinieren MICROSAR.DIAG mit folgenden MICROSAR Produkten, um die jeweiligen ISO-Normen zu erfüllen:

> MICROSAR.CAN (ISO 15765-3 oder ISO 14229-3)

> MICROSAR.FR (ISO 14229-4)

MICROSAR

50

> MICROSAR.ETH (ISO 14229-5)

Mit CANdelaStudio bedaten Sie die CANdela- bzw. ODX-Datei zur Konfiguration von MICROSAR.DIAG. Weitere Informationen

hierzu finden Sie in der separaten CANdelaStudio Produktinformation.

Für die Diagnose von Nutzfahrzeugen benötigen Sie die J1939-spezifischen Module aus MICROSAR.CAN.

12.8 Unterstützte Diagnose-Services

Das Modul DCM aus MICROSAR.DIAG unterstützt standardmäßig die folgenden UDS-Diagnose Services:

Diagnostic Service Name

(ISO 14229-1)

Service ID

(hex)

AUTOSAR 4.x:

The SWC has to …

AUTOSAR 3.x:

The SWC has to …

Diagnostic and Communication Management Functional Unit

DiagnosticSessionControl 10 - (handled in DCM internally) … grant service execution

ECUReset 11 - (handled in DCM/BSWM) - (handled in DCM/BSWM)

SecurityAccess 27 … calculate seed/key for each security level … calculate seed/key for each security level

CommunicationControl 28 - (handled in DCM/BSWM) - (handled in DCM/BSWM)

TesterPresent 3E - -

ControlDTCSetting 85 - (handled in DEM module) - (handled in DEM module)

Data Transmission Functional Unit

ReadDataByIdentifier 22 … handle data acquisition for each DataEle-

ment

… handle data acquisition for each DataId

ReadMemoryByAddress 23 via callout via callout

ReadDataByPeriodic Identifier 2A - -

DynamicallyDefineData Identifier 2C - -

WriteDataByIdentifier 2E …handle data access for each DataElement …handle data access for each DataId

WriteMemoryByAddress 3D via callout via callout

Stored Data Transmission Functional Unit

ReadDTCInformation 19 - (handled in DEM module) - (handled in DEM module)

ClearDiagnosticInformation 14 - (handled in DEM module) - (handled in DEM module)

Input/Output Control Functional Unit

InputOutputControlByIdentifier 2F … control I/O for each DataElement … control I/O for each DataId

Remote Activation Of Routine Functional Unit

RoutineControl 31 … start (stop/request result) for each Routin-

eId

… start (stop/request result) for each Routin-

eId

Bild 27: UDS Diagnose Services beim Modul DCM

Das Modul Dcm aus MICROSAR.DIAG unterstützt optional die folgenden OBD-II Diagnose Services:

Diagnostic Service Name

(ISO 15031-5)

Service

ID

(hex)

The SWC has to …

Diagnostic Service Definition for CAN

Request Current Powertrain Diagnostic Data 01 … handle data acquisition for each PID other than the "supported ID"

and DEM ones

Request Powertrain Freeze Frame Data 02 - (handled in DEM module)

Request Emission-Related Diagnostic Trouble Codes 03 - (handled in DEM module)

Clear/Reset Emission-Related Diagnostic Information 04 - (handled in DEM module)

MICROSAR

51

Request On-Board Monitoring Test Results for Specific Moni-

tored Systems 06 … handle data acquisition for each TestId of a MonitorId

Request Emission-Related Diagnostic Trouble Codes Detected

During Current or Last Completed Driving Cycle 07 - (handled in DEM module)

Request Control of On-Board System, Test or Component 08 … process each TestId

Request Vehicle Information 09 … handle data acquisition for each InfoType ID other than the "sup-

ported ID" and DEM ones

Request Emission-Related Diagnostic Trouble Codes with Per-

manent Status 0A - (handled in DEM module)

Bild 28: OBD-II Diagnose Services beim Modul Dcm

MICROSAR

52

13 MICROSAR.MCAL – AUTOSAR-Treiber zur Ansteuerung der Mikrocontroller-Peripherie

Das Paket MICROSAR.MCAL enthält die Treiber zur Steuerung der Peripherie-Einheiten eines Mikrocontrollers. Diese Treiber

sind kompatibel zu den AUTOSAR-Spezifikationen aus dem „Microcontroller Abstraction Layer“. Jeder MICROSAR.MCAL Trei-

ber ist controllerspezifisch umgesetzt.

Bild 29: Die MICROSAR.MCAL Module nach AUTOSAR 4.3

13.1 Die Vorteile von MICROSAR.MCAL im Überblick

> Für AUTOSAR 4.x erhältlich

> Optimale Unterstützung Ihrer Mikrocontroller-Peripherie

> Vereinfachte Konfiguration durch Berücksichtigung von modulübergreifenden Parameterabhängigkeiten im Konfigurati-

onswerkzeug

> Beschleunigte Entwicklung durch Plausibilitäts- und Vollständigkeitsprüfungen im Konfigurator

> Ressourcenschonend durch abschaltbare Funktionalitäten

> Reduzierte Hardware Anforderungen durch optimale Nutzung der Hardware Puffer

> Gateway Entwicklungen werden durch effiziente Zusatzfunktionen unterstützt


Mit MICROSAR.MCAL erhalten Sie eine fertige Lösung für die Ansteuerung Ihrer Prozessorperipherie. Beim Wechsel auf eine

andere Hardware ist daher keine Anpassung der Funktionssoftware erforderlich. Sie müssen lediglich MICROSAR.MCAL aus-

wechseln, um die passenden Treiber einzubinden.

Die MICROSAR.MCAL Treiber arbeiten optimal mit den restlichen MICROSAR Paketen zusammen. Je nach Anforderung Ihrer

Anwendung nutzen Sie weitere Pakete (z.B. MICROSAR.CAN, MICROSAR.MEM, etc.) und erhalten so beispielsweise einen kom-

pletten Kommunikations-Stack oder eine Speicherverwaltung.

MICROSAR

53


Das Paket MICROSAR.MCAL enthält die Treiber-Module CAN, ETH, FR, LIN, und IIC sowie in der Version für AUTOSAR 4.x das

Test-Module RamTst. Die Module entsprechen AUTOSAR 4.x und sind für eine Vielzahl der gängigen Mikrocontroller verfügbar.

>

Der Can-Treiber abstrahiert den Zugriff auf die CAN-Hardware zum Senden und Empfangen von Botschaften und zur

Umschaltung der Controller-Zustände (Sleep, Stop etc.).


> Benachrichtigung (Callback) beim Botschaftsempfang und nach erfolgreichem Versenden einer Botschaft. Damit ist

es möglich, automatisch anwenderspezifischen Code aufzurufen.

Add-Ons

> Die Option „CAN Driver High End Feature“ bietet erweiterte Filtermöglichkeiten für Multiple Basic CAN-Objekte, Emp-

fangsqueue zur Verkürzung der Interrupt Laufzeit während des Empfangs, Individual Polling von Mailboxen zum Si-

cherstellen der Datenkonsistenz sowie Reduzierung der Interrupt Last.

> Erhöhen der Full CAN Objekte durch Kombination von mehreren CAN-Controllern auf einem physikalischen CAN-Bus

(Common CAN)

>

Das SocketCAN API ist ein HW unabhängiges API zur Ansteuerung von CAN Communication unter Linux. Das Modul Can

(SocketCAN) nutzt ein vorhandenes SocketCAN API um darüber die CAN Kommunikation zu realisieren und erlaubt so

den Betrieb eines MICROSAR Communication Stack unter Linux.

>

Der Eth-Treiber abstrahiert den Zugriff auf die Ethernet-Hardware zum Senden und Empfangen von Daten und zur Um-

schaltung der Controller-Zustände.

>

Das Modul EthSwt bietet eine einheitliche und Hardware-unabhängige Schnittstelle zur Ansteuerung und Konfiguration

von Ethernet-Switches. Es koordiniert auch die MAC-Lernphase bei mehrfacher Verwendung von baugleichen Steuerge-

räten wie z.B. Kameras für den Surround-View.

>

Der Fr-Treiber abstrahiert den Zugriff auf die FlexRay-Hardware zum Senden und Empfangen von Daten und zur Um-

schaltung der Controller-Zustände.


> Unterstützung der Self Diagnostic. Wenn der FlexRay-Controller einen Fehler erkennt, benachrichtigt er die Anwen-

dung, damit diese den Fehlerstatus abrufen kann.

> Optimiertes Wakeup During Operation (WUDOP)

> Unterstützung der folgenden APIs: CancelTransmit und L-PDU-Rekonfiguration


>

Der Lin-Treiber stellt Dienste bereit, um die Frame-Übertragung (Header, Response, Sleep-Mode und Wake-up) anzusto-

ßen, sowie für den Empfang von Antworten, die Überprüfung des momentanen Zustandes und die Validierung von

Wake-up-Ereignissen.

>

Das Modul RamTst testet Mikrocontroller interne RAM Zellen. Ein kompletter Test wird während des Hoch- und Herun-

terfahrens des Steuergeräts durchgeführt oder durch ein Diagnosekommando ausgelöst. Während des Normalbetriebs

erfolgt ein zyklischer Test (Block für Block oder Zelle für Zelle).

>

MICROSAR

54

Hardware-basierte Abstraktion für 3rd Party Crypto Treiber Crypto.Vector Module als Erweiterung zum AUTOSAR

Standard

13.3.1 Vector Module als Erweiterung zum AUTOSAR Standard

>

Der vI2c-Treiber stellt Dienste zur Kommunikation mit externen I2C-Bausteinen bereit.

Erweiterung des AUTOSAR Standard

> >Der vI2c enthält Treiber für die Anbindung von externen Peripherie-Bausteinen über den Inter-Integrated Circuit-Bus

(I2C)





13.4 Konfiguration


Produktinformation.

Bild 30: Konfiguration mit dem DaVinci Configurator Pro

13.5 MICROSAR MCAL Integration Package

Das MICROSAR MCAL Integration Package umfasst mehrere Arbeitspakete, durch die eine möglichst reibungslose Integration

eines 3rd Party MCALs in die Vector Embedded- und Werkzeugumgebung erreicht wird. Hierbei nehmen wir in Abstimmung

mit Ihnen und dem Halbleiterhersteller den beigestellten MCAL des Halbleiterherstellers zusammen mit der Vector

MICROSAR

55

Basissoftware in Betrieb. Wir überprüfen ihn auf Konformität bzw. Integrierbarkeit und erreichen so, dass die 3rd Party Soft-

ware optimal mit den Vector Softwareprodukten zusammenspielt.

Bild 31: Ablaufschema des MCAL Integration Package

Die gewünschte MCAL-Version erfragen wir in einem projekt- und lieferungsspezifischen Fragebogen, in dem vom Kunden vor

der Auslieferung alle noch erforderlichen Angaben gemacht werden. Zur Integration und Auslieferung des MCAL ist es zwin-

gend erforderlich, dass der MCAL mit ausreichendem Vorlauf zur geplanten Lieferung für Vector zur Verfügung gestellt wird.

Details hierzu finden Sie in der Produktinformation, die Ihrem Angebot beigelegt ist.

Selbstverständlich können Sie in diesem Falle auch die Integrationsleistungen des MCAL Integration Packages erneut bei uns

anfragen.

Ein MICROSAR MCAL Integration Package erleichtert die Inbetriebnahme der Basissoftware erheblich, so dass Sie sich voll auf

Ihre Entwicklungsaufgaben fokussieren können.

Im Umfang der Dienstleitungen des MCAL Integration Package sind folgende Schritte enthalten:

Bild 32: Leistungsprofil des MCAL Integration Package

13.5.1 Abstimmung und Koordination mit dem Kunden

> Beratung bezüglich der Terminschiene des MCAL-Herstellers

MICROSAR

56

> Überprüfung der Rahmenbedingungen wie Compilerversion, AUTOSAR-Version, etc.

> Frühzeitige Klärung technischer Probleme, beispielsweise im Falle von Inkompatibilitäten

> Übernahme der Rolle als Ansprechpartner im Zusammenspiel BSW und MCAL

13.5.2 Embedded-Integration

> Eingangstest und Nachweis der Integrierbarkeit: Inbetriebnahme des MCAL auf einem geeigneten Evaluation Board und

Ausführung eines Integrationstests mit der MICROSAR Basissoftware.

> Compile- / Link-Test in Bezug auf die höheren Software-Schichten

> Test der BSW-relevanten Basisfunktionalitäten des MCAL (z.B. CAN-Kommunikation, NV-Datenspeicherung, etc.)

> Bedienung/Erstellung der Embedded-Schnittstellen zwischen BSW und MCAL (MemMap, Compiler Config, Make-Files)

> Bei "mixed AUTOSAR"-Projekten: Entwicklung von Wrappern. (Diese Dienstleistung ist möglich für BSW nach AR 3.x und

MCAL bis einschließlich AR 4.0.3.)

13.5.3 Tool-Integration

In Abhängigkeit von den Eigenschaften des gewählten MCALs gibt es unterschiedliche Möglichkeiten der Integration in die

Vector-Werkzeugkette. Wir streben hierbei die jeweils beste und komfortabelste Lösung für den Kunden an. Grundvorausset-

zungen für das Einbinden der MCAL-Komponenten in die BSW-Konfiguration sind dabei

> das Vorhandensein von AUTOSAR-konformen Beschreibungsdateien sowie

> die Fähigkeit der MCAL-Validatoren / -Generatoren, auf AUTOSAR-konformen Konfigurationsdateien zu arbeiten.

Wird dies vom MCAL unterstützt, so erfolgt eine Einbindung in das Konfigurationswerkzeug DaVinci Configurator Pro, wodurch

nachfolgend auch die Modul-Generierung ermöglicht wird.

Kommen proprietäre Formate zum Einsatz, oder beinhaltet das MCAL-Konfigurationstool besonders aufwendige Abstrahie-

rungen zur erleichterten Konfigurationserstellung und -validierung, so bietet Vector geeignete Mittel, die den parallelen Einsatz

von unterschiedlichen Konfigurationsdateien und Konfigurationstools erleichtern.

MICROSAR

57

14 MICROSAR.EXT – AUTOSAR-Treiber zur Ansteuerung von externen Bausteinen

MICROSAR.EXT beinhaltet die kommunikationsbezogenen AUTOSAR-Transceiver-Treiber für CAN (CanTrcv), FlexRay

(FrTrcv), LIN (LinTrcv), Ethernet (EthTrcv) sowie die Treiber (Ext) für weitere externe Bausteine wie z.B. EEPROM-, Flash-

Speicher und Watchdog. Die in den Treibern enthaltenen Funktionen hat AUTOSAR im „ECU Abstraction Layer“ spezifiziert.

Sie entsprechen AUTOSAR 4.x, sind für den jeweiligen Baustein optimiert und stehen für eine Vielzahl gängiger Bausteine zur

Verfügung.

Bild 33: Die MICROSAR.EXT Module nach AUTOSAR 4.3

14.1 Die Vorteile von MICROSAR.EXT im Überblick

> Optimale Ansteuerung Ihrer externen Transceiver- und Speicher-Bausteine


> Unterstützung von Transceivern für den Teilnetzbetrieb

> Zusätzliche Unterstützung von LIN- und Ethernet-Transceivern

> Vereinfachte Konfiguration durch Berücksichtigung von Parameterabhängigkeiten mit anderen Modulen

> Beschleunigte Entwicklung durch Plausibilitäts- und Vollständigkeitsprüfungen im Konfigurator


Mit MICROSAR.EXT erhalten sie eine fertige Lösung für die Ansteuerung Ihrer externen Peripheriebausteine. Beim Wechsel

eines externen Bausteins auf eine andere Hardware ist daher keine Anpassung der Funktionssoftware erforderlich. Sie müssen

lediglich die betroffenen Treiber aus MICROSAR.EXT auswechseln.

Je nach Anforderung Ihrer Anwendung fügen Sie weitere Pakete (z.B. MICROSAR.CAN, MICROSAR.MEM, etc.) hinzu und er-

halten einen kompletten Kommunikations-Stack oder eine Speicherverwaltung nach AUTOSAR-Spezifikation.

Für den Teilnetzbetrieb in CAN-Netzwerken benötigen Sie spezielle Transceiver. Für viele dieser Transceiver ist bereits ein pas-

sender Treiber (CanTrcv) in MICROSAR.EXT erhältlich.

MICROSAR

58


>

Dieser Treiber ist zuständig für die Steuerung der Betriebszustände eines externen CAN-Transceivers. Dies beinhaltet die

Kontrolle der Aufwach- und Schlaf-Funktionen.

>

Der EthTrcv bietet eine einheitliche und Hardware-unabhängige Schnittstelle zur Ansteuerung mehrerer gleicher

Transceiver. Die Konfiguration des EthTrcv ist Transceiver-spezifisch und berücksichtigt die Eigenschaften des verwende-

ten physischen Netzwerks.


> Ethernet–Transceiver Treiber, auch für Powerline Communication (PLC) und Wireless LAN (WLAN) (AUTOSAR 4.x und

3.x)

>

Der FrTrcv-Treiber für einen externen FlexRay-Transceiver ist zuständig für das Ein- und Ausschalten des Transceivers.

>

Das LinTrcv-Modul für einen externen LIN-Transceiver ist zuständig für die Überwachung und Ansteuerung der Aufwach-

und Schlaf-Funktionen.


> LIN-Transceiver Treiber (auch für AUTOSAR 3.x)

>

Auf Anfrage erhalten sie von Vector die Implementierungen von Treibern für extern angeschlossene Bausteine.

> Adc (EXT)

> Eep (EXT)

> Fls (EXT)

> EthSwt (EXT)

> Eth (EXT)

> Wdg (EXT)

14.3.1 Vector Module als Erweiterung des AUTOSAR Standard

>

Das vSbc Modul abstrahiert den Zugriff auf einen extern angeschlossenen System Basis Chip (SBC). Die Implementie-

rung bietet eine hardwareunabhängige Schnittstelle, die von den oberen Schichten zur Steuerung der SBC-Hardware

verwendet werden kann. Abhängig von der SBC-Peripherie, enthält vSbc AUTOSAR-kompatible Module der oberen

Schicht (z.B. CanTrcv, LinTrcv und Wdg), die dem BSW-Stack den Zugriff auf die entsprechende SBC-Funktionalität

ermöglichen. Weitere SBC-Funktionalitäten können über einen Complex Driver oder eine IO Hardware Abstraktion mit-

tels der RAW-API angesprochen werden, die von der vSbc-Implementierung bereitgestellt wird. Das RAW-API ermöglicht

einfachen (Lese-/Schreib-) Zugriff auf die SBC-Register. vSbc benötigt einen geeigneten MCAL-Treiber (z.B. Spi) um die

Verbindung zum SBC herzustellen.

MICROSAR

59

Bild 34: Der System Basis Chip ist über eine serielle Busschnittstelle (z.B. SPI, I²C) mit dem Mikrocontroller verbunden

14.4 Konfiguration


Produktinformation.

Bild 35: Konfiguration von MICROSAR.EXT mit DaVinci Configurator Pro


Die externen Bausteine werden physikalisch über SPI, DIO oder einen Port angesteuert. Dazu benötigen Sie den entsprechen-

den Treiber (Spi, Dio oder Port) aus MICROSAR.MCAL.


Vector bietet Ihnen an, die Konfiguration für Ihre eigenen Treiber oder für Treiber von Drittherstellern, wie z.B. Halbleiter-

Herstellern, in den DaVinci Configurator Pro zu integrieren. Dies ermöglicht Ihnen, die gesamte Steuergeräte-Software nahtlos

und schnell mit einem einzigen Werkzeug zu konfigurieren.

MICROSAR

60

15 MICROSAR.IO – AUTOSAR Input Output Hardware Abstraktion

Das Cluster IO stellt eine Verbindung zwischen Anwendung (zum Beispiel SWCs) und MCAL-Modulen her. Die Anwendung

erhält Zugriff auf I/O-Ports um zum Beispiel Sensoren auszulesen oder Aktuatoren an zu steuern

Das IO-Cluster enthält für diese Aufgabe spezialisierte BSW-Module. Zusätzlich bietet Vector die Möglichkeit mit Hilfe des

DaVinci Developers eine für das Steuergerät passgenaue IoHwAb zu erstellen.

Bild 36: Das MICROSAR.IO Cluster

15.1 Die Vorteile von MICROSAR.IO im Überblick

> Schnelle Implementierung von anwenderspezifischem Code für die Erfassung und Bereitstellung von Sensor und Aktua-

tor Signalen

> Generierung von Code-Beispielen: Es sind Read/Write Digital Signal Templates auswählbar, deren C-Code durch den

Anwender erweitert werden kann.

> Bereitstellung von SWC-Beschreibungen mit allen notwendigen Interface Definitionen

15.2 Vector Module als Erweiterung des AUTOSAR Standard

>

Die Digital Input Output Hardware Abstraction (vDioHwAb) stellt eine Verbindung zwischen Anwendung und DIO-Signa-

len aus dem MCAL her. Dafür erzeugt das Modul vDioHwAb in MICROSAR eine SWC-Schnittstelle sowie DIO-spezifische

Code Templates. Es bietet eine schnelle und unkomplizierte Umsetzung von Zugriffen auf das DIO-Modul. Somit deckt

das vDioHwAb-Modul einen Teil der IoHwAb ab und kann um weitere IoHwAb-Module erweitert werden, welche zum Bei-

spiel Zugang zu ADC- oder ICU-Kanälen bieten.

15.3 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Details hierzu erfahren Sie in der sepa-

raten Produktinformation.

MICROSAR

61

15.3.1 vDioHwAb

DaVinci Configurator Pro überprüft die Plausibilität der Konfigurationsparameter für MICROSAR.MCAL und MICROSAR.IO.

Empfehlenswert ist die folgende „Bottom up“-Vorgehensweise:

> Konfiguration des MCAL-Treibers

> Konfiguration von MICROSAR.IO

> Generierung der zu MICROSAR.IO gehörenden SWC-Description

Bei der Konfiguration der vDioHwAb von MICROSAR.IO definieren Sie jedes einzelne Signal. Hierbei können beliebig viele Port

Prototypes von einem Port Interface abgeleitet werden. Die Zuordnung von PortPrototypes zu Runnable Entities ist für Sen-

der/Receiver-Interfaces 1:n möglich. Runnable Entities in der RTE und Schedulable Entities im SchM sind beliebig konfigurier-

bar. Für den Zugriff der Funktionssoftware über die RTE auf die I/O-Signale stellt MICROSAR.IO alle notwendigen Client/Ser-

ver Interfaces sowie Code-Templates zur Verfügung. Diese ermöglichen dem Anwender das Aufbereiten und Filtern der Sig-

nale.

15.3.2 IoHwAb

Unter Verwendung des DaVinci Developers kann eine IoHwAb SWC-Beschreibung mit wenig Aufwand erstellt werden und in

das SWC-Design eingebunden werden. Die MICROSAR.RTE oder die DaVinci Developer Option.CPG bieten darüber hinaus die

Möglichkeit aus der so erstellten IoHwAb SWC-Beschreibung direkt ein Code Template für Ihre individuelle IoHwAb Implemen-

tierung zu erstellen. Das SWC Code Template wird durch den Anwendungsentwickler um Steuergeräte spezifische Algorithmen

(Entprellung , Signalfilter, etc.) erweitert und mit den MCAL-APIs verbunden.


Erfolgt der Zugriff auf I/O-Signale über einen externen Baustein, so benötigt Ihr I/O-Stack zusätzlich einen entsprechenden

Treiber aus MICROSAR.EXT.


Bei der Entwicklung eines vollständigen und ECU-spezifischen IoHwAb-Layers für Ihr Steuergerät unterstützt Vector Sie gerne

im Rahmen von Projektarbeit. Dabei profitieren Sie von der detaillierten Kenntnis der AUTOSAR-Spezifikation und -Methodik

sowie der umfangreichen Erfahrungen in der Integration von Steuergerätesoftware.

MICROSAR

62

16 MICROSAR.RTE – Die optimierte Ablaufumgebung für Softwarekomponenten nach dem AUTOSAR-Standard

Die MICROSAR.RTE (Runtime Environment) ist die skalierbare und hoch optimierte Laufzeitumgebung von Vector. Die Rte ist

ein von AUTOSAR eingeführtes Modul und verwaltet die Kommunikation zwischen den Softwarekomponenten (SWCs). Sie

stellt dabei die Konsistenz des gesamten Informationsflusses sicher und bildet die Schnittstelle zwischen Funktionssoftware,

Basissoftware (BSW) sowie Complex Drivern (Cdd).

Bild 37: Das MICROSAR.RTE Modul nach AUTOSAR 4.3

16.1 Die Vorteile von MICROSAR.RTE im Überblick

> Leicht konfigurierbar und skalierbar


> Tiefgehende Konsistenzprüfung der Konfiguration

> Hoch optimierter Code mit intelligenten Synchronisationsmechanismen

> Schneller Einstieg in AUTOSAR durch z.B. generiert Code Templates für die Softwarekomponenten (SWCs)

> Für Migrationsprojekte geeignet

> Vereinfachter Test der Applikation durch XCP-Zugriff auf Ports, InterRunnable-Variablen und Per-Instance Memory


Wenn die Funktionssoftware eines Steuergeräts über AUTOSAR-konforme SWCs implementiert ist, benötigt der Anwender

die Rte als Laufzeitumgebung. Dieser modulare Aufbau der Steuergerätesoftware bietet dem Anwender maximale Flexibilität:

Eine manuell entwickelte oder durch modellbasierte Werkzeuge entworfene SWCs kann in mehreren Steuergeräte-Projekten

verwendet werden. Hierzu ist lediglich für das konkrete Steuergerät das Umkonfigurieren und die neue Generierung der Rte

sowie ggf. der BSW-Module erforderlich. Darüber hinaus ist auch die Mehrfachverwendung einer SWC auf einem Steuergerät

möglich.

Beim Generieren der MICROSAR.RTE kann der Anwender zwischen zwei Modi wählen:

MICROSAR

63

> Contract Phase Generierung für die Entwicklung einzelner SWCs in einer frühen Phase. Hierbei erstellt der Generator

anstelle der gesamten Rte nur eine Header-Datei für jede SWC. Damit ist es möglich die SWC einzeln zu kompilieren um

sie z. B. als Objektcode an den Entwicklungspartner weiterzugeben.

> RTE-Generierung für die gesamte Steuergerätesoftware. Der in diesem Modus generierte Code ist hoch effizient und

benötigt wenig Speicherplatz. Er ist optimiert für die gesamte Steuergerätekonfiguration und benötigt nur eine geringe

Laufzeit und minimale Interrupt-Sperrzeiten. Dies wird z.B. erreicht durch intelligente Synchronisationsmechanismen, die

auf die Eigenschaften der verwendeten Hardware abgestimmt sind.


>

MICROSAR.RTE ist kompatibel zu AUTOSAR 4.x und 3.x. Im Detail enthält MICROSAR.RTE die folgende Funktionalität:

> Sender/Receiver und Client/Server Kommunikation

> Mode Management

> InterRunnable-Variablen sowie Exclusive Areas

> Zugriff auf Nv Block Software Components über Sender/Receiver-Ports

> Trigger für Runnables

> Unterstützung der Online-/Offline-Kalibrierung von SWCs sowie Messen von S/R-Ports, InterRunnable-Variablen und

Per-Instance Memory mittels Xcp

> Mehrfach-Instanziierung von SWCs und Per-Instance Memory

> Schedule Manager/BSW Scheduler (SchM): Seit AUTOSAR 4.0 übernimmt die Rte die Funktionalität des SchM-Moduls.

Dieses war vorher in MICROSAR.SYS enthalten. Mehr Information über das SchM-Modul finden Sie im Kapitel

„MICROSAR.SYS“.

> Unterstützung der Transformer-Schnittstellen für ComXf, SomeIpXf und E2eXf. Details hierzu erhalten Sie im Kapitel

MICROSAR.COM.

> Externe Client/Server Kommunikation (Inter-ECU) über den optional erhältlichen Transformer SomeIpXf.


> Generieren von Code-Templates für die SWCs auf Basis der „SWC Description“. Diese Templates enthalten alle APIs

der Rte.

> Verwenden von Speicherschutzmechanismen, wie im AUTOSAR-Betriebssystem spezifiziert. Besonders optimiert ist

diese Unterstützung beim Einsatz von MICROSAR.OS.

> Konfiguration von Initialisierungs-Runnables für das AUTOSAR-Konzept der „Mode-abhängigen Runnables“

> Erzeugen eines HTML-Reports mit den Eigenschaften der Rte. Darin sind Informationen wie z.B. der berechnete Rte

Ressourcenbedarf (RAM + Konstanten) enthalten.

> Generieren einer A2L-Datei zur einfachen Anbindung an bestehende Kalibrier- und Diagnose-Standards.

Add-Ons

> MPU-Unterstützung für den Speicherschutz

> Multi-Core-Unterstützung

> Post-build selectable: Dieses Feature ist innerhalb der MICROSAR-Produktfamilie im Modul "Identity Manager" gelöst.

Details hierzu finden sie im Kapitel "MICROSAR Variantenhandling".

>

Die Basic Runtime Environment (Bre) erlaubt die Integration einer nicht-AUTOSAR-basierten Anwendung mit der

MICROSAR Basissoftware. Bei Verwendung der BRE ist ein formelles Design der SWCs nach AUTOSAR-Definition nicht

erforderlich, da die Bre die Nutzung der existierenden Anwendungs-Architektur ermöglicht. Sie ist dadurch das ideale

Instrument, um ein bestehendes Steuergeräte-Projekt in eine AUTOSAR-Architektur zu migrieren.

MICROSAR

64

Bei Verwendung der Bre greift die Applikation direkt auf die Funktionen der Basissoftware zu, ohne dass hierzu AUTO-

SAR-konforme SWCs definiert werden müssen. In diesem Anwendungsfall wird die Rte als Bindeglied zwischen SWCs

und BSW nicht verwendet, sondern durch Anwendungs-Code ersetzt.

Um die Integration der Anwendung mit der MICROSAR Basissoftware zu erleichtern, stellt die Bre Basisfunktionalitäten

zur Verfügung, die normalerweise von der AUTOSAR-RTE übernommen werden:

> Generierung der Typdefinition für BSW-Module der Service Schicht

> Aufrufen der BSW Main Functions basierend auf einem konfigurierbaren Task Mapping

> Generierung der Exclusive Areas für die BSW-Module

Da die BSW AUTOSAR-konforme Schnittstellen besitzt, setzt die Verwendung der Bre voraus, dass die Applikation die

Schnittstellenfunktionen der Rte zur BSW selbst übernimmt.

Grundsätzlich ist MICROSAR.RTE die umfassende Lösung für ein Steuergeräte-Projekt im AUTOSAR-Umfeld. Unsere

erfahrenen Coaches unterstützen Sie gerne, wenn Sie Ihre Anwendung und BSW-Architektur auf den AUTOSAR-Stan-

dard anheben möchten.

>

Der Schedule Manager/BSW Scheduler koordiniert die Ausführung der BSW-Module. Bei der Konfiguration definieren Sie

Tasks und Zyklus-Zeiten der BSW-Module. Auch die Einstellung der Exclusive Areas legen Sie zentral für jedes Modul fest.

Für AUTOSAR 3.x ist SchM Bestandteil von MICROSAR.SYS. In AUTOSAR 4.x übernimmt die MICROSAR.RTE die Funkti-

onalität des SchM.

16.4 Konfiguration

Für die Konfiguration der Rte benötigen Sie entweder den DaVinci Configurator Pro mit der Option .RTE oder den DaVinci

Developer. Mehr Details finden Sie in den separaten Produktinformationen.

16.5 Lieferumfang

Zusätzlich zum Standard-Lieferumfang erhalten Sie auch Beispielprogramme mit Makefiles.


MICROSAR.RTE setzt ein Betriebssystem wie z.B. MICROSAR.OS oder osCAN voraus.

MICROSAR

65

17 MICROSAR AMD – AUTOSAR-Monitoring und -Debugging

MICROSAR AMD enthält viele nützliche Funktionen, die das Entwickeln und Testen von Steuergeräten erheblich vereinfachen.

Kernfunktionen von AMD sind das Reporting von Fehlern und Events aus der Applikation und der MICROSAR-BSW sowie das

Bereitstellen der aktuellen CPU-Last und der Software-Laufzeiten.

Bild 38: Die MICROSAR AMD Module nach AUTOSAR 4.3

17.1 Die Vorteile von MICROSAR AMD im Überblick

> Vereinfachtes Testen von Steuergeräten durch Erfassen von Steuergeräte-internen Daten

> Einfaches Messen des Start- und Einschlafverhaltens

> Ermittlung von CPU-Last und Laufzeiten der Applikation und der Basissoftware

> Reporting von BSW-Fehlerzuständen und Programmfluss-Trace-Nachrichten

> Verwendung des vom ASAM standardisierten und weit verbreiteten XCP-Protokolls


Das Paket MICROSAR AMD unterstützt Sie effizient beim Testen Ihrer AUTOSAR-Steuergerätesoftware. Die Basis-Software-

Module aus MICROSAR AMD haben Zugriff zu allen wichtigen internen Variablen, Zuständen und Fehlermeldungen Ihrer

MICROSAR-Basissoftware.

Weil sich das aus dem Mess- und Kalibrierumfeld bekannte XCP-Protokoll (Universal Calibration Protocol) hervorragend zum

Übertragen Steuergeräte-interner Größen eignet, hat Vector MICROSAR AMD auf Basis von XCP entwickelt.

MICROSAR

66

Bild 39: MICROSAR AMD ermöglicht im Zusammenspiel mit CANoe.AMD einen einfachen Zugriff auf Steuergeräte-interne Informationen

17.3 Funktionen

Die Funktionalität der Module Dbg (Debugging) und Dlt (Diagnostic Log and Trace) ist in AUTOSAR 4.x spezifiziert Zusätzlich

zum AUTOSAR-Standard bietet MICROSAR AMD die Möglichkeit, CPU-Last und beliebige Laufzeiten zu ermitteln.

Zur Anzeige und Analyse werden die mit MICROSAR AMD ausgelesenen Werte an einen XCP-Master übertragen. Als XCP-

Master können Sie auf der PC-Seite z.B. die folgenden Vector Werkzeuge einsetzen:

> CANape – zusammen mit den MICROSAR Modulen Dlt und Dbg

> CANoe.AMD ab Version 8.1 – zusammen mit den MICROSAR Modulen Dlt, Dbg und vRtm.

Mit diesen Werkzeugen und einer Beschreibung der Mess-Objekte in Form einer ASAM A2L-Datei wählen Sie die Steuergeräte-

internen Daten aus und analysieren deren Abläufe. Speziell für AMD wurde CANape um das „Digital Fenster“ mit der „Status“-

Signaldarstellung und CANoe mit dem speziellen „State Tracker“ Fenster erweitert. Damit stellen Sie diskrete Zustände und

binäre Signale in einem Fenster übersichtlich dar.

Bild 40: Auswerten von Statusänderungen mit dem State Tracker Fenster in CANoe.AMD

17.3.1 Erfassen von internen Variablen aus den AUTOSAR BSW-Modulen

Mit dem BSW-Modul Dbg aus MICROSAR AMD überprüfen Sie bei Steuergerätetests, welche externen und internen Einflüsse

einen Zustandswechsel der BSW-Module verursacht haben. Die dazu benötigten internen Variablen der MICROSAR BSW-Mo-

dule sendet das Dbg-Modul mittels Xcp an den Master.

17.3.2 Erfassen von internen Variablen aus der MICROSAR.RTE

Beim Einsatz einer MICROSAR.RTE als Laufzeitumgebung in Ihrer Steuergerätesoftware kann der Datenfluss zwischen SWCs

mit Xcp überwacht werden. Nach der Aktivierung der Option „Measurement Support“ bei der Rte-Konfiguration werden die

folgenden Rte-interne Objekte erfasst:

MICROSAR

67

> Inter-Runnable Variablen

> Sender/Receiver Ports

> Mode Ports

> Per-Instance Memory

Damit überwachen Sie die Intra- und Inter-ECU Kommunikation sowie messen oder stimulieren nicht verbundenen Sender/Re-

ceiver Ports.

17.3.3 Erfassen von Zuständen und Fehlermeldungen der Applikation

Das BSW-Modul Dlt erfasst und überträgt mittels Xcp während der Laufzeit alle auftretenden Fehlermeldungen und Warnun-

gen, die von der BSW an das Modul Det gemeldet werden. Zusätzlich ist das Dlt-Modul in der Lage, Benachrichtigungen an den

Fehlerspeicher (Dem) aktiv an den XCP-Master weiterzuleiten.

Um den Programmfluss und Zustand der Anwendung zu überwachen, bietet das Dlt-Modul das Reporting von beliebigen Trace

Botschaften als Freitext an. Dazu wird ein „WriteLine“-ähnliches API bereitgestellt, das zur Laufzeit einen beliebigen Text über-

mitteln kann. Alternativ können auch vordefinierte Textblöcke laufzeitoptimiert übertragen werden.

17.3.4 Ermitteln von CPU-Last und Laufzeit

Mit MICROSAR AMD und CANoe.AMD erfassen Sie die Laufzeit frei wählbarer Code-Abschnitte aus der Anwendungssoftware

oder den BSW-Modulen. Die Ergebnisse der Messungen werden in HTML- und CSV-Reports angezeigt, die mit dem CANoe

Test Feature Set erzeugt werden.

17.3.5 Erzeugen der A2L-Datei für den XCP-Master

Sie erzeugen die A2L-Beschreibungsdatei für den XCP-Master mit den DaVinci Werkzeugen auf Basis der Konfigurationsdaten

aus der Steuergerätekonfigurationsdatei (ECUC). Falls symbolische Namen für Werte der messbaren Objekte existieren, sind

diese für die spätere Visualisierung ebenfalls hinterlegt. Es ist auch möglich, weitere Applikations-spezifische A2L-Fragmente

in die Master A2L-Datei mit aufzunehmen. Vor der Messung aktualisieren Sie mit dem ASAP2 Updater die A2L-Datei mit den

tatsächlichen Adressen der Variablen. Der ASAP2-Updater ist im Lieferumfang von CANape und CANoe.AMD enthalten.

Bild 41: Erzeugen einer A2L-Datei für den XCP-Master

17.4 Konfiguration


Produktinformation.

MICROSAR

68

17.5 Lieferumfang

MICROSAR AMD besteht aus folgenden Komponenten

> Softwaremodule als Source-Code

> A2L-Generator (für Windows XP/Windows 7)

> BSW-Module Description-Dateien

> Dokumentation

17.6 Weitere relevante Produkte

Voraussetzung für den Einsatz von MICROSAR AMD ist entweder

> der gleichzeitige Einsatz von MICROSAR XCP für CAN, FlexRay oder Ethernet oder

> das VX1000 System von Vector. Dieses empfiehlt sich für höchsten Datendurchsatz bei minimaler Laufzeit-Beeinflus-

sung. Details dazu erhalten Sie auf der Produkt-Webseite www.vector.de/vx . In vielen Fällen dürfen in Serienprojekten

aus Sicherheitsgründen die Mess- und Kalibrierschnittstellen nicht mehr verwendet werden. Das Modul VX1000If ermög-

licht es, den Vector VX1000 Mess- und Kalibrier-Hardware Treiber in einem deaktivierten Zustand in der BSW auch im

Rahmen von Serienprojekten zu belassen. Über ein API kann die VX1000 Treiber Funktion für Prüf und Entwicklungszwe-

cke wieder freigegeben werden. Die Lieferung muss im Rahmen eines MICROSAR SIPs erfolgen um eine Freigabe für die

Nutzung dieser Vorgehensweise im Serieneinsatz zu erhalten. Eine Aktivierung des VX1000 Treibers im Serieneinsatz zur

Laufzeit ist jedoch auch bei Verwendung des Moduls VX1000If nicht gestattet.

http://www.vector.de/vx

MICROSAR

69

18 MICROSAR Lösungen

Jetzt folgen die Beschreibungen der bereits eingangs vorstellten Lösungen. Diese Lösungen sind paketübergreifend und können

die unterschiedlichsten Module aus ganz verschiedenen Pakete beinhalten. Zu den Lösungen gehören: MICROSAR Safe, MI-

CROSAR Security, MICROSAR Multicore, MICROSAR Variant Handling, MICROSAR Posix, MICROSAR Gateway, MICROSAR

J1939, MICROSAR vVIRTUALtarget.

MICROSAR

70

19 MICROSAR Safe – Sicherheit nach ISO 26262 bis ASIL D für Steuergeräte-Software

Die Sicherheitsnorm ISO 26262 definiert, nach welchen Kriterien das Entwickeln von sicherheitsrelevanten Steuergeräten im

Automobilbereich erfolgen soll. Mit MICROSAR Safe erhalten Sie von Vector eine Lösung, um sicherheitsrelevante Funktiona-

lität bis zur höchsten Sicherheitsebene (ASIL D) in einem AUTOSAR-Projekt umzusetzen.

Eine nach ISO 26262 entwickelte Basissoftware kann helfen, die Anzahl der Partitionen im System zu reduzieren und damit die

Laufzeit zu verbessern. Viele unserer MICROSAR Basissoftware-Module sind mit den Methoden der ISO 26262 / ASIL D entwi-

ckelt und können mit sicherheitsrelevanten SWCs auch ohne eine Partitionierung koexistieren. Darüber hinaus können bei Be-

darf auch weitere Sicherheitsanforderungen in der Basissoftware abgebildet werden.

Bild 42: Die MICROSAR Safe Module nach AUTOSAR 4.3. Neben den oben dargestellten Modulen sind weitere Module als ASIL-Software erhältlich, z.B.

OSEK NM und Hersteller-spezifische Software-Komponenten.

19.1 Die Vorteile von MICROSAR Safe im Überblick

> Zertifizierte Lösung für alle Automotive Safety Integrity Level (ASIL A bis ASIL D)

> Ausführung von ASIL- und QM-Softwareteilen auf einem einzelnen Mikrocontroller (Mixed-ASIL)

> Reduzieren von Qualifizierungskosten

> Laufzeitoptimierte Umsetzung der Kontextverwaltung

> Überwachung von Kontrollfluss und Deadlines

> Absicherung der externen Kommunikation

> Weniger Partitionswechsel und damit geringere Laufzeit durch sichere Basissoftware

> Geeignet für Multi-core Projekte

MICROSAR

71


Die Module aus MICROSAR Safe sind "Safety Elements out of Context" (SEooCs), die nach ISO 26262 / ASIL D entwickelt

sind.

MICROSAR Safe ermöglicht den rückwirkungsfreien Ablauf von sicheren Softwareteilen mit unterschiedlichem ASIL und nicht-

sicheren Softwareteilen (QM-Software) auf dem gleichen Steuergerät (Mixed-ASIL-Systeme). MICROSAR Safe ist das Ergeb-

nis langjähriger Erfahrung im Umfeld der funktionalen Sicherheit.

19.3 Funktionen

MICROSAR Safe beinhaltet für Projekte nach dem AUTOSAR 4 Standard die SafeBSW mit ihren Hauptbausteinen SafeOs,

SafeE2E und SafeWdg . Sie entsprechen der AUTOSAR-Spezifikation und sind kompatibel zu allen anderen MICROSAR BSW-

Modulen, die optional ebenfalls im Kontext der SafeBSW bereitgestellt werden können. Darüber hinaus stellt MICROSAR Safe

auch die SafeRte zur Verfügung.

Für Mixed-ASIL-Systeme (Steuergeräte, die sowohl ASIL-Funktionen als auch Funktionen ohne Sicherheitsanforderungen ent-

halten) ist als kleinste mögliche Ausbaustufe ein Umfang notwendig, der die Bausteine SafeOs, SafeWdg und SafeE2e um-

fasst. Eine Erweiterung dieses Mindestumfangs erfolgt dann passgenau zu Ihren Anforderungen, bis hin zum kompletten Ba-

sissoftware Stack nach ASIL D.

Bild 43: MICROSAR Safe mit SafeRTE und SafeBSW in AUTOSAR 4.2

Die Hauptbausteine im Konzept von MICROSAR Safe enthalten die nachfolgend genannten Funktionen:

19.3.1 SafeOS- das sichere AUTOSAR Betriebssystem

Den Speicherschutz für Steuergeräte mit sicherheitsrelevanten Anwendungen sichert die Option SafeOs des MICROSAR Be-

triebssystems. Dabei schottet MICROSAR.OS (SC3/SC4) auf geeigneten Mikroprozessoren, z.B. mit einer Memory Protection

Unit (MPU), die verschiedenen Software-Partitionen voneinander ab. Dies verhindert, dass SWCs unerlaubt in den Speicher

anderer SWCs schreiben und so Daten verfälschen. Zusätzlich wird sichergestellt, dass bei einem Task-Wechsel oder Interrupt

der Kontext korrekt umgeschaltet wird.

SafeOs verbessert die Unterstützung von sicheren Systemen mit hohen Anforderungen an die Verfügbarkeit durch ein nach

ISO 26262 entwickeltes Scheduling mit zugehöriger Timing Protection und Applikationsterminierung.

SafeOs enthält weitere Funktionen zur Unterstützung der Partitionierung durch die MPU, z.B. Zugriff auf privilegierte Register,

MPU-Testfunktionen und Datenaustausch über Partitions- und Kerngrenzen hinweg.

19.3.2 SafeE2e - Sichere Inter-ECU-Kommunikation

Daten, die zwischen sicherheitsrelevanten Anwendungen auf verschiedenen Steuergeräten ausgetauscht werden, müssen auf

korrekte Übertragung geprüft werden. Eine Checksumme sichert dazu den Dateninhalt ab. Die korrekte Reihenfolge der Daten

wird durch einen Botschaftszähler überwacht. Schlägt eine dieser Prüfungen fehl, wird die Anwendung informiert und kann

darauf entsprechend reagieren. Dadurch werden Fehler wie Maskerade, Ausfall, Vertauschung, etc. erkannt.

MICROSAR

72

Innerhalb von SafeE2E stehen Ihnen die Transformer ComXf, SomeIpXf und E2eXf nach AUTOSAR 4.2 zur Verfügung, um eine

sichere Kommunikation nach diesem Schema zu gewährleisten. Alternativ bieten wir mit dem ebenfalls erhältlichen Protection

Wrapper eine AUTOSAR-konforme und signalbasierte Schnittstelle. Diese ermöglicht das komfortable Anwenden der E2E-

Absicherung in der Applikation oberhalb der Rte.

19.3.3 SafeWDG - Ablaufkontrolle sicherheitsrelevanter Softwarekomponenten

Das Modul WdgM aus SafeWdg überwacht das korrekte Ausführen von sicherheitsrelevanten Funktionen. Hierzu gehört das

Überwachen der Ausführungsreihenfolge mithilfe des „Program Flow Monitorings“, das in AUTOSAR 4.x speziell für sicherheits-

relevante Anwendungen definiert ist. Das Paket SafeWdg realisiert die Anbindung eines internen oder externen Hardware

Watchdog mithilfe der Module WdgIf, Wdg bzw. Wdg (EXT) und kann auf Wunsch auch externe System Basis Chips (SBC)

unterstützen.

19.3.4 SafeRTE – Sichere Intra-ECU-Kommunikation

Die MICROSAR.RTE unterstützt über die Betriebssystemoption SafeOs die Partitionierung von Speicherbereichen. Um die si-

chere Kommunikation zwischen Anwendungen auf einem Steuergerät zu ermöglichen, ist eine RTE gemäß ISO 26262 erforder-

lich. Zur Absicherung der MICROSAR.RTE steht Ihnen das statische Analysewerkzeug RTE Analyzer optional zur Verfügung.

19.3.5 Absicherung der Hardware

Die Module von MICROSAR Safe setzen voraus, dass die Hardware hinreichend sicher für den Einsatz im Kundenprojekt ist.

Wenn diese Forderung durch die Hardware nicht erfüllt wird, können Sie dies unter Umständen durch geeignete Software-

Prüffunktionen erreichen. Dazu müssen Sie die spezifischen Sicherheitsziele betrachten.

SafeOs enthält in Bezug auf die MPU bereits zusätzliche Funktionen. Weitere Funktionen zur Absicherung von RAM, Flash,

MPU, IO, etc. können als Projektarbeit angeboten werden.

19.4 Konfiguration

Für die Konfiguration der BSW-Module aus MICROSAR Safe empfehlen wir das Werkzeug DaVinci Configurator Pro. Details

hierzu erfahren Sie in der separaten Produktinformation.

19.5 Lieferumfang

MICROSAR Safe ist für den AUTOSAR 4 Standard entwickelt. Zusätzlich zu den BSW-Modulen enthält jede Lieferung von

MICROSAR Safe auch das für sicherheitsrelevante Steuergeräte erforderliche Sicherheitshandbuch (Safety Case) für die nach

ASIL entwickelten Module. Das ausgelieferte Gesamtpaket ist dabei stets ein SEooC für das im Projekt ein entsprechendes

Safety Case Dokument von Vector zur Verfügung gestellt wird.

MICROSAR Safe ist auch für AUTOSAR 3 verfügbar. Somit können Mixed-ASIL-Projekte nach AUTOSAR 3 Standard durchge-

führt werden. Es wird "freedom from interference" mittels MPU-Unterstützung inkl. des sicheren Kontextwechsels, die Lauf-

zeitüberwachung und die sichere externe Kommunikation unterstützt. MICROSAR Safe für AUTOSAR 3 beinhaltet die Haupt-

gruppen SafeOs, SafeE2E und SafeWdg, sowie das Modul SafeCrc.

19.6 Umsetzung

Die Realisierung der sicherheitsrelevanten Funktionen erfolgt durch die oben genannten Bausteine aus MICROSAR Safe. Sie

entsprechen der AUTOSAR-Spezifikation, sind nach ISO 26262 / ASIL D entwickelt und enthalten im Einzelnen:

Baustein Inhalt

SafeOs > Speicherschutz und sicherer Kontextwechsel (Option für MICROSAR.OS)

> Timing Protection (Option für MICROSAR.OS)

SafeE2e > Protection Wrapper: End to End Protection Wrapper

> ComXf, SomeIpXf, E2eXf

> E2e (End to End-Library)

> Crc

SafeWDG > WdgM: Watchdog Manager

> WdgIf: Watchdog Interface

> Wdg: Treiber für interne Watchdog-Bausteine

MICROSAR

73

Baustein Inhalt

> Wdg (EXT): Treiber für externe Watchdog-Bausteinen

> vSbc: Treiber für System Basis Chip Bausteine (mit Watchdog- und Transceiver-Funktion)

MICROSAR

74

20 MICROSAR Security – Zugriffssicherheit für AUTOSAR-Steuergeräte

Mit dem zunehmenden Aufkommen sicherheitsrelevanter und privater Information im Automobil wird auch der Schutz vor

gezielten Manipulationen und vor Datendiebstahl immer wichtiger. Security-Mechanismen werden eingesetzt, um die Integri-

tät, Authentizität und Vertraulichkeit von Information zu schützen. Vector bietet Ihnen in diesem Bereich die in AUTOSAR 4.2

und AUTOSAR 4.3 spezifizierten Komponenten an. Das folgende Bild zeigt die MICROSAR Security Module nach AUTOSAR 4.3.

Bild 44: MICROSAR Security Module nach AUTOSAR 4.3.

20.1 Die Vorteile von MICROSAR Security im Überblick

> Standardkonforme Implementierung von Security-Funktionen aus einer Hand

> Etablierte kryptographische Algorithmen

> Schutz gegen unautorisierte Modifikation kritischer Daten

> Schutz gegen unautorisiertes Lesen von Daten

> Schutz gegen Replay-Attacken

> Authentifizierung von Kommunikationsendpunkten


20.2.1 Crypto Service Manager (CSM)

> Zugriff auf die kryptografischen Dienste

> Konfiguration der kryptografischen Dienste und der Algorithmen durch die der Dienst ausgeführt wird

> Konfiguration für synchrone oder asynchrone Ausführung

> Konfiguration von Secure Countern

> Konfiguration von Operationen an kryptografischen Schlüsseln

> Konfiguration von Operationen an Zertifikaten

MICROSAR

75

20.2.2 Crypto Interface (CRYIF)

Das Modul Crypto Interface CryIf ermöglicht dem CSM Hardware- und Software-basierte Crypto-Lösungen zu verwenden.

Das erforderliche Zuordnungsschema wird vom Crypto Interface verwaltet. Das Modul CRYIF stellt eine einheitliche Schnitt-

stelle für verschiedene Crypto-Lösungen bereit, wie beispielsweise

> Software-basierte Implementierung von Algorithmen, die über das Modul Crypto (SW) bereitgestellt werden

> Hardware-basierte Crypto-Funktionen, die mittels einer Secure Hardware Extension (SHE) oder eines Hardware

Security Modul (HSM) über das Modul Crypto (HW) implementiert werden.

20.2.3 Crypto (SW)

Das Modul Crypto (SW) stellt Implementierungen für die kryptografischen Algorithmen und Funktionen in Software bereit, die

über den CSM zur Verfügung gestellt werden. Alle Berechnungen werden dabei in Software durchgeführt und erfordern keine

spezielle Hardware zur Durchführung der kryptografischen Operationen.

20.2.4 Key Manager (KeyM)

Der Key Manager stellt standardisierte Schnittstellen zur Verfügung, um Prozeduren für das Verfahren zur Schlüsselverwal-

tungs für Fahrzeuge zu implementieren. Darüber hinaus bietet es Funktionen um Zertifikate zu überprüfen und zu parsen.

Der Key Manager verwendet die CSM Schnittstellen um die Schlüssel und Zertifikate zu speichern.

20.2.5 Security Modules (vSecMod)

Das OEM-spezifische vSecMod beinhaltet den Freshness Value Manager (vFVM) und das Key Management (vKeyM) mit den

folgenden Funktionalitäten:

> vFVM: Stellt einen „freshness value“ für das Modul SecOC bereit, um Replay Attacken zu vermeiden. Die Verwendung

von vFVM setzt das Vorhandensein des Moduls SecOC voraus.

> vKeyM: Bewerkstelligt den Schlüssel-Austausch und Schlüssel-Updates

Weitere Informationen zu diesen Modulen erhalten Sie in den OEM-spezifischen Hinweisen in der programmbezogenen Pro-

duktinformation, die Ihrem Angebot beigefügt wird.

20.2.6 Crypto (HW)

Das Modul Crypto (HW) fungiert als Treiber für den Zugriff auf die Security-Algorithmen und Funktionen, die über einen Hard-

ware Trust Anchor (HTA) bereitgestellt werden. Es sind verschiedene HTA-Typen verfügbar, wie beispielsweise Secure Hard-

ware Extensions (SHE) oder Hardware Security Modules (HSM). In Abhängigkeit von der Hardware-Plattform und dem ver-

wendeten Derivat bietet Vector die folgenden Optionen für das Modul Crypto (HW):

> Integration einer von Vector entwickelten Crypto (HW)

> Integration einer 3rd Party Crypto (HW), entwickelt beim Halbleiterhersteller

Als spezielle Implementierung des Crypto (HW) stellt Ihnen Vector optional das Crypto Modul Vector Hardware Security Mo-

dule (vHsm) zur Verfügung. Das vHsm von Vector stellt hierbei die benötigten Algorithmen für den CSM zur Verfügung (mehr

dazu im nächsten Kapitel MICROSAR.HSM).

20.2.7 Secured OnBoard Communication (SecOC)

Das Modul SecOC, auch Authenticated Messaging genannt, dient der authentifizierten Kommunikation zwischen zwei Steuer-

geräten. Durch die Absicherung kann eine dritte Stelle nicht eingreifen oder vorgeben, sie wäre die richtige Gegenstelle. Mani-

pulative Eingriffe sind dadurch ausgeschlossen. Das SecOC interagiert mit dem PDU-Router. Diese Interaktion ist durch die

Applikation steuerbar. Das Modul bietet dabei folgende Funktionen:

> Übertragung von authentisierten und integritätsgeschützten I-PDUs.

> Authentifizierung mit einem Message Authentication Code (MAC). Die tatsächliche Generierung und Validierung des

Message Authentication Code wird vom CSM durchgeführt.

> Verhinderung von Replay-Angriffen. Hierbei kommt ein Zähler zum Einsatz, der „Freshness Value“. Er wird von einer ei-

genständigen Komponente erzeugt, dem Freshness Value Manager (FVM). Es werden hierbei verschiedene Ansätze bei

der Erzeugung der Freshness Values unterstützt.

MICROSAR

76

20.2.8 Vector Ethernet Firewall (vEthFw)

Die Ethernet Firewall vEthFw stellt die Implementierung einer Firewall für die Ethernet Kommunikation bereit. Ihre Hauptauf-

gabe ist es, unerwünschten ein- oder ausgehenden Datenverkehr zu blockieren, um die Sicherheit des gesamten Netzwerks zu

erhöhen.

Das Modul Ethernet Interface (EthIf) erlaubt zusätzliche Callouts an das Modul vEthFw, um der Firewall die Überprüfung des

aktuellen Ethernet-Frames zu ermöglichen und ihn zu verwerfen, wenn er nicht dem konfigurierten Regelwerk entspricht. Das

Modul vEthFw erlaubt die Spezifikation von Filterregeln für verschiedene Typen des Datenverkehrs (IPv4/IPv6, AVB und RAW-

Ethernet) sowie für verschiedene Schichten (UDP, TCP und RAW-Ethernet).

20.2.9 Vector Internet Security (vIpSec)

Das Add-On vIpSec ermöglicht den Aufbau einer IPsec-Kommunikation nach IETF RfC 4301. Die Funktionalität ist auf den

Transportmodus und die Verwendung des Authentication Headers nur nach RfC 4302 beschränkt. Der Authentication Header

fügt den Nutzdaten Datenintegrität und Datenauthentifizierung hinzu, erlaubt aber keine vertrauliche Behandlung.

20.2.10 Vector Transport Layer Security (vTls (Client))

Dieses Modul enthält einen Transport Layer Security Client. Mit vTls wird TCP-basierte Kommunikation verschlüsselt. Der ver-

wendete Verschlüsselungsalgorithmus ist wählbar.

20.2.11 Vector Hardware Security Module (vHsm)

Mehr zum Thema vHsm im nächsten Kapitel MICROSAR.HSM.

20.3 Konfiguration

Für die einfache Konfiguration der Module aus MICROSAR Security empfehlen wir Ihnen das Konfigurationswerkzeug DaVinci

Configurator Pro. Details hierzu finden Sie in der separaten Produktinformation.

MICROSAR

77

21 MICROSAR.HSM – AUTOSAR Basis-Software-Module für Hardware Security Module

Das Paket MICROSAR.HSM beinhaltet das Modul vHsm, das wiederum ein Paket für verschiedene Untermodule ist. Das vHsm

ist Vectors Lösung für Hardware Security Module (HSM) der verschiedensten Halbleiterhersteller. Die Lösung ermöglicht so-

wohl einfache als auch umfangreiche Konfigurationen, um dem dem Anwendungsfall und seinen Anforderungen gerecht zu

werden. vHsm stellt unterschiedliche Security Services bereit, die auf einem separaten und sicheren Kern des Mikrocontrollers

ausgeführt werden und verwendet dabei die verfügbaren Hardwarebeschleuniger.

Das folgende Übersichtsbild zeigt die Module, die zur vHsm Lösung gehören. vHsm benötigt zusätzlich den Kryptotreiber

Crypto(vHsm) als Interface zum AUTOSAR Stack. Eine detailreichere Sicht auf die Architektur des vHsm ist in Abschnitt Mo-

dule und ihre Add-Ons dargestellt.

Der vHsm beinhaltet verschiedene kryptographische Funktionen und Merkmale, die in den nachfolgenden Abschnitten beschrie-

ben werden. Dabei handelt es sich um ein eigenständiges Paket für ein HSM, inklusive Einplanung und Verarbeitung von Krypto-

Anfragen. Zusammen mit dem Crypto(vHsm)-Treiber stellt es alle nötigen Teile für die Anbindung an einen AUTOSAR Stack

zur Verfügung.

21.1 Die Vorteile von MICROSAR.HSM

> vHsm stellt sicher, dass Crypto-Material niemals vom sicheren Kern an den Kern weitergegeben wird, auf dem der AU-

TOSAR Stack läuft.

> vHsm stellt eine modulare Architektur zur Verfügung, die vom Nutzer so konfiguriert werden kann, dass vHsm den Leis-

tungs- und Platzbedarfanforderungen des jeweiligen Anwendungsfalles genügt.

> vHsm verfügt über eine große Bibliothek von Kryptoalgorithmen, die auf dem HSM ausgeführt werden können.

> vHsm wird als Quellcode zusammen mit einem umfassenden Konfigurationstool und Debugging-Funktionen bereitge-

stellt.

MICROSAR

78


Das Cluster MICROSAR.HSM ermöglicht die Verwendung von Hardwarebeschleunigung sowie isolierte Funktionen für krypto-

graphische Operationen. Das vHsm ist für den Einsatz auf einem Mikrocontroller mit integriertem HSM vorgesehen, das über

einen sicheren Kern verfügt. Daher läuft vHsm eigenständig und isoliert vom AUTOSAR Stack auf dem sicheren Kern mit un-

abhängigem Speicher (Flash oder RAM), während der AUTOSAR Stack auf einem oder mehreren Anwendungskernen läuft.

Die Kommunikation der vHsm Firmware mit dem AUTOSAR Stack ist komplett abstrahiert und wird vom Kryptotreiber

Crypto(vHsm) verwaltet. Crypto(vHsm) ist konform zu AUTOSAR 4.3 und Teil der MICROSAR BSW.

Durch die Integration mit einem AUTOSAR-Hostsystem können Entwicklungsfehler über einen DET-Proxy auf dem HSM an das

DET des AUTOSAR Stacks gemeldet werden. Darüber hinaus können Fehler in einen sicheren Datenflash geschrieben und von

der Anwendung gelesen werden.

Anwendungsbeispiele des vHsm sind die effiziente Verarbeitung von kryptographischen Algorithmen sowie die Schlüsselver-

waltung für z.B. Secure Boot und Secure OnBoard Communication (SecOC).

21.3 Funktionen

vHsm verfügt über eine Vielzahl von Funktionen und Kryptoalgorithmen, die auf dem HSM ausgeführt werden können, sei es in

Software auf dem sicheren Kern oder hardwarebeschleunigt.

21.3.1 Schlüsselspeicher

> Sichere Speicherung im HSM (für symmetrische/asymmetrische Schlüssel, Zertifikate und beliebige andere sicherheitsre-

levante Daten, wie z.B. Kilometerstand, freshness values)

> Installation von symmetrischen Schlüsseln gemäß SHE 1.1

> Freie Wahl des Schlüsselspeichers (Flash oder RAM)

> Redundante und Reset-sichere Speicherung

> Schlüssel werden beim Start vorgeladen / zwischengespeichert, um ein Laden bei jedem Gebrauch zu vermeiden

> Schlüssel können gesperrt werden, bis der secure boot Vorgang beendet ist

> Schlüssel können als einmalig schreibbar konfiguriert werden

> Schlüssel können sofort einzeln oder verzögert mit mehreren anderen Schlüsseln persistiert werden (optimiert die Ge-

schwindigkeit und reduziert die Anzahl der Flash-Zugriffe)

21.3.2 Secure Boot Unterstützung

> Unterstützung von Secure Boot und Authenticated Boot

> Der sichere Startvorgang kann in verschiedene Phasen und Segmente aufgeteilt werden

> Das erste Segment wird automatisch geprüft, z.B. für die Bootloader-Verifikation

> Der Bootloader kann einen oder mehrere weitere Phasen starten (sequentieller oder paralleler Secure Boot)

> Secure Boot Maßnahmen im Falle von Fehlern sind konfigurierbar (Systemreset, nur Protokollierung, keine Freigabe von

Schlüsseln)


Der vHsm Software Stack ist nicht im AUTOSAR Standard spezifiziert, auch wenn er einige AUTOSAR-konforme Module ver-

wendet. Somit besteht der vHsm aus mehreren dedizierten Modulen und aus Vector Standardsoftware.

Dieser Abschnitt gibt eine Übersicht über die interne Architektur von MICROSAR.HSM und sein Funktionsschema. Darüber

hinaus werden die verfügbaren Add-Ons beschrieben.

21.4.1 Module die im vHsm enthalten sind

>

vHsm ist die Schlüsselkomponente der vHsm Lösung. Sie bietet:

MICROSAR

79

> Empfang eingehender Kryptoanfragen des AUTOSAR Kryptotreibers Crypto(vHsm)

> Bewertung der eingehenden Kryptoanfragen und Verteilung an die entsprechenden Untermodule und Treiber (unter-

stützte Auftragsarten sind die Verarbeitung von Kryptoalgorithmen und die Schlüsselverwaltung)

> Verwaltung von Lese- und Schreibzugriffen auf nichtflüchtigen Speicher

>

vHsm_Hal stellt die Hardwareabstraktion des HSM im Mikrocontroller zur Verfügung und stellt hardwarebeschleunigte

Algorithmen (z.B. CMAC, AES, TRNG) bereit

>

vHsm_Core bietet Funktionen für Secure Boot und sicheren Software-Download

>

vHsm_Custom stellt eine Vorlage für die Implementierung kundenspezifischer Erweiterungen zur Verfügung.

Darüber hinaus verwendet der vHsm Stack die folgenden Vector Standardmodule:

> CryIf, Crc, Crypto(Sw), Det, Fee, MemIf und FlsDrv

21.4.2 Add-Ons

Für den vHsm sind Add-Ons und Erweiterungen erhältlich. Besonders der Kryptotreiber vHsm_Custom ist dafür gedacht, spe-

zielle Benutzerfunktionen zu integrieren, um bestimmten Anforderungen des jeweiligen Anwendungsfalls zu genügen. Diese

AUTOSAR-konforme Kryptotreiber-Vorlage muss vom Benutzer konfiguriert und gefüllt werden. Auf Anfrage können weitere

Funktionen auch von Vector integriert werden.

Add-Ons

>

> Bereitstellung von asymmetrischen kryptografischen Algorithmen

> Erzeugung und Überprüfung von RSA und ECC Signaturen

> Sichere Speicherung und Aktualisierung der symmetrischen Schlüssel

>

> Ermöglicht das Aktualisieren des vHsm im Code Flash des HSM (eine Aktualisierung des Daten Flashs ist nicht vorge-

sehen)

> Dabei handelt es sich um ein separates Modul, das als Binärprogramm im HSM Code Flash platziert werden muss.

> Ermöglicht geschützte Aktualisierungen des vHsm (verschlüsselt und signiert)

21.4.3 Integrations-Szenarien

Für die Integration und die Verwendung von MIRCROSAR.HSM gibt es zwei Hauptszenarien. MICROSAR.HSM kann zusammen

mit MICROSAR von Vector verwendet werden, ist aber auch kompatibel zu jedem beliebigen AUTOSAR Stack von Drittanbie-

tern, der nach AUTOSAR 4.3 entwickelt ist. Das folgende Bild zeigt das Zusammenspiel der vHsm Firmware mit einem AUTO-

SAR Stack und einem Flash Bootloader.

MICROSAR

80

Bild 45: Integrations-Szenario – vHsm, AUTOSAR and Flash Bootloader

21.5 vHsm und Vector MICROSAR

In dieser Konstellation wird vHsm zusammen mit MICROSAR von Vector verwendet. Diese Lösung aus einer Hand bietet opti-

mierte Interaktion auf Embedded Code- und Tooling-Ebene sowie die Vorintegration von vHsm und MICROSAR.

Diese Lieferung besteht aus den folgenden Positionen:

> vHsm Software Integration Package (SIP) und Quellcode

> MCROSAR SIP inklusive Kryptotreiber Crypto(vHsm)

> DaVinci Configurator Pro für die Konfiguration von vHsm und MICROSAR

21.5.1 vHsm und AUTOSAR eines Drittanbieters

In dieser Konstellation wird vHsm zusammen mit einem AUTOSAR 4.3 konformen Stack eines Drittanbieters eingesetzt.

Hinweis: Bei der Verwendung von vHsm mit einem AUTOSAR Stack eines Drittanbieters muss der Anwender besonders auf die

Konsistenz der vHSM- und AUTOSAR-Konfigurationen achten. In einem solchen Fall kann von Vector keine Werkzeugunter-

stützung angeboten werden.



> Kryptotreiber Crypto(vHsm) (AUTOSAR 4.3 konform) für den Host AUTOSAR BSW

> DaVinci Configurator Pro für die Konfiguration des vHsm

21.5.1.1 vHsm und Flash Bootloader

In dieser Konstellation wird vHsm zusammen mit dem Flash Bootloader (FBL) von Vector verwendet. Das bietet mehrere Vor-

teile:

> Nahtlose Integration mit dem Vector Flash Bootloader, z.B. für Secure Boot Anwendungsfälle

> Detailliertere Test- und Vorintegrationsmöglichkeiten für vHSM und FBL bei Vector

> Vereinfachte Tool-Unterstützung

> DaVinci Configurator Pro wird sowohl für den vHsm als auch den Flash Bootloader verwendet.

MICROSAR

81



> Flash Bootloader SIP

> DaVinci Configurator Pro für die Konfiguration von vHsm und Flash Bootloader

21.6 Konfiguration


Produktinformation.

Bild 46: Configuration of MICROSAR.HSM (vHsm) in DaVinciConfigurator Pro

MICROSAR

82

22 MICROSAR Gateway – Basissoftware für Gateway Steuergeräte

Gateway Steuergeräte sind zentrale Knotenpunkte in der oft heterogenen Netzwerkarchitektur eines Fahrzeugs. In dieser Rolle

verbindet ein Gateway die verschiedenen Netzwerke, um die Datenübertragung zwischen verteilten Steuergeräten auch über

unterschiedliche Netzwerktypen hinweg zu ermöglichen. Die Leistungsindikatoren eines Gateways bewegen sich dabei im

Spannungsfeld zwischen hohen Datendurchsätzen sowie geringer Ressourcenbelastung (insb. RAM und CPU Auslastung) und

niedrigen Latenzzeiten bei der Übertragung.

Vector bietet für Gateways optimierte Module, die sowohl ein Routing auf unterschiedlichen Protokollebenen als auch zwischen

unterschiedlichen Bus-Systemen (CAN, LIN, FlexRay, Ethernet) ermöglicht. Aufbauend auf diesen Basisfunktionen bietet

MICROSAR Gateway eine Reihe von Sonderfunktionen, beispielsweise zur Spiegelung von Sub-Netzwerken und ein modulares

Plug-In Konzept zur Erweiterung der vorhandenen Funktionalität. Durch dieses dreistufige Konzept aus Basisfunktionalität,

Sonderfunktionen und Erweiterbarkeit bietet MICROSAR Gateway die nötige Flexibilität um spezifische Anwendungsfälle ab-

zudecken.

Um eine optimale Gateway Performance zu ermöglichen, folgt MICROSAR Gateway an einigen Stellen einer unabhängigen

Architektur. Diese erfüllt die AUTOSAR-Architekturkonformitätsklasse 2 (ICC2), so dass AUTOSAR-Softwarekomponenten

eingebunden werden können.

Bild 47: Multi-Layer Gateway in MICROSAR

22.1 Die Vorteile von MICROSAR Gateway im Überblick

> Routing auf unterschiedlichen Protokollebenen (PDU, High-Level TP, PDU-Abschnitt, Signal)

> Routing zwischen unterschiedlichen Netzwerktypen (CAN, LIN, FlexRay, Ethernet)

> Flexibel konfigurierbare Pufferkonzepte (Rx FIFO Queue, Tx FIFO Queue, prioritätsbasierte Queue)

> Flexibel konfigurierbare Verarbeitungskonzepte (Interrupt, Task)

> Post-Build-Ansatz zum flexiblen Nachladen von Routingbeziehungen

> Spiegelung von Sub-Netzen auf den Diagnosezugang (CAN und Ethernet)

> Erweiterter Support für NM-Koordinatoren

> Werkzeugkette zur automatischen Verarbeitung von Eingangsdaten (.dbc, .ldf, .fibex, .arxml und proprietäre Formate)

> Definierte Schnittstellen zur Erweiterung der Werkzeugkette (Scripting, Extensions) und der Basissoftware (Cdd-sup-

port)

> Optional begleitender Support von Gateway-Projekten durch Vector in enger Zusammenarbeit mit dem Tier1

MICROSAR

83


MICROSAR Gateway bietet dem Anwender die notwendige Basissoftware, um Daten auf der jeweils optimalen Protokollebene

zwischen CAN-, LIN-, FlexRay- und Ethernet-Netzwerken zu routen. Dieser flexible Ansatz erlaubt den Einsatz von MICROSAR

Gateway in der Entwicklung von

> lokalen Gateways (beispielsweise im Türbereich)

> Domänencontroller (zum Beispiel Body Controller)

> zentralen Gateways (beispielsweise als zentraler Diagnosezugang oder für Connectivity-Anwendungen).

22.3 Funktionen

> Routing auf verschiedenen Protokollebenen

> PDU Routing (auf Interface-Ebene):

> Effizientes Event-basiertes Routing auf Botschafts- und PDU-Ebene

> Unterstützung unterschiedlicher Pufferstrategien (last-is-best, FIFO, prioritätsbasiert)

> Routing von „contained PDUs“ (SoAd und IpuM)

> Unterstützte Netzwerke: Ethernet, CAN, LIN, Flexray

> High-Level TP Routing

> Routing zwischen unterschiedlichen Transportprotokollen

> Segmentierte Übertragung mit zeitlicher Ablaufkontrolle und Bandbreiten-Management

> Spezielle Pufferbehandlung: „Routing-on-the-fly“, „request queueing“, „buffer sharing“

> Unterstützte Netzwerke: Ethernet, CAN, LIN, Flexray

> PDU-Abschnitts-Routing (Description-based Routing)

> Effizientes Routing von Datenabschnitten in PDUs, definiert über Startbit, Zielbit und Länge

> Kontrolliertes Sendeverhalten (periodisches Senden, Senden bei Datenveränderung, Reaktion auf Zeitüberschreitun-

gen, minimaler Sendeabstand, etc.)

> Unterstütze Netzwerke: Netzwerkunabhängiges Routing

> Signalbasiertes Routing

> Routing von entpackten Datensignalen

> Kontrolliertes Sendeverhalten (periodisches Senden, Senden bei Datenveränderung, Reaktion auf Zeitüberschreitun-

gen, minimaler Sendeabstand, etc.)

> Möglichkeit zur Durchführung von Konvertierungen (Endianess, Signallänge, Signalinhalte)

> Unterstütze Netzwerke: Netzwerkunabhängiges Routing

MICROSAR

84

Bild 48: Routing auf unterschiedlichen Protokollebenen

> Erweiterbare Basissoftware (Plug-In Architektur)

> Effiziente Integration von eigener Software in den Datenfluss (realisiert über Complex Device Driver (Cdd) nach AU-

TOSAR)

> Konfiguration von Cdds im Konfigurationswerkzeug

> Generierung von Templates zur Einbindung des Cdds in die Basissoftware

> Cdds können oberhalb der Interfaces, unterhalb des PDU Routers und oberhalb des PDU Routers eingebunden wer-

den

> Callouts zur Integration von eigener Software in den Kontrollfluss (oft auch mit der Möglichkeit die Daten zu beein-

flussen)

> Gateway-Optimierungen

> Deferred Event Caching: Effiziente Verarbeitung von Rx Ereignissen auf COM Ebene

> Timing Domains: Effiziente Behandlung von Tx Ereignissen auf COM Ebene

> Description based Routing: Effizientes Routing von Datenabschnitten

> Dynamisches Routing

> Lernendes Diagnoserouting: Routing von Diagnose-Requests in Abhängigkeit der erlernten ECU Position (z.B. durch

Empfang einer Diagnose-Response)

> Routing in Abhängigkeit der CAN ID, z.B. Routing von CAN ID Bereichen durch die Nutzung des AUTOSAR Meta-Daten

Feature

> Mirroring

> Spiegelung von einem internen CAN- oder LIN-Kanal auf den Diagnose CAN

> Spiegelung von mehreren internen CAN, LIN Netzwerken und einem FlexRay (A+B Kanal) Netzwerk auf den Diagnose

Ethernet

> NM Koordination

> Post-Build: Update der Gateway Konfiguration ohne die Notwendigkeit, das gesamte Steuergerät re-programmieren zu

müssen. Weitere Informationen zu Post-Build entnehmen Sie bitte dem separaten Kapitel "MICROSAR Variantenhand-

ling".

MICROSAR

85

22.4 Konfiguration

Gateway Konfigurationen sind häufig sehr umfangreich. Umso wichtiger ist die Möglichkeit der automatischen Bedatung der

Basissoftware in Abhängigkeit der vom OEM zur Verfügung gestellten Eingangsdaten. Das Konfigurationswerkzeug DaVinci

Configurator Pro von Vector unterstützt eine automatische Bedatung über verschiedene Verfahren:

> Konfiguration über ein AUTOSAR System Extract (arxml): Das von AUTOSAR definierte Datenformat erlaubt die expli-

zite Spezifikation von Routinginformationen. Diese werden von DaVinci Configurator Pro eingelesen und in eine Soft-

warekonfiguration umgewandelt.

> Konfiguration über erweiterte Netzwerkdateien: Die proprietären Netzwerkdateien (dbc /ldf /fibex) bieten in der Regel

keine Möglichkeit, um Routinginformationen nativ zu spezifizieren. DaVinci Configurator Pro interpretiert jedoch diverse

Zusatzattribute und kann Regeln auswerten (z.B. eine bestehende Namensgleichheit von Signalen), um Routinginforma-

tionen abzuleiten.

> Konfiguration über proprietäre Daten (z.B. xls): Die Werkzeugkette von Vector bietet zusätzlich die Möglichkeit, Rou-

tinginformationen über eine separate Zusatzdatei zu definieren. Diese Datei erlaubt es, in einem von Vector spezifizier-

ten XML Format (Vector System Description Extension, VSDE) Nachrichten und Signale aus den Netzwerkdateien zuei-

nander in Beziehung zu setzen um damit Routingbeziehungen zu spezifizieren. Eine VSDE-Datei eignet sich besonders,

um proprietäre Routingkonfigurationen in die Werkzeugkette einzubinden. Dies erfordert die Implementierung einer

Konvertierungsroutine, welche die proprietäre Datei in eine VSDE Datei überführt.

> Scripting: Die oben beschriebenen Verfahren lassen sich zusätzlich mit einer Scripting-Lösung kombinieren. Mit der Da-

Vinci Configurator Pro Option WF (Workflow) erstellen Sie spezifische Scripte für Ihr Projekt, über die Sie programma-

tisch Routinginformationen ergänzen.

Die mit diesen Verfahren erzeugte Softwarekonfiguration ist dabei kein einmaliger Vorgang. Sollten sich die Netzwerkbeschrei-

bung in den Eingangsdateien ändern, lässt sich die Softwarekonfiguration automatisch aktualisieren.

Bild 49: Die Optionen zur automatischen Konfiguration der BSW für das Gateway mit DaVinci Configurator Pro

Neben der automatischen Ableitung der Konfiguration können alle Parameter auch manuell in DaVinci Configurator Pro bear-

beitet werden. Mehr Details hierzu finden Sie in der separaten Produktinformation.

22.5 Projektsupport

An Gateway Steuergeräte werden besonders häufig sowohl OEM-spezifische als auch anwendungsspezifische Anforderungen

gestellt, die ein Standardprodukt in der Regel nicht vollumfänglich erfüllt. Um diese Anforderungen in ihrem Projekt dennoch

effizient abzubilden, bietet Vector einen zweistufigen Ansatz:

> Zunächst unterstützt MICROSAR Gateway eine Vielzahl von Erweiterungsmöglichkeiten im Sinne einer Plug-In Architek-

tur, die es Ihnen erlaubt, eigene Software zu entwickeln oder Drittanbieter-Software zu integrieren.

> Optional bieten wir darüber hinaus unsere Unterstützung an, um aufbauend auf diesen Schnittstellen gemeinsam mit

Ihnen die Projektanforderungen zu bearbeiten. Dies erlaubt eine wesentlich flexiblere Implementierung der Kundenanfor-

derungen, als dies in einem durch Release-Zyklen geprägten Produktansatz möglich ist. Innerhalb eines gemeinsamen

MICROSAR

86

Projekts implementieren wir dann gerne auch die zur Erfüllung der Kundenanforderungen notwendigen Produkterweite-

rungen.

Bild 50: Dreischichtige Herangehensweise zur optimalen Entwicklungsunterstützung

MICROSAR

87

23 MICROSAR Multi-core – Die AUTOSAR Lösung für Mehrkern-Prozessoren

Durch die Einführung von Multi-core Prozessoren verändert sich nachgelagert das Design der AUTOSAR-Software. Einzelne

AUTOSAR-Anwendungen können auf unterschiedliche Prozessorkerne verteilt und somit zeitgleich betrieben werden. Entschei-

dend für den Erfolg ist eine optimale Verteilung mit geringen Synchronisationsverlusten, verursacht beispielsweise durch War-

tezeiten. MICROSAR Multi-core unterstützt Sie hierbei umfassend.

23.1 Die Vorteile von MICROSAR Multi-core im Überblick

> MICROSAR Multi-core ist vollständig in das Gesamtpaket MICROSAR integriert und wird hauptsächlich von MICRO-

SAR.OS und MICROSAR.RTE wie folgt umgesetzt:

> Nutzung von nur einer OS-Konfiguration für alle Prozessorkerne

> Nutzung von Shared-Memory und effizienten Spinlocks für die RTE zur Verringerung von Laufzeit und Speichernutzung

> Eng verzahnt mit der Vector Lösung MICROSAR Safe: Alle Multi-core Funktionen fügen sich nahtlos in das Safety-Kon-

zept von MICROSAR ein

> Bereitstellung von AUTOSAR BSW-Satelliten auf Slave-Prozessorkernen zur Gewährleistung einer laufzeitoptimierten

Abwicklung der Servicefunktionen

> Mixed ASIL Partitioning & BSW Split macht es möglich, einen Teil der Laufzeit der Basissoftware auf einen anderen Kern

zu verlagern, um den Kern, auf dem die Basissoftware läuft zu entlasten. Ebenso unterstützt es die Partitionierung der

Kommunikationspakete in mixed ASIL Systemen (z.B. CAN- und Ethernet-Stacks in verschiedenen Partitionen)

> Einfache Konfiguration

> Erhältlich für einzelne MICROSAR-Module

> Mit der TA Tool Suite von Vector optimieren Sie effizient Ihre Anwendung hinsichtlich CPU-Lastverteilung zwischen den

Kernen, Reaktionszeiten von Effektketten sowie Reduzierung der Inter-Core-Kommunikation.


Das Einsatzgebiet von MICROSAR Multi-core umfasst den Betrieb der vorhandenen Prozessorkerne für Anwendungen, in de-

nen:

> Die BSW auf einem der vorhandenen Kerne läuft

> Jede beliebige Aufteilung der Anwendungssoftware auf alle verfügbaren Kerne möglich ist.

Das Ziel dabei ist es, die Anwendung mit dem höchsten Maß an CPU-Nutzung auf mehrere Prozessorkerne zu verteilen. MICRO-

SAR Multi-core bietet dafür folgende Funktionen an:

> Bereitstellung effizienter Mechanismen, um die Services der BSW auf allen Prozessorkernen zu nutzen

> Bereitstellung von BSW-Satelliten auf Slave-Prozessorkernen, sofern notwendig

> Nutzen von RTE-Standardmechanismen, um Services der Basissoftware zu teilen und dabei Laufzeit zu optimieren und

Speichernutzung zu minimieren

Dieser Multi-core-Ansatz funktioniert auch mit der Lösung MICROSAR Safe.

23.3 Funktionen

23.3.1 RTE

Die MICROSAR.RTE verwendet im Multi-core Umfeld bevorzugt Shared-Memory, um Laufzeit und Speicherbelegung zu mini-

mieren. Bei Bedarf werden Spinlocks verwendet, um die Datenkonsistenz abzusichern. Dabei entstehen nur dann Wartezeiten

für die Prozessorkerne, wenn sie zur gleichen Zeit auf den gleichen Speicherbereich zugreifen.

23.3.2 Betriebssystem (OS)

Für alle beteiligten Prozessorkerne ist nur eine einzige OS-Konfiguration notwendig. Über den AUTOSAR-Standard hinausge-

hend bietet MICROSAR Multi-core schnellere Spinlocks, wodurch die Daten in allgemein zugänglichen Speicherbereichen ge-

halten werden können.

MICROSAR

88

23.3.3 ECU Manager

Der ECU-Manager läuft auf dem Hauptprozessorkern. Die Koordination zwischen den Kernen erfolgt über Satelliten auf jedem

der anderen Kerne. Hierdurch ist auch beim EcuM nur eine einzige Konfiguration erforderlich, die für alle Prozessorkerne gültig

ist.

23.3.4 Watchdog Manager

Der Watchdog Manager läuft ebenfalls auf dem Hauptprozessorkern. Auf allen weiteren Kernen verarbeitet ein Satellit die

"checkpoint reached"-Funktion der Anwendung und synchronisiert deren Status mit dem Master. Dies gewährleistet eine lauf-

zeitoptimierte Abwicklung der Servicefunktionen des WdgM.

23.3.5 Diagnostic Event Manager

Der Diagnostic Event Manager implementiert das Master-Satelliten-Muster, um diese beiden Punkte zu ermöglichen:

> Laufzeitfähige Multi-core-Architekturen durch an Kerne gebundene APIs zum Lesen und Schreiben des Diagnosestatus

> Mixed-ASIL Systeme, in denen die Dem-Entities auf derselben ASIL-Ebene ausgeführt werden wie die Anwendungs-

SWC.

23.3.6 Multi-Core BSW Split

Multi-Core BSW Split macht es möglich, einen Teil der Laufzeit der Basissoftware auf einen anderen Kern zu verlagern, um den

Kern, auf dem die Basissoftware läuft zu entlasten. Erreicht wird diese Entlastung durch Auslagern eines oder mehrerer Bus-

Systeme. Konkret werden dabei die Main Functions und Interrupts der ausgelagerten Busse auf den anderen Kern verschoben.

Eine Beschleunigung der Basissoftware wird dadurch jedoch nicht erzielt, auch keine Effizienzsteigerung des Stacks. Es ent-

stehen sogar zusätzlich Latenzen und Overhead durch die Kommunikation über die Kerngrenzen hinweg. Ein messbarer posi-

tiver Effekt stellt sich darum nur ein, wenn die Bus-Systeme ausgelagert werden, die maßgeblich zur Belastung dieses Kerns

beitragen. Dann kann dieses Feature den Unterschied zwischen einem überlasteten und einem stabil laufenden System bedeu-

ten.

23.4 Konfiguration

23.4.1 Konfiguration des Betriebssystems

Bei der Konfiguration wird statisch festgelegt, auf welchem Prozessorkern das Betriebssystem laufen soll. OS-Anwendungen

werden konfiguriert und jede für sich einem speziellen Kern zugewiesen. Mittels der Zuordnung der OS-Objekte wie z.B. Tasks,

Interrupts und Alarms zur OS-Anwendung wird ihre Kern-Zugehörigkeit schließlich festgelegt.

23.4.2 Konfiguration der Rte

Die Rte muss wissen, welche Software auf welchem Prozessorkern läuft. Nur dann ist die Rte in der Lage

> die Konsistenz des Datenaustauschs zu sichern

> im Bedarfsfall die Runnables auch Prozessorkern-übergreifend zu aktivieren

Hierzu erfolgt bei der Konfiguration ein Mapping der einzelnen Runnables auf OS-Tasks und nachfolgend die Zuweisung dieser

Tasks zu einer OS-Applikation. Jede OS-Applikation wird dann wieder einem konkreten Prozessorkern zugeordnet.

MICROSAR

89

Bild 51: Zuordnung von SWCs, Tasks und OS-Instanzen zu den Prozessorkernen (schematische Darstellung)

Für eine komfortable Konfiguration Ihres Steuergerätes empfehlen wir den DaVinci Configurator Pro. Mehr Details hierzu fin-

den Sie auf unserer Website https://vector.com/vi_davinci_configurator_pro_de.html.

23.5 Lieferumfang

Im Rahmen der Lieferung erhalten sie alle gewählten Module aus dem MICROSAR-Paket in einem für Multi-core-Projekte ge-

eigneten Umfang. Einige Module wurden verändert, um effizienter mit den Anforderungen für Multi-core umgehen zu können.

> Master-Satellite-Module: WdgM / WdgIf, Dem, EcuM, Xcp, Rtm, Det

> Anwendungs-Proxies: NvM, Com

MICROSAR

90

24 MICROSAR Variantenhandling - Lösungen für flexible Konfigurationen in AUTOSAR

Bei der traditionellen Aufgabenverteilung der Steuergeräteentwicklung definiert der Fahrzeughersteller die Kommunikations-

und Diagnose-Schnittstellen. Der Zulieferer implementiert und baut das Steuergerät entsprechend diesen Vorgaben. Sollen

nach Lieferung des Steuergerätes Parameter geändert werden, muss der Zulieferer eine neue Version des Steuergerätes ent-

wickeln. Diese Entwicklungskette kostet bei kleinen Änderungen unverhältnismäßig viel Zeit und Geld. Besonders die Entwick-

lung von Steuergeräten mit einer volatilen BSW-Konfiguration kann durch die Flexibilität des optionalen MICROSAR Post-Build

Loadable profitieren.

Zusätzlich nimmt in den Automobilen die Anzahl der Steuergeräte, die in unterschiedlichen Varianten verbaut werden können

stetig zu - sogenannte Mehrfachsteuergeräte. Ihr Vorteil ist das Verwenden einer einzigen Hardware für die unterschiedlichen

Einsatzbereiche. Das reduziert Hardwarekosten und den Aufwand bei der Lagerverwaltung. Im Gegenzug entsteht ein Mehr-

aufwand bei der Softwareentwicklung und der Verwaltung der Softwarevarianten in der Fertigung und im Service. Für diesen

Anwendungsfall steht mit dem optionalen MICROSAR Identity Manager eine passende Post-Build Selectable Lösung bereit.

24.1 Post-Build Loadable – Nachträgliche Modifikation von BSW-Merkmalen

24.1.1 Die Vorteile im Überblick

> Anpassung vieler BSW-Parameter direkt durch den Fahrzeughersteller

> Flexible und spontane Anpassung der BSW im Rahmen von Entwicklung und Erprobung

> Post-Build Updates ohne die Verwendung von Compiler (-Lizenzen)

> Die zentrale Ressourcen-Verwaltung erlaubt es, die BSW-Konfiguration flexibel um weitere Elemente (z.B. Botschaften)

zu erweitern

> Spezielle Erweiterungen in DaVinci Configurator Pro sorgen für eine reibungslose Post-Build-Konfiguration

> Höchstmaß an Sicherheit durch Konsistenzprüfungen in der MICROSAR BSW und DaVinci Configurator Pro

> Keine Änderung der Anwendungs-Architektur notwendig: Verwendung vielfach erprobter MICROSAR BSW nach AUTO-

SAR

> Post-Build Loadable ist als Option für zahlreiche BSW-Module und Funktionen verfügbar

24.1.2 Anwendungsgebiete

Post-Build Loadable erlaubt das Ändern bestimmter BSW-Eigenschaften aus den Bereichen Diagnose und Kommunikation

nachdem das Steuergerät produziert und geflashed wurde. Neben der Änderung von Parametern wie zum Beispiel der CAN ID,

Sendeart oder Default- Werten können auch neue Objekte nachträglich in das Steuergerät eingeführt werden. So lassen sich

zum Beispiel Gateway Routing Tabellen um neue Botschaften oder Signale erweitern. Für die Anpassung der BSW-Parameter

zum Post-Build-Zeitpunkt wird nur die MICROSAR Lieferung benötigt. Die Anwendung, Compiler (-Lizenzen) werden für ein

Post-Build Update nicht mehr benötigt. Ebenso ist keine Anpassung der Anwendungsschicht notwendig. Somit kann auch der

Fahrzeughersteller Anpassungen an der BSW direkt und unkompliziert vornehmen.

24.1.3 Vertrauter Konfigurationsprozess

Der Konfigurationsprozess zum Post-Build-Zeitpunkt findet mit dem Standard-Konfigurationswerkzeug DaVinci Configurator

Pro statt. Es steht somit ein mächtiges Werkzeug für die reibungslose Synchronisation mit einer Vielzahl von Datenbanken

(DBC, SystemDescription, ODX, CDD…) zur Verfügung.

Über die MICROSAR Post-Build Loadable-Werkzeugkette wird in einem einfachen Schritt eine HEX-Datei der aktualisierten

BSW-Konfiguration erzeugt, die mit Standard-Flash-Werkzeugen in das Steuergerät geladen werden kann.

MICROSAR

91

Bild 52: MICROSAR Post-Build Loadable Workflow

24.1.4 Lieferumfang "Post-Build Loadable"

> Lizenz für die Freischaltung im Konfigurations-Werkzeug

> Werkzeuge zur Erstellung eines Build Loadable Updates

> Dokumentation

24.2 Der MICROSAR Identity Manager - die Post-Build Selectable Lösung für Mehrfachsteuergeräte

24.2.1 Die Vorteile im Überblick

> Effizienter Umgang mit Steuergerätevarianten

> Weniger Administrationsaufwand

> Verringerung der Lagerkosten

> Ressourcenoptimierte Umsetzung der BSW-Konfiguration

> als Option für zahlreiche BSW-Module und Funktionen verfügbar

24.2.2 Anwendungsgebiete

Der Identity Manger kann alternativ zwei Funktionen wahrnehmen:

Beispiel "Türsteuergerät": Steuergeräte mit nahezu identischen Aufgaben, die sich nur in ihren Empfangs- und Sende-PDUs

bzw. der Diagnose und der Adresse im Netzwerk unterscheiden, können in einem Fahrzeug als ein Bauteil mit nur einer Teile-

nummer realisiert werden. Gefertigt wird also nur noch ein einziges Steuergerät, das beim Hochfahren über die ihm zugewie-

sene Identität seine Position, Aufgabe und Funktionen kennt. Die Puffer der Empfangs- und Sende-PDUs können komplett

überlagert werden, wenn deren Layout identisch ist. Die Anwendung greift unabhängig von der Identität auf die Signale und

Datenelemente zu. Eine Unterscheidung im Code ist nicht notwendig.

Beispiel "Übernahmesteuergerät": Funktional ähnliche Steuergeräte in mehreren Baureihen können als ein Bauteil entwickelt

und gefertigt werden. Sie beinhalten die Software aller Baureihen, für die sie eingesetzt werden und unterstützen dann je

MICROSAR

92

Baureihe eine unterschiedliche Kommunikationsbeschreibung. Die bei der Konfiguration zugrundeliegenden Datenbanken kön-

nen sich bei den verwendeten Varianten deutlich unterscheiden – zum Beispiel durch ein komplett anderes Signallayout oder

eine unterschiedliche Anzahl an Netzwerken.

Bild 53: Einsatz eines Steuergerätes mit unterschiedlichen Funktionen unter Verwendung des Identity Managers

24.2.3 Vertrauter Konfigurationsprozess

Der Konfigurationsprozess eines Steuergeräteprojektes das mehrere Varianten unterstützt, ist analog zu einem Projekt ohne

Varianten mit dem Unterschied dass für jede Variante ein eigener Satz an Systembeschreibungen (Extract of System Descrip-

tion, Legacy-Formate wie DBC, Diagnose Beschreibungen (CDD, ODX)) vorgegeben werden.

24.2.4 Variantenauswahl

Sofern ein Steuergerät mehrere Konfigurationsvarianten unterstützt, wird die zu verwendende Variante bei der Steuergeräte-

Initialisierung ausgewählt. Die Quelle der Varianteninformation ist frei definierbar und wird durch die Anwendung realisiert.

Dies kann zum Beispiel eine Steckercodierung oder eine Speichercodierung in Flash sein.

24.2.5 Ressourcen sparen

Ein Steuergerät, das mehrere Varianten beinhaltet, reduziert die Anzahl der physikalischen Steuergeräte, welche entwickelt,

hergestellt und gelagert werden müssen. Da nun mehrere Varianten im verwendeten Steuergerät abgelegt werden, steigt dort

entsprechend der Ressourcenbedarf.

Bei der Code-Generierung der MICROSAR-BSW wird durch eine Reihe von Optimierungsmöglichkeiten auf eine möglichst effi-

ziente Speicherverwendung im RAM und ROM besonderen Wert gelegt.

24.2.6 Lieferumfang "Post-Build Selectable"

> Lizenz für die Freischaltung im Konfigurations-Werkzeug

> BSW-Module mit Identity Manager Funktionalität

> Dokumentation

MICROSAR

93

25 MICROSAR J1939 – AUTOSAR Basissoftware-Module speziell für Nutzfahrzeuge

In diesem Kapitel stellen wir Ihnen die in der AUTOSAR-Architektur definierten BSW-Module für die Kommunikation in J1939-

Netzen vor: Den Netzwerkmanager J1939Nm, den Request Manager J1939Rm und das Transportprotokoll J1939Tp, sowie das

Diagnosemodul J1939Dcm. Diese Module sind Teil von MICROSAR.CAN und MICROSAR.DIAG.

Bild 54: Die MICROSAR J1939 Module nach AUTOSAR 4.3

25.1 Die Vorteile der J1939-spezifischen MICROSAR Module im Überblick

> Für AUTOSAR 4.x erhältlich.

> J1939Nm: Adress-Arbitrierung und Kommunikations-Kontrolle nach SAE J1939-81. Optional erhältlich ist die Unterstüt-

zung der voll-dynamischen Adressierung und Adressüberwachung für selbstkonfigurierende Steuergeräte.

> J1939Nm kann gemeinsam mit CANNM eingesetzt werden, um Adress-Arbitrierung und Sleep/Wakeup zu kombinieren.

> J1939Rm: Direkte Anbindung an die Module J1939Nm, J1939Dcm, Com und Rte sowie Cdds. Voller Zugriff auf Request

mit Timeout-Überwachung und Acknowledgement (SAE J1939-21).

> J1939Tp:

> Vollständige Implementierung des J1939-Transportprotokolls nach SAE J1939-81 mit den Varianten BAM und CMDT

(RTS/CTS), erweitert um die Unterstützung für das erweiterte Transportprotokoll nach ISO 11783-3 (ETP) und das

FastPacket Transportprotokoll gemäß NMEA2000.

> Automatische Auswahl des richtigen Transportprotokolls (direkt, BAM, CMDT, ETP) anhand der Botschaftsgröße und

der Zieladresse, Empfang von Botschaften über beliebige Transportprotokolle.

> J1939Tp (BAM und CMDT) auch für AUTOSAR 3.x.

> J1939Dcm: Diagnosemodul für die Nutzfahrzeug-Diagnose gemäß SAE J1939-73. Voll integrierte Lösung mit gemeinsa-

mer Nutzung der gespeicherten Diagnosedaten des Dem über J1939- und UDS-Diagnose.

> Routing von Botschaften basierend auf ihrer PGN, unabhängig von Quell- und Zieladressen, auch direkt aufeinander fol-

gender Botschaften

> Zugriff auf Botschafts-Adressen in Cdds

MICROSAR

94

> Code- und Laufzeit-optimiert durch bedarfsspezifische Konfiguration.

> Modulübergreifende Konfiguration aller kommunikationsspezifischen Softwaremodule.


Das Einsatzgebiet der J1939-Module ist die Abwicklung der Kommunikation in Nutzfahrzeugen über CAN-Netzwerke mit den

im SAE J1939-Standard definierten Besonderheiten. Diese sind in den J1939-spezifischen BSW-Modulen umgesetzt und wer-

den durch Erweiterungen in benachbarten Modulen unterstützt. Darüber hinaus kann MICROSAR.CAN auch zur Implementie-

rung von ISOBUS-Steuergeräten (gemäß ISO 11783) in landwirtschaftlichen Nutzfahrzeugen und Gerätschaften verwendet

werden. Hierfür wurden J1939Nm und CanIf um Funktionalitäten zur volldynamischen Adressarbitrierung und Adressverfol-

gung erweitert und im J1939Tp zusätzlich die Transportprotokolle ETP und FastPacket implementiert. Auch maritime Anwen-

dungen gemäß NMEA2000 können dank FastPacket und volldynamischer Adress-Arbitrierung unterstützt werden.


Die BSW-Module für J1939 enthalten die in AUTOSAR 4.x definierten Funktionen, insbesondere:

>

Adress-Arbitrierung gemäß SAE J1939-81 für J1939-Netzwerke mit unveränderlichen Adressen

Optionen

> Erweiterung um voll-dynamische Adressierung, mit automatischer Änderung der eigenen Adresse im Konfliktfall und

automatischer Anpassung aller verwendeten Adressen an aktuelle Änderungen

>

Unterstützung der Anfrage/Antwortprotokolls (Request, Acknowledgement) gemäß SAE J1939-21

>

J1939-Transport-Layer mit Unterstützung für Broadcast- (BAM) und gerichtete Kommunikation (CMDT bzw. RTS/CTS)

gemäß SAE J1939-21

Optionen

> Erweiterung um die Transport-Protokolle ETP (nach ISO11783-3 bzw. -7) und FastPacket (nach NMEA200)

>

Unterstützung der wichtigsten Diagnose-Botschaften aus SAE J1939-73, Parallel-Betrieb mit DCM





25.4 Konfiguration


Produktinformation.

25.5 Weitere relevante MICROSAR Produkte für J1939

> Dem aus MICROSAR.DIAG

> Det, BswM, EcuM und ComM aus MICROSAR.SYS


wendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für CAN-Steuergeräte enthält MICRO-

SAR XCP die passende Transportschicht CanXcp.

Über den AUTOSAR-Standard hinaus unterstützt MICROSAR XCP das generische Auslesen von Messobjekten. In der


MICROSAR

95









stattet.

MICROSAR

96

26 MICROSAR vVIRTUAL Target – Virtuelle Integration mit vVIRTUALtarget

Die Entwicklung eines Steuergerätes beginnt typischerweise mit der Erstellung einzelner Software-Module (SWC). Infolge im-

mer kürzer werdender Projektzeiten steht jedoch in der Regel nicht die notwendige Zeit zur Verfügung, um zuerst alle notwen-

digen SWCs zu erstellen und diese dann für sich alleine, in der Interaktion untereinander und am Ende auch im Zusammenspiel

mit der Basissoftware auf der Ziel-Hardware zu testen.

Zahlreiche Projekte stellen sich heute so dar, dass bereits in einer sehr frühen Projektphase mit Testläufen begonnen werden

muss, teilweise in einer Phase, in der die spätere Ziel-Hardware noch nicht final definiert worden ist.

Bild 55: Klassischer Steuergeräte-Entwicklungsprozess

Für diese Situation bietet vVIRTUALtarget die passende Lösung. vVIRTUALtarget stellt eine Laufzeitumgebung bereit, in der

Steuergeräte-Software ausgeführt werden kann, ohne auf ein reales Steuergerät angewiesen zu sein. Mit Hilfe dieser Umge-

bung lässt sich der Testablauf von der realen Hardware und auch vom Vorhandensein der Basissoftware entkoppeln und ein

erheblicher Zeitgewinn realisieren. Dabei kann dieselbe Konfiguration sowohl auf der Ziel-Hardware als auch in der Umgebung

von vVIRTUALtarget verwendet werden:

Bild 56: Steuergeräte-Entwicklungsprozess mit vVIRTUALtarget

Die Steuergeräte-Software und deren Bedatung sind nach der Entwicklung der SWCs und deren System-Integration in einem

fortgeschrittenen Stadium. Neben der Applikation wird nun auch die Konfiguration der Basissoftware konkreter betrachtet.

Hier bietet vVIRTUALtarget die Möglichkeit, unabhängig von der Zielplattform zu testen.

MICROSAR

97

Bild 57: Der Anwendungsbereich von vVIRTUALtarget (Version vVIRTUALtarget pro derzeit in Entwicklung)

26.1 Die Vorteile von vVIRTUALtarget im Überblick

> Frühe Integration und Tests von AUTOSAR 4 Softwaremodulen

> Entwicklung der Steuergeräte-Software unabhängig von der Verfügbarkeit der realen Ziel-Hardware

> Dual-Target Option für die parallele Integration auf virtueller und realer Hardware

> Höhere Testtiefe durch zusätzliches Testen in der virtuellen Umgebung

> Einsatz von Microsoft Visual Studio als komfortable Entwicklungs- und Debugging-Umgebung

> Keine Änderung des Workflows in Steuergeräte-Entwicklung durch den Einsatz von vVIRTUALtarget basic

> Verbesserte Simulation von Unterbrechungen durch Interrupts und Task-Preemption

> Simulation von Multi-core Systemen


MICROSAR vVIRTUALtarget kann in vielfältigen Anwendungsgebieten eingesetzt werden, wie beispielsweise:

> Beschleunigung der Steuergeräte-Integration

> Erweiterung der Testlandschaft um Integrations- und Systemtests in einer virtuellen Umgebung

> Evaluierungsplattform für Demonstrationszwecke oder Prototyping

26.3 Funktionen

vVIRTUALtarget basic ist für die Steuergeräte-Integration vorgesehen und ermöglicht den Test des kompletten Stacks (Appli-

kation, SWCs, RTE und BSW) in einer virtuellen Umgebung. Es bietet dabei folgende Funktionen:

> Frühzeitiger Test des kompletten Stacks, auch wenn das reale Steuergerät noch nicht verfügbar ist

> Verwenden derselben MICROSAR-Konfiguration sowohl auf der Ziel-Hardware als auch in der virtuellen Umgebung

> Komfortableres Testen der Steuergeräte-Software in der virtuellen Umgebung

> Unterstützung von AUTOSAR-konformen 3rd Party Modulen

MICROSAR

98

26.3.1 vVIRTUALtarget im Verbund mit CANoe

Das Tool vVIRTUALtarget basic erzeugt basierend auf der aktuellen MICROSAR-Konfiguration ein Visual Studio Projekt, in dem

aus den BSW-Modulen und der Applikation automatisch eine "System under Test" Windows-DLL (SUT DLL) erstellt werden

kann. Derzeit werden Microsoft Visual Studio 2013 (Express & Professional) und 2017 (Community & Professional) unterstützt.

Bild 58: Das Dual-Target-Prinzip

Als Laufzeitumgebung wird CANoe eingesetzt. Die erzeugte DLL wird dabei im Steuergeräte-Knoten in der CANoe-Konfigu-

ration referenziert. Ein Debugging des virtuellen Steuergeräts ist über das Visual Studio Projekt möglich. Für die Stimulation

über die Busse und IO-Schnittstellen können jegliche Funktionen von CANoe verwendet werden, insbesondere ein gleichzeitiger

Betrieb mit realen Steuergeräten wird unterstützt.

Für die Simulation und Messung von Kommunikation und I/O Interfaces wird eine CANoe Lizenz benötigt.

26.3.2 vVIRTUALtarget im Verbund mit MICROSAR.MCAL und MICROSAR.OS

Für den Einsatz von vVIRTUALtarget wurden die BSW-Module MICROSAR.MCAL und das MICROSAR.OS portiert. Dabei ent-

sprechen die MCAL-Schnittstellen und das Verhalten den Spezifikationen nach AUTOSAR 4. Das für vVIRTUALtarget erhältli-

che MICROSAR.OS implementiert die „Scalability Class“ SC2 mit Multi-core-Erweiterungen.

Die übrigen BSW-Module benötigen keine Anpassung, um in der Umgebung von vVIRTUALtarget ausgeführt zu werden. Hierbei

handelt es sich um dieselben BSW-Module, die auch im realen Steuergerät zum Einsatz kommen.

26.4 Workflow

Der Workflow zur Konfiguration der BSW-Module im Umfeld von vVIRTUALtarget unterscheidet sich nicht vom Vorgehen bei

einer realen Hardware-Plattform. Lediglich die für vVIRTUALtarget spezifischen MCAL-Module und das vVIRTUALtarget OS

benötigen gegebenenfalls besondere Einstellungen, sofern Sie durch das Konfigurationstool DaVinci Configurator Pro nicht

automatisch abgeleitet werden können.

MICROSAR

99

Bild 59: Der MICROSAR-Workflow erweitert um den Workflow von vVIRTUALtarget

26.5 Konfiguration


Produktinformation. Für die Generierung der vVIRTUALtarget spezifischen Initialisierungscodes und einer Visual Studio Lösung

ist die vVIRTUALtarget basic Lizenz erforderlich.

26.6 Lieferumfang

Die Module von vVIRTUALtarget werden als Software Integration Package (SIP) geliefert. Hierbei kann wahlweise das SIP nur

für die vVIRTUALtarget Plattform geliefert werden (nur vVIRTUALtarget MCAL und OS), oder die Lieferung erfolgt als Dual-

Target SIP in Verbindung mit Treibern für eine vom Kunden definierte reale Hardware-Plattform (realer MCAL und OS, als

auch vVIRTUALtarget MCAL und OS).

26.7 Systemvoraussetzungen

Unser Produkt vVIRTUALtarget ist eine 64-Bit Anwendung und setzt dementsprechend ein 64-Bit Microsoft Windows voraus.

26.8 Weitere relevante MICROSAR Produkte für VTT

Zum Kennenlernen der virtuellen Integration und Erprobung ihrer Funktionsweise ist das Evaluierungspaket "AUTOSAR Evalu-

ation Bundle VTT" erhältlich. Nähere Informationen erhalten Sie im Kapitel "AUTOSAR Evaluierungspaket“.

MICROSAR

100

27 MICROSAR POSIX – Anbindung von AUTOSAR Classic an POSIX-Betriebssysteme

Fahrer-Assistenzsysteme und Infotainment führen zu einer immer stärkeren Verzahnung der etablierten statischen Steuerge-

räte-Lösungen mit neuen, dynamischen Diensten. Aus diesem Grund befinden sich in Steuergeräte-Projekten immer häufiger

POSIX-basierte Systeme in Kombination mit klassischer AUTOSAR-Technologie. Der neu definierte Standard „AUTOSAR

Adaptive Platform“ unterstreicht diesen Trend. MICROSAR bietet daher Lösungen an, um klassische AUTOSAR-Funktionen

auch unter einem POSIX-Betriebssystem zu nutzen oder um Daten zwischen einer POSIX- und einer AUTOSAR-Domäne aus-

zutauschen.

Bild 60: Typische Arbeitsgebiete bei POSIX-basierten Steuergeräten

27.1 Die Vorteile im Überblick

> Betrieb der MICROSAR Basissoftware als Prozess in einem POSIX-basierten System

> Unterstützung von multi-Controller Architekturen

> Integration der MICROSAR Basissoftware mit POSIX-basierten Drittanbieter-Betriebssystemen


> AUTOSAR Classic Basissoftware-Module und Legacy-Komponenten als Prozess unter POSIX

> Diagnose in Multi-Controller und Multi-core Architekturen

> Inter Process Communication (IPC) für den Datenaustausch zwischen verschiedenen Betriebssystemen

> Flash Bootloader für POSIX-Betriebssysteme

> Steuergeräte nach dem neuen Standard „AUTOSAR Adaptive Platform“. Vector bietet hierzu eine umfassende Lösung

an. Detaillierte Informationen hierzu finden Sie in der separaten Produktinformation.

27.2.1 AUTOSAR Classic Basissoftware-Module und Legacy-Komponenten als Prozess unter POSIX

POSIX-Betriebssysteme stellen üblicherweise für die typischen Bussysteme im Fahrzeugbau, Ethernet und CAN, eigene Treiber

zur Verfügung. Zur Anbindung an ein Bordnetz fehlen jedoch die notwendigen höheren Protokollschichten. Ein häufig vorkom-

mendes Anwendungsbeispiel ist die Diagnoseanbindung über DoIP. Hier ist es von Vorteil, wenn bestehende Implementierungen

übernommen werden können.

MICROSAR

101

Bild 61: AUTOSAR als Prozess in einem POSIX-basierten System

Für diesen Anwendungsfall sind zu den relevanten MICROSAR-Modulen die erforderlichen Schnittstellenmodule verfügbar, um

diese in einem POSIX-System anzubinden. Alle übrigen Module bleiben unverändert, ebenso die dazugehörigen Konfigurations-

werkzeuge. In der Folge reduziert sich die erforderliche Umstellung beziehungsweise Einarbeitung in diesen Anwendungsfall

auf ein Minimum. Gleichzeitig wird durch die Nutzung der freigegebenen Komponenten auch die Buskompatibilität des POSIX-

Steuergeräts sichergestellt.

27.2.1.1 Laufzeitumgebung

Die Handhabung einer POSIX-Umgebung mit AUTOSAR Basissoftware ist unkompliziert, sofern ein AUTOSAR OS als Lauf-

zeitumgebung bereitsteht. Für Basissoftware-Module, die lediglich einen Aufruf ihrer „Main Function“ benötigen, genügt es

jedoch bereits, einen pThread des POSIX OS entsprechend einzurichten. Einige Komponenten, beispielsweise die RTE, haben

dagegen eine stärkere Kopplung zum AUTOSAR-Betriebssystem, die sich nur schwer ersetzen lässt.

MICROSAR bietet hierfür die Betriebssystem-Variante „Guest OS“, welche als Prozess unter Linux eingebunden werden kann

und so den Basissoftwaremodulen eine AUTOSAR-Laufzeitumgebung bietet. Es werden alle Mechanismen unterstützt, von

Alarmen bis zu ScheduleTables. Da das Betriebssystem nur in dem von Linux bereitgestellten Zeitfenster agieren kann, ist

jedoch das Echtzeitverhalten eingeschränkt.

Bei der Verwendung von Green Hills INTEGRITY ist der Einsatz von MICROSAR Guest OS nicht notwendig, da vom Hersteller

eine Schnittstelle zum AUTOSAR OS angeboten wird.

27.2.1.2 Treiber Schnittstellen

Für Ethernet bietet Linux native Treiber und einen TCP/IP Stack an. Diese reichen für eine reine Datenübertragung und Diag-

noseverbindung (DoIP) aus. Der MICROSAR Protokoll-Stack setzt hierbei auf BSD Sockets auf. Wird darüber hinaus auch die

Service-Qualifizierung (QoS) oder eine Zeitsynchronisation (TSyn) benötigt, ist eine Anbindung an Hardware-nähere Kompo-

nenten des Kernels notwendig.

Ebenfalls erhältlich ist ein SocketCAN-Treiber für CAN-Kommunikation über Linux.

Unter Green Hills INTEGRITY werden die MICROSAR Treiber eingesetzt, welche hierzu an die Schnittstellen des Betriebssystem

Kernels angepasst werden.

MICROSAR

102

27.2.2 Verteilte Diagnose

MICROSAR bietet OEM-spezifische Diagnosemodule und Workflows für alle Fahrzeughersteller. Mit der MICROSAR POSIX

Lösung können diese Module auch unter POSIX-Betriebssystemen eingesetzt werden.

In Steuergeräten mit einer POSIX-basierten Anwendung findet man häufig eine aus zwei Controllern bestehende Architektur.

Beide stellen Daten und Dienste zur Diagnose bereit, der Tester sieht aber nur das Steuergerät als Ganzes. Meistens bietet der

POSIX-Controller die Diagnoseschnittstelle zum Tester und leitet die Diagnosebotschaften an den zweiten Controller oder

Kern weiter. Dieser zweite Controller enthält ein klassisches AUTOSAR-System inklusive des Diagnose Masters. Beide Systeme

werden um das Modul Diagnostic Event Synchronizer (vDes) erweitert. vDes sammelt die lokalen Diagnoseevents ein und leitet

sie an den DEM Master weiter. Dabei werden nur qualifizierte Diagnose-Events weitergeleitet, um die inter-Controller Kom-

munikation auf das minimal notwendige Maß zu reduzieren.

Bild 62: Verteilte Diagnose in einem POSIX-System

27.2.3 Inter Process Communication (IPC) für den Datenaustausch zwischen verschiedenen Betriebssystemen

In einem Steuergerät mit zwei Controllern, Kernen oder einem komplexeren SoC (System-on-a-chip), auf denen unterschiedli-

che Betriebssysteme laufen, fehlt ein systeminterner Mechanismus zur Übertragung von Daten. Um die zusätzlichen Kosten

für den Einsatz von Bussystemen wie CAN oder Ethernet zu vermeiden, bietet MICROSAR hierzu eine IPC-Lösung an. Diese

überträgt die anfallenden Daten über eine serielle Schnittstelle wie SPI oder UART mittels des CAN Protokoll Stacks. Bei Multi-

core Architekturen findet die Übertragung über Shared Memory statt.

Der Ansatz, eine CAN-Übertragung zu imitieren, hat den Vorteil, dass die vorhandenen Konfigurationswerkzeuge und –verfah-

ren genutzt werden können. Das Weiterleiten bestehender PDUs wird damit stark vereinfacht.

Die IPC-Lösung setzt eine AUTOSAR-Laufzeitumgebung und einen CAN Protokoll-Stack voraus. Diese Module werden ergänzt

um das IPC-spezifische Interface sowie die notwendigen Hardware Treiber.

27.2.4 Flash Bootloader für POSIX-Betriebssysteme

Der bewährte Vector Flash Bootloader für AUTOSAR-konforme Steuergeräte steht mit entsprechenden Erweiterungen auch

für POSIX-kompatible Betriebssysteme wie Linux zur Verfügung. Die Kommunikation mit dem Flash-Werkzeug erfolgt über

Ethernet gemäß ISO 13400-2 (DoIP) und berücksichtigt dabei OEM-spezifische Download-Spezifikationen.

Der Flash Bootloader basiert auf der Linux-Laufzeitumgebung und bietet neben einem adressbasierten auch einen dateiba-

sierten Software-Download. Dadurch lassen sich sehr effizient auch einzelne Softwareanteile während der Entwicklung, in der

Produktion und im Fahrzeugservice aktualisieren. Die zusätzlich erhältlichen Security-Optionen schützen dabei wirkungsvoll

Steuergeräte mit sensitiven Fahrzeugdaten.

Der Vector Flash Bootloader ist für alle gängigen Fahrzeughersteller und Embedded-Linux-Systeme im Automotive-Umfeld

verfügbar. Bei Bedarf kann die Basissoftware für weitere POSIX-kompatible Betriebssysteme eingesetzt werden.

Weitere Details zum Vector Flash Bootloader finden sie in der separaten Produktinformation.

MICROSAR

103

27.3 Konfiguration


Produktinformation.

MICROSAR

104

28 MICROSAR.OTA – Basissoftware-Module für den Software-Download

Das Paket MICROSAR.OTA enthält BSW-Module zur Verarbeitung, Speicherung und Aktivierung von Softwareupdates für Ihr

Fahrzeug. OTA steht für „Over the Air“. Mit unseren flexibel konfigurierbaren Modulen lassen sich verschiedene Strategien zur

Aktualisierung der Software auf dem Steuergerät realisieren. Der Softwaredownload und das anschließende Update können

mit Hilfe der Module aus MICROSAR.CRYPTO abgesichert werden.

Bild 63: Das MICROSAR.OTA Modul

28.1 Die Vorteile von MICROSAR.OTA im Überblick

> Für AUTOSAR 4.x erhältlich

> Effizientes und konfigurierbares Management der updatefähigen Softwarebereiche im nichtflüchtigen Speicher

> Effiziente Datenzugriffe

> Optimiertes Zusammenspiel von MICROSAR.MEM und MICROSAR.OTA bei paralleler Verwendung des internen Spei-

chers des Steuergeräts

> Effiziente Umschaltung zwischen altem und neuem Softwarestand durch Ausnutzung von Hardwareunterstützung (so-

fern verfügbar)

> Wahlweise wird interner oder externer Flash unterstützt

> Integrierte Lösung mit der Vector Flash Bootloader Lösung (CANfbl), welche den Softwarestand beim nächsten Neu-

start aktualisiert


MICROSAR.OTA enthält Dienste zum Initialisieren, Schreiben und Aktivieren von Softwareupdates in Flash-Speichern. Die an-

gebotenen Dienste arbeiten dabei nicht direkt auf den physikalischen Speicheradressen der verfügbaren (internen und/oder

externen) Speicherbausteine, sondern auf Softwareregionen, die die physikalischen Gegebenheiten abstrahieren und die Ver-

waltung von Softwareupdates wesentlich vereinfachen.

OEM-Lösungen für OTA-Updates unterscheiden sich meist durch die Paketformate und die Protokolle, welche die Updates

steuern. MICROSAR.OTA bietet OEM-Erweiterungen an, die die OEM-spezifischen Anforderungen umsetzen.

MICROSAR

105

28.3 Vector Module als Erweiterung des AUTOSAR Standards

Die BSW-Module in MICROSAR.OTA sind nicht in AUTOSAR spezifiziert.

>

vOtaDl enthält alle hardwareunabhängigen Anteile für den Softwaredownload. Im Wesentlichen werden Dienste für das

Initialisieren, Schreiben, (Übertragen) und Aktivieren von Softwareudates zur Verfügung gestellt. Für die Umsetzung

dieser Dienste sind folgende Funktionalitäten implementiert:

> Zugriffssteuerung bei gleichzeitiger Verwendung des Flash-Speichers von mehreren Benutzern (MICROSAR.MEM und

MICROSAR.OTA)

> Gepuffertes Datenhandling und Weiterleitung an den Speichertreiber

> Datenkompression und Datenvalidierung

> Zustandsverwaltung

> Konfigurierbare Speicherabstraktion von physischen Adressen auf virtuelle Adressen bzw. Softwareregionen

Für OEM-spezifische Lösung bietet vOtaDl zusätzliche Funktionen an.

28.4 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Dieser enthält arbeitserleichternde Funk-

tionen wie Optimierungshilfen, optische Darstellung der Flash-Auslastung usw. Mehr Details finden Sie in der Produktinforma-

tion zum DaVinci Configurator Pro.

28.5 Weitere relevante MICROSAR Produkte für Ihren Memory-Stack

MICROSAR OTA benötigt weitere Module aus den folgenden Paketen:

>

Bei Verwendung des internen Flash-Speichers wird ein für Ihre Hardware geeigneter OTA Flash Treiber (vMem) benötigt.

vMem bietet Zugriff auf Speicherbausteine wie z.B. Flash. Im Gegensatz zu AUTOSAR Fls erlaubt vMem den Zugriff auf

Daten- und Programmflash, abhängig vom Gerät und der Treiberfähigkeit. vMem ist dafür gedacht, zusammen mit

MICROSAR Modulen der höheren Schichten verwendet zu werden, die das optimierte vMem API unterstützen.

>

Bei Verwendung eines externen Flash-Speichers wird ein für Ihre Hardware geeigneten externen OTA Flash Treiber

(vMem Ext) aus MICROSAR.EXT benötigt.

>

Für weitere Funktionalitäten wie Checksummenberechnung und kryptografische Algorithmen sind die Pakete MICRO-

SAR.LIBS und MICROSAR.CRYPTO relevant.

>

Für das Umschalten zwischen alten und neuen Softwareständen wird der Vector Flash Bootloader mit dem Add-On OTA

Manager benötigt.

Bei der alleinigen Verwendung des internen Flash-Speichers ist in der Regel darauf zu achten, dass der Flash-Speicher eine

Partitionierung des Speichers anbietet, wobei gleichzeitig in einer Partition gelesen und in einer anderen Partition geschrieben

werden kann (Read-While-Write). Dadurch lassen sich im Hintergrund Softwareupdates in den Flash-Speicher schreiben, wäh-

rend die Applikation auf dem Steuergerät ohne Beeinträchtigung weiterläuft.

MICROSAR

106

29 MICROSAR.IPC – AUTOSAR Basissoftware-module für Interprozessorkommunikation

Für komplexe Steuergeräteprojekte, die mehrere Mikrocontroller- und/oder mehrere Betriebssysteme vereinen, stellt sich meist

auch die Frage, wie zwischen diesen verschiedenen Systemen kommuniziert werden kann.

Sofern die im Automotive-Umfeld typischen Feldbusse wie CAN oder Ethernet zur Verfügung stehen und von der benötigten

Bandbreite ausreichend sind, kann die Kommunikation darüber erfolgen.

Sind diese Bedingungen nicht erfüllt, bieten sich alternative Übertragungsmedien an. Diese sind in der Regel projektspezifisch

und reichen von gemeinsamem Speicher (RAM) über SPI bis UART und anderen seriellen Schnittstellen.

Neben dem reinen Übertragen der Daten über ein geeignetes Medium ergibt sich des Weiteren die Frage, wie die Daten in den

jeweiligen Kommunikationsendpunkten zwischen Kommunikations-Stack und Applikationssoftware ausgetauscht werden kön-

nen.

Das Paket MICROSAR.IPC wurde genau für solche Fälle entwickelt. Es bietet alle nötigen Softwaremodule für eine Kommuni-

kation zwischen zwei und mehr Prozessoren bzw. Kernen eines Mikrocontrollers. MICROSAR.IPC ist flexibel gestaltet und er-

laubt dadurch nahezu beliebige Übertragungsmedien.

Darüber hinaus integriert sich MICROSAR.IPC optimal in die typischen Systeme wie AUTOSAR (Adaptive und Classic) und

POSIX. MICROSAR.IPC bietet sowohl die entsprechenden Schnittstellenkomponenten als auch die Tool-Unterstützung für die

Beschreibung der Kommunikation auf Signal-, PDU- und Service-Ebene.

29.1 Die Vorteile von MICROSAR.IPC

> Kommunikationsendpunkte für unterschiedlicher Systeme

> AUTOSAR (Classic und Adaptive)

> Linux

> Weitere POSIX Betriebssysteme

> Unterstützung unterschiedlicher Kommunikationstypen

> Serviceorientierte Kommunikation

> Signalbasierte Kommunikation

MICROSAR

107

> Übertragung von Rohdaten

> Botschafts- und Signalgateway

> Unterstützung unterschiedlicher Übertragungsmedien

> Shared Memory

> SPI (auf Anfrage)

> Tool-gestützte, flexible Konfiguration


MICROSAR.IPC ermöglicht die Kommunikation zwischen den Prozessen zweier Betriebssysteminstanzen. Diese können auf

unterschiedlichen Mikrocontrollern oder Kernen eines „System on Chip“ (SoC) laufen. Dadurch werden Anwendungen ermög-

licht, wie zum Beispiel:

> Bereitstellen von Daten der fahrzeuginternen Bussysteme auf nicht-AUTOSAR Mikrocontrollern:

> Controller A: AUTOSAR Kommunikation mit geringer Latenz- und kurzer Startzeit

> Controller B: Network Attached Device (NAD) für die Backbone- / Cloud Anbindung

> Mixed AUTOSAR Steuergeräte mit AUTOSAR Classic und Adaptive Anwendungen

> Diagnose sowie Kalibrierung von Multi-Mikrocontroller Steuergeräten, bei denen nur einer der Controller direkt über die

fahrzeuginternen Bussysteme erreichbar ist.

µC / SoC µC / SoC

Physical channel

ECU ECU

OS / Process

OS / Process

Physical channel

Bild 64: Die zwei grundsätzlichen Anwendungsfälle von MICROSAR.IPC

29.3 Funktionen

MICROSAR.IPC bietet die folgenden Grundfunktionen:

> Bereitstellen mehrerer virtueller Kanäle (PDUs)

> Simultaner Betrieb von mehreren physikalischen Kanälen

> Multiplexen von mehreren, virtuellen Kanälen auf einen physikalischen Kanal

> Priorisierung der virtuellen Kanäle

> Segmentierung der Daten für

> Verbesserte Fairness bei der Übertragung auf Multiplex-Kanälen

MICROSAR

108

> Unterstützung von Übertragungsmedien mit limitierter Paketgröße

> Modulare Architektur


Erweiterungen zum AUTOSAR Standard

Sämtliche Module zur Interprozessorkommunikation sind nicht im AUTOSAR Standard enthalten und stellen Erweiterun-

gen von Vector dar.

>

vIpc ist das Kernstück der IPC Lösung. Es bietet:

> Konfigurierbare Segmentierung der Daten der virtuellen Kanäle

> Datenpriorisierung der virtuellen Kanäle

> Multiplexer für mehrere virtuelle auf einen physikalischen Kanal

>

vIpcIf ist das Übersetzungsmodul zwischen den statischen Schnittstellen von vIpc und den Betriebssystem- und Bussys-

temabhängen Schnittstellen des Treibers

>

vIpcDrv ist der betriebssystemabhängige Treiber für das verwendete Bussystem. Dabei kann es sich um einen Standard

Treiber handeln, der von der Basissoftware bzw. dem Betriebssystem bereitgestellt wird, oder um eine Eigenentwicklung

für den spezifischen Anwendungsfall. MICROSAR.IPC bietet aktuell Treiber für Shared Memory für die Betriebssysteme

AUTOSAR und Linux.

>

Übersetzungsmodul zwischen den Schnittstellen von vIpc und Netzwerk Sockets von POSIX sowie AUTOSAR Adaptive

Systemen.

Mit den hier beschriebenen Funktionen lassen sich die folgenden Kommunikationsszenarien abbilden.

MICROSAR

109

29.4.1 Signalbasierte Kommunikation

Die Daten werden durch die Basissoftware aufbereitet und in ihrer logischen Repräsentation der Applikation zur Verfügung

gestellt, bzw. von der Applikation entgegengenommen. Typisches Beispiel sind die Signale die der AUTOSAR Interaction Layer

bereitstellt. Die Basissoftware übernimmt dabei unter anderem die Konvertierung zwischen logischer Repräsentation und Re-

präsentation auf dem Übertragungsmedium.

29.4.2 Serviceorientierte Kommunikation

Events und Methoden werden gemäß dem SOME/IP Standard transformiert und serialisiert übertragen. Die Transformation

erfolgt endpunktspezifisch entweder durch die Basissoftware oder die Applikation.

29.4.3 Übertragung von Rohdaten

Die Daten werden direkt von der Applikation interpretiert und bereitgestellt. Die Basissoftware und MICROSAR.IPC übertragen

lediglich intransparente Datenblöcke. Eine Interpretation bzw. Vorverarbeitung wie beispielsweise die Konvertierung zwischen

logischer Repräsentation und Repräsentation auf dem Übertragungsmedium wird von der Applikation übernommen.

29.4.4 Systemservice Kommunikation

Über vIpc werden serialisierte Aufrufe von Systemservices übertragen. Diese werden beim empfangenden Endpunkt dekodiert

und ausgeführt. Typisches Beispiel dafür sind Funktionen, die sich auf die Fahrzeugdiagnose beziehen, aber auch die Steuerge-

rätekalibrierung via XCP.

MICROSAR

110

29.4.5 PDU basiertes Routing

Bei Systemen, deren Feldbusse unterschiedlichen Mikrocontrollern fest zugewiesen sind, müssen oft PDUs zwischen den Feld-

bussen geroutet werden. MICROSAR.IPC übernimmt dabei den Transport der PDUs zwischen Quell- und Zielendpunkt. Die

PDUs werden direkt von der Basissoftware entgegengenommen bzw. auf Empfängerseite in die Basissoftware eingespeist.

29.4.6 Signalbasiertes Routing

Dieser Anwendungsfall ist vergleichbar mit dem PDU basierten Routing. Allerdings werden beim signalbasierten Routing ein-

zelne Signale in PDUs verpackt und geroutet. Es wird dadurch möglich, maßgeschneidert nur die Signale zu übertragen, die

tatsächlich für den Empfänger relevant sind. Weiterhin ist es möglich, den Sendezeitpunkt bzw. die Sendehäufigkeit der Sig-

nale anzupassen. So kann zum Beispiel ein über einen Feldbus empfangenes Signal mit reduzierter Zykluszeit an den vIpc Zie-

lendpunkt weitergeleitet werden.

29.5 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Mehr Details finden Sie in der Produk-

tinformation zum DaVinci Configurator Pro.

Die Konfiguration der serviceorientierten Kommunikation erfolgt über die AUTOSAR Systembeschreibungen. Diese können bei-

spielsweise mit unserem Systemmodellierungswerkzeug PREEvision erzeugt werden.

29.6 Weitere relevante MICROSAR Produkte für IPC

Auf Endpunkten mit AUTOSAR Basissoftware ergänzt MICROSAR.COM mit seinen Modulen COM sowie SOMEIPXF MICRO-

SAR.IPC optimal. Das Modul COM ermöglicht die signalbasierte Kommunikation via MICROSAR.IPC. COM übernimmt dabei

die Transformation zwischen logischer Repräsentation und Darstellung auf dem Übertragungsmedium.

Analog dazu ermöglicht SOMEIPXF serviceorientierte Kommunikation. SOMEIPXF stellt Events und Methoden über definierte

Schnittstellen der Applikationssoftware bereit und übernimmt die Serialisierung sowie De-Serialisierung gemäß SOME/IP Pro-

tokoll.

MICROSAR

111

30 MICROSAR.SIP und MICROSAR.EIP – Der Schnelleinstieg in Ihr AUTOSAR Projekt

Das Software Integration Package (SIP) und das Extended Integration Package (EIP) von Vector verschaffen Ihnen den ent-

scheidenden Vorteil bei der Entwicklung Ihrer Steuergerätesoftware: wir testen Ihr Software-Paket vor der Lieferung und Sie

nehmen das gesamte Paket innerhalb weniger Tage in Betrieb.

30.1 Das Software Integration Package (SIP)

Das MICROSAR.SIP ist eine Standard-Lieferposition und stellt eine möglichst breite Verwendbarkeit Ihres Stacks in den Mit-

telpunkt. Es optimiert die Einsetzbarkeit Ihrer Lieferung auch bei einer leichten Abwandlung der Rahmenbedingungen:

> Prüfung der OEM-spezifischen Ausprägungen von BSW inklusive SWCs und der zugehörigen Werkzeugkette (z.B. Unter-

stützung der OEM-Datenformate für Kommunikation und Diagnose) und Sicherstellung der Konformität zu den vom

OEM geforderten Lastenheften.

> Prüfung der projektspezifischen Zusammenstellung der BSW-Komponenten und –Features für einen definierten Steuer-

geräte-UseCase.

> Prüfung des Paketes unter abstrakten Randbedingungen: Sowohl die Konfiguration als auch die initiale Datenbasis kann

sich im Verlauf Ihres Projektes noch verändern. In der Praxis tritt dies sogar sehr oft auf. Unser Ziel ist es, Ihr MICROSAR

Paket auf eine breite Basis zu stellen, so dass sich möglichst viele zusätzliche Varianten zur initialen Konfiguration und

Datenbasis abbilden lassen.

> Prüfung des Paketes unter projektnahen Randbedingungen (Mikrocontroller-Derivat, Compiler/Linker-Version und Com-

piler/Linker–Optionen). Hier betrachten wir Ihre konkreten Randbedingungen des Projekts möglichst nahe, damit die

Integration des Produkts bei Ihnen problemlos erfolgen kann. So wählen wir beispielsweise aus der Produkt-Familie des

von Ihnen gewählten Microcontrollers ein Evaluation Board mit geeignetem Derivat aus und testen hierauf das Soft-

ware-Paket. Ziel dabei ist, dass Ihre Lieferung später auf möglichst vielen Derivaten der gewählten Prozessorfamilie

lauffähig ist.

> Lieferspezifische Verwaltung der bestellten MICROSAR-Module in unserem Konfigurationsmanagement. Die Option auf

Nachlieferungen ist dadurch für die Dauer von 10 Jahren sichergestellt.

> Aktives Issue Reporting in regelmäßigen Abständen.

30.1.1 Das Anwendungsgebiet des SIP

Das MICROSAR.SIP ist fester Bestandteil jeder MICROSAR Lieferung, unabhängig davon, ob es sich um eine Prototypen-, Beta-

, Update- oder Serienlieferung handelt. Je nach dem Verwendungszweck des SIP ist hierbei das Leistungsspektrum an den

jeweiligen Kontext angepasst.

Mittels eines Fragebogens (Questionnaire) nehmen wir im Vorfeld der Lieferung Ihre Anforderungen möglichst detailliert auf

und stellen auf dieser Basis Ihr Software Integration Package individuell für Sie zusammen.

Über die SIP-Maintenance erhalten Sie beginnend mit der ersten Produktlieferung ein aktives Issue Tracking, welches Sie über

bekannt gewordene Fehler und mögliche Workarounds informiert. Weiterhin beinhaltet die SIP-Maintenance eine Update-SIP

Lieferung je Kalenderjahr, in der erweiterten Maintenance sogar zwei Update-SIP Lieferungen jährlich.

Mit dem Update-SIP helfen wir Ihnen aktiv, ein neues SIP und/oder eine neue Datenbasis in ihr Projekt einzuspielen und zu

testen.

MICROSAR

112

Bild 65: Das MICROSAR Software Integration Package und seine optionalen Zusatzleistungen

30.1.2 Optionale Erweiterungen zum SIP

Die Erweiterung "Start Application" ist eine Inklusiv-Leistung zum MICROSAR SIP, sofern sie für das Projekt des Kunden

technisch umsetzbar ist. Die Lieferung beinhaltet in diesem Fall eine Start Applikation basierend auf den Steuergeräte-spezi-

fischen Eingangsdaten bezüglich Kommunikation (z.B. den ECU-Extract) und Diagnose (z.B. ECUC). Die Start Applikation

demonstriert die grundsätzliche SIP-Funktionalität basierend auf den bestellten Modulen. Dies sind beispielweise:

> Kommunikation: Die in der Start Applikation beinhalteten SWCs demonstrieren den Empfang und das Senden eines

Signals auf Ebene der runnables. Die BSW wird so konfiguriert, dass das System initialisiert wird und auf allen in den

Eingangsdaten beschriebenen Bus-Systemen kommuniziert.

> Diagnose: Die in der Start Applikation beinhalteten SWCs werden erweitert um eine beispielhafte Implementierung

eines RDBI/WDBI Dienstes auf runnable Ebene. Darüber hinaus bietet sie die Möglichkeit, einen Diagnostic Trouble

Code (DTC) auszulösen.

> Memory: Die in der Start Applikation beinhalteten SWCs werden um eine beispielhafte Implementierung erweitert die

es erlaubt, Daten in einen NV-Block zu schreiben.

Für die Ausführung dieser Teilpunkte ist Voraussetzung, dass die dazu erforderlichen MICROSAR Module in der Lieferung ent-

halten sind. Weitere Details hierzu entnehmen Sie bitte der technischen Produktbeschreibung zu MICROSAR.

Zu der Basisleistung des SIP sind darüberhinausgehend folgende erweiterte Dienstleistungen erhältlich:

Vom Fahrzeughersteller unabhängige Erweiterungen ermöglichen Ihnen einen einfachen Start durch die Umsetzung wesentli-

cher Aufgaben durch unser Integrations-Team schon vor der Auslieferung Ihres MICROSAR Stacks an Sie:

> Erweiterung "Customer Hardware":

> Herstellen der Betriebsbereitschaft des Steuergeräts inklusive CPU clock, PLL und internem Watchdog

> Konfiguration des Netzwerk-Transceivers

> Ausführen der von Vector üblichen Auslieferungstest auf der realen Kunden-Hardware

Vom Fahrzeughersteller abhängige Erweiterungen erfordern eine enge Zusammenarbeit zwischen Ihnen und unserem Team

und behandeln erweiterte Steuergeräte-Abhängigkeiten wie beispielsweise:

> OEM-Application: Einbezug spezieller vom Fahrzeughersteller entwickelter Module zur Ergänzung der AUTOSAR-Basis-

software

> OEM-Test: Ausführung besonderer Tests unter Einbezug der OEM-Module und Erzeugen aller Test-Reports

Welche Optionen in diesem Umfeld für Ihren Fahrzeughersteller verfügbar sind, entnehmen Sie bitte der OEM-spezifischen

Produktinformation, die Ihnen gemeinsam mit unserem Angebot automatisch zur Verfügung gestellt wird.

MICROSAR

113

30.2 Das Extended Integration Package (EIP)

Aufbauend auf dem MICROSAR.SIP in Verbindung mit erweiternden SIP-Erweiterungen [siehe oben] unterstützt das MICRO-

SAR.EIP den weiteren Verlauf einer Initial-Lieferung. Es bietet eine maßgebliche Supportleistung zur schnellen und umfassen-

den Inbetriebnahme. Sie hat das Ziel, den ersten Vernetzungstest beim OEM zu bestehen.

Mitarbeiter von Vector übernehmen dabei die Vorbereitungen, welche im Standardfall vor Ort beim Kunden ablaufen. Diese

Dienstleistung erbringen wir zum Festpreis und im Rahmen einer mit Ihnen detailliert vereinbarten Aufgabenplanung:

> Aufsetzen einer Startapplikation auf Ihrem Steuergerät mit einer Lastenheft-konformen Konfiguration und unter Ver-

wendung der für das Projekt relevanten Datenbasen (Kommunikation und Diagnose).

> Zusätzliche Projektmanagement-Arbeiten wie die Abstimmung über Regelabsprachen und Projektprotokollierung

> Erstellen einer auf Sie zugeschnittenen Release-Planung

> Am Ende des Leistungspaketes aus dem EIP steht die gemeinsame Inbetriebnahme bei Ihnen vor Ort

> Durchführung der vom OEM geforderten und die BSW betreffenden Testfälle

Das Ergebnis dieser vorbereitenden Tätigkeiten ist dann auch Bestandteil der Lieferung:

> Ihr Basissoftware-Paket inklusive konfigurierter Start-Applikation

> Release Notes

> Verfassen der entsprechenden Test-Reports

Bild 66: Das Extended Integration Package im Zusammenspiel mit den SIP-Optionen

30.2.1 Das Anwendungsgebiet des EIP

Das MICROSAR.EIP stellt eine erweiterte Dienstleistung dar mit dem Ziel, sehr kurzfristig nach der Auslieferung eine Muster-

vorlage für den ersten Vernetzungstest beim OEM verfügbar zu haben. Das EIP ist daher eine Option, welche insbesondere bei

MICROSAR

114

Erstprojekten im AUTOSAR-Umfeld von Interesse sein kann, sowie beim Vorliegen von besonderen Projektbedingungen im Rah-

men der Initial-Lieferung:

> Sie bearbeiten ihr erstes Projekt im AUTOSAR-Umfeld und wünschen eine erweiterte Unterstützung

> Sie kennen den OEM bislang nicht und möchten daher die Erfahrung von Vector nutzen

> Sie sollen Zusatzleistungen (z.B. OEM-spezifische Komponenten oder 3rd-party Module) mit einbeziehen

> Wenn ein Testnachweis unter genau Ihren Randbedingungen (Steuergerät, Konfiguration) notwendig ist

Das MICROSAR.EIP wird für ausgewählte OEM angeboten. Unser Service-Team erläutert Ihnen bei Interesse an dieser Ser-

viceleistung gerne, ob und wie weit der für Ihr Projekt relevante Hersteller unterstützt werden kann.

Auch beim EIP nehmen wir mittels eines Fragebogens Ihre Anforderungen möglichst detailliert auf. Diese dienen dann als kon-

krete Basis für alle weiteren Aktivitäten:

Ihre Basissoftware wird zunächst wie im Falle eines SIP bei uns zusammengestellt. Danach konfiguriert und testet ein Mitar-

beiter unseres Serviceteams das Gesamtpaket unter genau den bei Ihnen vorliegenden Produktionsbedingungen und nimmt

das Paket bei Ihnen vor Ort in Betrieb.

Die Dokumentation des Installationsprozesses, die Erstellung von Test-Reports und die nachfolgende Supportleistung von Vec-

tor runden das Leistungspaket ab.

30.3 Konfiguration

Für eine komfortable Konfiguration Ihrer MICROSAR Lieferung empfehlen wir den DaVinci Configurator Pro. Mehr Details

finden Sie in der separaten Produktinformation.

30.4 Weitere relevante MICROSAR Produkte zum SIP und EIP

Unsere Serviceleistungen werden durch ein breites Portfolio an Unterstützungsangeboten ergänzt, die den erfolgreichen Pro-

jekt-Start, die Projekt-Migration und den Projekt-Review unterstützen. Details hierzu entnehmen Sie bitte der separaten Pro-

duktinformation "Services" im Internet unter http://vector.com/pi_embeddedservices_de.

http://vector.com/pi_embeddedservices_de

MICROSAR

115

31 AUTOSAR Eval Package – Komplettpaket zur Evaluierung von AUTOSAR-Basissoftware und -Tools

Das AUTOSAR Evaluierungspaket ist die umfassende Zusammenstellung von OEM-unabhängiger AUTOSAR-Basissoftware

(MICROSAR) sowie den Werkzeugen DaVinci Developer und DaVinci Configurator Pro. Dieses Paket ermöglicht die Entwick-

lung Ihrer ersten Steuergerätesoftware mit AUTOSAR-konformer Softwarearchitektur. Sie erhalten damit einen tiefen Einblick

in die AUTOSAR-Welt, vom Entwurfs- und Konfigurationsprozess bis zur konkreten Basissoftware. OEM-spezifische BSW-

Module z.B. für Diagnose erhalten Sie in unserem MICROSAR Prototypen SIP (siehe Ende dieses Kapitels).

31.1 Die Vorteile des AUTOSAR Evaluierungspakets im Überblick

> Werkzeuge und Basissoftware in Serienqualität nach AUTOSAR 4.x oder 3.x, zum Evaluieren der Vector Lösung für AU-

TOSAR

> Ermöglicht die realistische Beurteilung von Laufzeit- und Speicherbedarf Ihres Steuergeräte-Projektes

> Verfügbar für eine Vielzahl von Mikrocontrollern

> Schnelle Einarbeitung in AUTOSAR durch ausführliches Beispielprojekt

> Unterstützung sowohl der AUTOSAR-konformen als auch der konventionellen Beschreibungsdateien


Das AUTOSAR Evaluierungspaket unterstützt sowohl die Fahrzeughersteller bei der Evaluierung der AUTOSAR-Prozesse

und -Methoden als auch die Zulieferer bei der Erstellung einer ersten AUTOSAR-konformen Steuergerätesoftware. Da die

Werkzeuge und die Basis-Software dem Serienstand entsprechen, können Sie zuverlässig die Vector-Lösung für AUTOSAR

beurteilen bezüglich

> Effizienz der Basissoftware

> Einbindung der Werkzeuge in Ihre Entwicklungsumgebung

> Einsatzmöglichkeiten der AUTOSAR-Konzepte in Ihrem Anwendungsgebiet

Auch Dienstleistern, die sich auf die Applikationsebene konzentrieren, bietet das AUTOSAR-Evaluierungspaket die optimale

Basis für erste Entwicklungen von AUTOSAR-konformen Softwarekomponenten (SWCs).

31.3 Funktionen

Das AUTOSAR-Evaluierungspaket enthält die Werkzeuge und Embedded Software von Vector für das Erstellen einer komplet-

ten AUTOSAR-Steuergerätesoftware bestehend aus Softwarekomponenten (SWCs), Runtime Environment (RTE) und Basis-

software (BSW). Die DaVinci Werkzeuge sind auf AUTOSAR zugeschnitten und erleichtern Ihnen den Entwurf komplexer AU-

TOSAR-Anwendungen. Als Input für die Konfiguration der MICROSAR Software verwenden Sie einen „ECU Extract of System

Description“ (AUTOSAR XML) oder alternativ eine gängige Netzwerkbeschreibungsdatei (DBC, FIBEX, LDF).

> Mit dem Werkzeug DaVinci Developer erzeugen Sie auf einfachem Weg AUTOSAR-konforme ECU-Applikationen. Mit-

hilfe des grafischen Editors beschreiben Sie schnell und übersichtlich Ihre AUTOSAR-Softwarekomponenten und definie-

ren deren Schnittstellen.

> Mit dem Werkzeug DaVinci Configurator Pro konfigurieren Sie die Basissoftware-Module und die RTE. Durch die komfor-

table und übersichtliche Bedienoberfläche passen Sie die Parameterwerte für Ihr Steuergeräteprojekt an.

> Zusätzlich ist das Werkzeug CANdelaStudio von Vector verfügbar. Damit definieren Sie Diagnosedaten für Ihre Netz-

werke und Steuergeräte. Diese Daten exportieren Sie über Standardformate und verwenden sie zur automatischen Kon-

figuration der MICROSAR Diagnose-Basissoftware.

MICROSAR

116

Bild 67: Entwurf von Softwarekomponenten mit DaVinci Developer

Bild 68: Konfiguration der Basissoftware und der RTE mit DaVinci Configurator Pro

Das AUTOSAR Evaluierungspaket gibt es für AUTOSAR 4.x und 3.x. Die darin enthaltenen MICROSAR Basissoftware-Module

setzen alle Funktionen des entsprechenden AUTOSAR-Releases effizient und flexibel um. Sie enthalten über den Standard

hinaus viele Erweiterungen.

MICROSAR

117

31.4 Enthaltene BSW-Pakete

Die folgende Tabelle gibt Ihnen einen Überblick der einzelnen MICROSAR Pakete, die im AUTOSAR-Evaluierungspaket enthal-

ten sind. Eine komplette Beschreibung der jeweiligen Pakete entnehmen Sie den separaten Kapiteln in diesem Dokument.

Im EVAL-Bundle enthal-

ten: Erhältliche Optionen

MICROSAR.OS > Standard ist die Implementierung der „Scalability Class“ SC1

> SC2-SC4 sind optional erhältlich, sofern vom Prozessor unterstützt

> Multi-core ist optional erhältlich

MICROSAR.COM

MICROSAR.CAN

MICROSAR.LIN

MICROSAR.FR

MICROSAR.ETH

> Module aus dem jeweiligen Cluster nach Auswahl des Kunden

> XCP zum Messen und Kalibrieren über CAN/LIN/FR/ETH

MICROSAR.MEM > Das Modul Ea für interne EEPROMs

> Das Modul Fee für interne Flash Speicher

> Treiber zur Ansteuerung von externen Speicher Bausteinen in MICROSAR. EXT

MICROSAR. SYS > Das Modul Csm (Crypto Service Manager) für AUTOSAR 4.x

> Das Modul StbM (Synchronized Time-Base Manager) für AUTOSAR 4.x

> Treiber zur Ansteuerung von externen Speicherbausteinen (siehe MICROSAR. EXT)

MICROSAR. DIAG

MICROSAR. MCAL > I2c (Treiber für die Anbindung von externen Peripherie-Bausteinen über den Inter-Integrated

Circuit Bus „ I2C“)

> FlsTst, RamTst, CorTst

MICROSAR. IO

MICROSAR. RTE

Zusätzlich können zum Evaluierungspaket hinzubestellt werden:

Modul Beschreibung

MICROSAR. EXT > Module zur Ansteuerung von externen Bausteinen

MICROSAR. VTT > Lösung für virtuelle Integration mit vVIRTUALtarget

MICROSAR Safe > Komplette Lösung für sicherheitsrelevante Funktionssoftware nach ISO 26262

31.5 Spezielle Funktionen

DaVinci Developer verfügt über eine Import-/Exportschnittstelle für AUTOSAR XML-Dateien. Diese Schnittstelle ermöglicht

den Austausch von Entwurfs- und Konfigurationsdaten. So können Sie beispielsweise AUTOSAR-Softwarekomponenten in ein

Steuergerät integrieren, die Sie modellbasiert mit Werkzeugen wie MATLAB® Simulink® entwickelt haben.

Alle MICROSAR Produkte entsprechen

> der „Implementation Conformance Class“ ICC3 und

MICROSAR

118

> der „Configuration Conformance Class“ CCC 2.

31.6 Zusätzlich enthaltene Umfänge

> Beispielapplikation als Source-Code und ein ausführlicher Leitfaden zu deren Einsatz.

> AUTOSAR-Training bei Vector

31.7 Weitere Optionen

Die AUTOSAR-Evaluierungspakete CAN, LIN, ETH und FlexRay können beliebig miteinander kombiniert werden. Auf Wunsch

unterstützt Vector Sie mit einem umfangreichen MICROSAR Coaching bei der Erst-Inbetriebnahme und der Integration der

MICROSAR-Basissoftware in Ihre Applikation – gerne auch bei Ihnen vor Ort.

31.8 Verfügbare Hardware-Plattformen

Das AUTOSAR-Evaluierungspaket ist für die gängigsten 16-Bit und 32-Bit Hardware-Plattformen verfügbar. Aufgrund der

Hardwareabhängigkeit der MICROSAR.MCAL Module und dem MICROSAR.OS können verbindliche Aussagen nur auf Basis der

konkreten Derivatsnummer der Prozessoren gegeben werden. Hier steht Ihnen das Vector Sales Team gerne zur Verfügung.

Innerhalb einer Evaluierung können Sie zeitliche und personelle Ressourcen sparen, indem sie die VC-Hardware von Vector

einsetzen. Passend zu der VC-Hardware bietet Vector auch die entsprechende Unterstützung in der MICROSAR Basissoftware

an, wodurch die Inbetriebnahme der Basissoftware im Steuergerät besonders einfach ist. Die VC Hardware der Modellreihen

VC121 und VC54B wird softwareseitig durch folgende Inhalte unterstützt:

> VCx SW LIB

> MCAL VCx

> vFlash (mit passendem Template für den integrierten Flash Bootloader auf der VC121 bzw. VC54B)

Details zur VC-Hardware finden sie in der entsprechenden Produktinformation auf unserem Marketing-Portal unter

http://vector.com/vi_universal_controller_vc_de.html. Weitere Varianten der VC-Hardware sind bereits in Entwicklung.

Hinweis: Die Integration und der Test des Evaluation Bundles wird auf einem Evaluation Board durchgeführt. Vector

verwendet dafür Vector Testdatenbasen für die Kommunikation und die Diagnose.

31.9 MICROSAR Prototypen-SIP

Wenn Sie über die reine Evaluierung hinausgehend Software für die Prototypen-Phase eines konkreten OEM-Projektes benö-

tigen, empfehlen wir unser MICROSAR Prototypen-SIP (Software Integration Package). Bitte sprechen Sie uns an.

http://vector.com/vi_universal_controller_vc_de.html

MICROSAR

119

32 Weiterführende Informationen

Weitere Informationen zu unseren Produkten und dem Konfigurierungs- und Generierungswerkzeug DaVinci Configurator Pro

finden Sie auf der Portalseite im Internet: http://vector.com/vi_embedded_software_de.html.

Mehr Informationen

Besuchen Sie unsere Website für:

> News

> Produkte

> Demo-Software

> Support

> Seminare und Workshops

> Kontaktadressen

www.vector.com

Documents

MICROSAR Produktinformation Deutsch - assets.vector.com · MICROSAR 4 1 MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software MICROSAR ist die AUTOSAR-Lösung von Vector