MICROSAR Produktinformation Deutsch

MICROSAR

Produktinformation

MICROSAR

2

Inhaltsverzeichnis

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

2 MICROSAR.OS ........................................................................................................................................................................... 9

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

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

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

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

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

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

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 ...................................................................... 42

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

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

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

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

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

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

18 MICROSAR Lösungen .............................................................................................................................................................. 70

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

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

21 MICROSAR Gateway – Basissoftware für Gateway Steuergeräte .................................................................................... 79

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

23 MICROSAR Variantenhandling - Lösungen für flexible Konfigurationen in AUTOSAR ..................................................... 87

24 MICROSAR J1939 – AUTOSAR Basissoftware-Module speziell für Nutzfahrzeuge ......................................................... 90

25 MICROSAR VTT – Virtuelle Integration mit vVIRTUALtarget ............................................................................................. 93

26 MICROSAR POSIX – Anbindung von AUTOSAR Classic an POSIX-Betriebssysteme ....................................................... 97

27 MICROSAR.SIP und MICROSAR.EIP – Der Schnelleinstieg in Ihr AUTOSAR Projekt ..................................................... 101

28 AUTOSAR Eval Package – Komplettpaket zur Evaluierung von AUTOSAR-Basissoftware und -Tools ....................... 105

29 MICROSAR.OTA – Basissoftware-Module für den Software-Download ........................................................................ 109

30 MICROSAR.IPC – AUTOSAR Basissoftware-module für Interprozessorkommunikation .............................................. 111

31 Weiterführende Informationen ............................................................................................................................................ 116

V2.8 03/2018

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

MICROSAR

3

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 MICRO-

SAR.RTE und den MICROSAR Basissoftware-Modulen (BSW), die den gesamten Umfang des AUTOSAR-Standards sowie

viele Erweiterungen und Add-Ons abdecken. Jedes AUTOSAR BSW-Modul ist einem MICROSAR-Paket zugeordnet. Die de-

taillierten Beschreibungen 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

4

Paket Inhalt

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

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 Sicherheit nach ISO 26262 bis ASIL D für Steuergeräte-Software

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

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 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 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-

Software, 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.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.

1.1 Anwendungsgebiete

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

mentierung 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

entwickeln.

MICROSAR

5

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

verfü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 integrie-

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

Funktionssoftware 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 Informationsaustauschs 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

(Vector Basic Runtime Environment) optional unterstützt. vBRE vereinfacht die BSW-Integration durch das Bereitstellen

eines konfigurierbaren 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

Drittherstellern (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 Migra-

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

> 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 Anwendungssoft-

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

MICROSAR

6

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

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

Ethernet/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

Werkzeuge 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

Netzwerkbeschreibungsdateien (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 Erwei-

terung der AUTOSAR-Methode vereinfacht die Integration der Basissoftware in Ihr Steuergerät und reduziert die Integrati-

onszeit.

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 er-

zeugt. Diese Automatisierung nimmt Ihnen Aufgaben ab, die sich häufig wiederholen und bei manueller Durchführung fehler-

anfällig, zeitaufwändig und somit kostenintensiv sind.

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

MICROSAR

7

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

Steuergerä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

8

1.9 Lieferung von Sourcecode

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

compile-Optimierungen und vereinfacht das Testen.

1.10 Lizenz und Wartung

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

ten 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

verfü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 unse-

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

Internet unter www.vector-academy.de.

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

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

MICROSAR

9

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

> OS: Als Multi-core Betriebssystem verfügbar

> 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 er-

weitert. So bietet der implementierte High Resolution Timer Mechanismus Zeitauflösungen von weniger als 1ms ohne Erhö-

MICROSAR

10

hung der Interrupt-Last. In Abhängigkeit vom Controller sind damit Auflösungen bis in den Mikrosekundenbereich möglich.

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

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 Betriebs-

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

mit unterschiedlichen ASILs parallel betrieben werden. Der Master-Kern ist frei wählbar. Falls die Hardware nach einem Re-

set 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 lau-

fenden 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ützung

> 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.

MICROSAR

11

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.

LeanHypervisor wird nach ASIL-D als Software 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

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

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

den. 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

12

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-

Kommunikation. Sie unterstützen beliebig viele Kommunikationskanäle. Diese Dienste sind busunabhängig und werden in

jedem Kommunikations-Stack benötigt. Entsprechend der AUTOSAR-Architektur übernehmen sie die Kontrolle und vollstän-

dige 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

Aufgaben 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 MICRO-

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

MICROSAR

13


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öglich. 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 Kommunika-

tionsmodulen (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

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

nikationskanäle.

Erweiterung zum AUTOSAR Standard

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

> Backup Koordinator

MICROSAR

14

> 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 Kaptiel "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 norma-

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

Basisversion 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 separa-

ten 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

15

Bild 6: Konfiguration der Kommunikationsmodule mit dem DaVinci Configurator Pro

MICROSAR

16

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.

MICROSAR

17


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.

>

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

MICROSAR

18

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

>

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-

Protokoll.


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



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 Fol-

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

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

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

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

tivierung des VX1000 Treibers im Serieneinsatz zur Laufzeit ist jedoch auch bei Verwendung des Moduls VX1000If nicht

gestattet.

MICROSAR

19

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

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

20

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.

>

MICROSAR

21

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.


> 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-

Kompatibilitä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 IE-

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

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

22

5.5 Konfiguration



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ältli-

chen 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 (FRDRV) 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

23

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-Erweiterung verfügbar.

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.

>

MICROSAR

24

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

die Schedule Table Bearbeitung.


> 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.

>

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.


> 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.

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



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ältli-

chen 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 (LINDRV) 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

25

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 Fol-

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

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

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







gestattet.

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

26

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

Steuergerä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 und als Ergänzung zu AUTOSAR 3.x erhältlich

> Nach Automotive-Standard entwickelter und vom Fraunhofer ESK geprüfter TCP/IP-Stack

> 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

27

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

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

terleiten. 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 MICRO-

SAR.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 zwi-

schen 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 bei-

spielsweise 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. Wei-

tere 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ändig. 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 Ether-

net-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 IE-

EE 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

28

>

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

nikation 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-

Umgebung, 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)

>

SD: Service Discovery (SD) ist erstmals in AUTOSAR 4.1.1 spezifiziert. Über das in diesem Modul implementierte Proto-

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

Steuergerä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

>

Das Modul vETHFW ist eine Firewall welche unerwünschten ein- oder ausgehenden Datenverkehr blockiert, um die Si-

cherheit des gesamten Netzwerks zu erhöhen.

>

Das Ethernet Testability Module (vETM) implementiert eine standardisierte Gegenstelle für Protokoll-

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

Stack auslö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

29

Dieses Modul enthält einen Transport Layer Security Client. Mit vTLS wird TCP-basierte Kommunikation verschlüsselt.

Der verwendete Verschlüsselungsalgorithmus ist wählbar.




7.4 Konfiguration



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 Konfigura-

tionsparameter.

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 (ETHSWTDRV aus MICROSAR.MCAL und ETHSWTDRV EXT aus

MICROSAR.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.

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

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

MICROSAR

30

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

31

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

Mit Ethernet und dem darüberliegenden TCP/IP-Stack steht die Basistechnologie zur Verfügung, um mit Fahrzeug-externer

Infrastruktur zu kommunizieren.

Das Paket MICROSAR.V2G (Vehicle-to-Grid) enthält BSW-Module für das intelligente Laden von Elektro- und Hybridfahr-

zeugen 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 Erweite-

rungen werden sowohl für AUTOSAR 4.x als auch für AUTOSAR 3.x angeboten. Als Basis für MICROSAR.V2G werden Module

aus dem MICROSAR.ETH Paket benötigt. Details hierzu finden Sie in Kapitel 8.5.

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

8.1 Die Vorteile von MICROSAR.V2G 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.V2G 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

mit den dazugehörigen Möglichkeiten zum Wechsel- und Gleichstromladen (AC und DC), induktives Laden (WPT), Automatic

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

MICROSAR

32

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

Server kommunizieren.

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.V2G 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 und validieren Sie XML-Signaturen welche an EXI-kodierten Daten angehängt

sind und auf dem W3C XML-Security-Standard basieren. Es kommt im Vehicle2Grid-Umfeld zum Einsatz.

>

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 bzw. DIN SPEC 70121.

Add-Ons

> AC: Wechselstromladen sowie die dazugehörigen Profile Plug-and-Charge (PnC) und External-Identification-Means

(EIM).

> DC: Gleichstromladen sowie die dazugehörigen Profile Plug-and-Charge (PnC) und External-Identification-Means

(EIM).

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

> WPT: Wireless-Power-Transfer (WPT, Induktivladen)

> BPT: Bidirectional-Power-Transfer (BPT, 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 in Japan verwen-

deten 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.

MICROSAR

33

8.4 Konfiguration

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

der separaten Produktinformation.

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


MICROSAR.V2G 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 (ETHDRVEXT) 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-

Kommunikation (PLC) verfügbar.

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

wir die Verwendung der MICROSAR.RTE.

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

SAR.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 kostenlosen Smart-Charging-

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

rend 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.

MICROSAR

34

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

Bild 16: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet/V2G-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 Audi-

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

MICROSAR.ETH, aufsetzen. Die auf AUTOSAR 4.x basierte Lösung unterstützt vAVTP (Audio/Video Transport Protocol),

vRTP (Transport 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-Funktionalitä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 umge-

setzt.

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

Spezifikation IEEE 802.1AS umgesetzt.

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

notwendig, 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

zulassen.

>

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



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 (ETHDRV 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

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

9.6 Weitere relevante MICROSAR Module für Ethernet

> TCPIP, SOAD, DOIP, SOME/IP 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 konfi-

gurierbar) 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

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

Die Basissoftware-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/oder EEPROM-Speichern. Dadurch hat die Funktionssoftware einen Hardware-unabhängigen Zugriff auf den Speicher.

Die Applikation 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 –

MICROSAR

39

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

Memory-Stack zusätzliche BSW-Module:

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

Hardware geeigneten Flash Treiber (FLSDRV) im Rahmen unserer Dienstleistung des MCAL Integration Package oder

für externe Speicher (DRVEXT) aus MICROSAR.EXT. Zur Verwaltung der Daten braucht das FEE-Modul mindestens zwei

physikalische 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 Schreibzu-

griffe 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 ei-

nen 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üsssen, 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 neu-

er Konfigurationstabelle (Inhalt und Größe)

>

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

stanzen dieser Module verwenden.

>

MICROSAR

40

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

start 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.

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 arbeitserleich-

ternde 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 platt-

formspezifischen BSW-Modulen aus dem separat erhältlichen Paket MICROSAR.MCAL und MICROSAR.EXT einen komplet-

ten Memory-Stack.

> FLSDRV und/oder EEPDRV aus dem MCAL Integration Package

> DRVEXT aus MICROSAR.EXT für externe Speicherbausteine

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

MICROSAR

41

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

dem Paket MICROSAR.LIBS absichern.

MICROSAR

42

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

43

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 Kommuni-

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

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

unterstü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 Anwen-

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

verhalten 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 Steu-

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

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

Funktionalitä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

44

> 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

WDGDRV (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

Aktionen, 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 Auf-

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

schalten 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ähn-

ten Aufgaben bereits automatisch erstellen können. Nachfolgend können Sie diese per Click automatisch konfigurieren las-

sen. 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

45

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

Configuration 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öglich, 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 verbindenden 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



MICROSAR

46

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

E2ELIB 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

47

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

MICROSAR.DIAG enthält die BSW-Module für die Umsetzung des UDS-Protokolls ISO 14229-1:2013 (bzw. ISO 14229-

1:2006) 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

> 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

> Varianten-Handling für die Diagnosekonfiguration bereits enthalten

> Konfigurierbar über CANdela- und ODX-Format

> Generierung von optimierten Anwendungscode-Templates

MICROSAR

48


Ü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 (ISO27145) 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.

Dabei werden Redundanzen in der Steuergerätesoftware vermieden, weil identische Schnittstellen auf gleiche Daten, Ser-

vices 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

Unterschiede liegen in den Schnittstellen-Definitionen. Vector bietet Ihnen eine Migrationslösung an, mit der Sie Ihre AUTO-

SAR 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-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

Add-Ons

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

> WWH-OBD (ISO 27145)

>

Der DCM verarbeitet die UDS- und OBD-II-Services im Steuergerät.

Die OEM-unabhängige Variante des DCMs 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 in Kapitel 12.8.

Die DCM-Module für spezifische OEMs setzen die Spezifikationen des jeweiligen OEMs um. Deshalb variieren die Listen

der unterstützten Services wie z.B. die zusätzliche Unterstützung von ResponseOnEvent oder LinkControl. Gerne infor-

mieren wir Sie über die Details.


MICROSAR

49

> Varianten-Handling für Diagnosekonfigurationen

> Nahtlose Zusammenarbeit mit dem Vector Flash Bootloader

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

> J1939DCM: speziell für Nutzfahrzeuge konzipiertes DCM-Modul

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 Modul J1939Dcm realisiert Diagnostic Messages des SAE J1939-73-Protokolls z.B. zum Auslesen des Fehlerspei-

chers.

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-

Monitoring über mehrere Prozessoren. Der Diagnose-Master sammelt hierbei qualifizierte Diagnose-Events, welche vom

Diagnose-Salve 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-, 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

50

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

MICROSAR

51

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.ETH (ISO 14229-5)

Mit CANdelaStudio bedaten Sie die CANdela- bzw. ODX-Datei zur Konfiguration von MICROSAR.DIAG. Weitere Informatio-

nen 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 Routine-

Id

… start (stop/request result) for each Routine-

Id

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

MICROSAR

52

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)

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

53

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

Treiber 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

auswechseln, 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

kompletten Kommunikations-Stack oder eine Speicherverwaltung.

MICROSAR

54


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 ver-

fü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

CANDRV (SocketCAN) nutzt ein vorhandenes SocketCAN API um darüber die CAN Kommunikation zu realisieren und er-

laubt 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) anzu-

stoß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

55

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 vIICDRV-Treiber stellt Dienste zur Kommunikation mit externen I2C-Bausteinen bereit.

Erweiterung des AUTOSAR Standard

> >Der vIICDRV enthält Treiber für die Anbindung von externen Peripherie-Bausteinen über den Inter-Integrated Circuit-

Bus (I2C)





13.4 Konfiguration



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 Integrati-

on eines 3rd Party MCALs in die Vector Embedded- und Werkzeugumgebung erreicht wird. Hierbei nehmen wir in Abstim-

mung mit Ihnen und dem Halbleiterhersteller den beigestellten MCAL des Halbleiterherstellers zusammen mit der Vector

MICROSAR

56

Basissoftware in Betrieb. Wir überprüfen ihn auf Konformität bzw. Integrierbarkeit und erreichen so, dass die 3rd Party

Software 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

57

> Ü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 Ein-

satz von unterschiedlichen Konfigurationsdateien und Konfigurationstools erleichtern.

MICROSAR

58

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 (DRVEXT) 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“ spezi-

fiziert. Sie entsprechen AUTOSAR 4.x, sind für den jeweiligen Baustein optimiert und stehen für eine Vielzahl gängiger Bau-

steine 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üs-

sen 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

erhalten einen kompletten Kommunikations-Stack oder eine Speicherverwaltung nach AUTOSAR-Spezifikation.

MICROSAR

59

Für den Teilnetzbetrieb in CAN-Netzwerken benötigen Sie spezielle Transceiver. Für viele dieser Transceiver ist bereits ein

passender Treiber (CANTRCV) in MICROSAR.EXT erhältlich.


>

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 verwen-

deten 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.

> EXTADC

> EEPEXT

> FLSEXT

> ETHSWTDRVEXT

> ETHDRVEXT

> WDGEXT

14.3.1 Vector Module als Erweiterung des AUTOSAR Standard

>

Das vSBC Modul abstrahiert den Zugriff auf einen externen System Basis Chip.

Das Modul stellt eine Hardware-unabhängige Schnittstelle zur Verfügung, welche von höheren Schichten wie z.B. dem

CanTrcv, LinTrcv oder Wdg zur Kontrolle der SBC Hardware verwendet werden kann.

>

Das vPSI5 Modul setzt das "Peripheral Sensor Interface 5" (PSI5) Protokoll um. PSI5 ist ein offener Standard für bidirek-

tionale, digitale Sensordaten Kommunication in Fahrzeugen.

Die BSW-Module in MICROSAR.EXT enthalten die in AUTOSAR 4.x definierten Funktionen mit den folgenden Erweiterungen:

> Busfehlererkennung auf FlexRay

> LIN-Transceiver Treiber (auch für AUTOSAR 3.x)

> Ethernet–Transceiver Treiber, auch für Powerline Communication (PLC) und Wireless LAN (WLAN) (AUTOSAR 4.x und

3.x)

MICROSAR

60

> Ethernet-Switch Treiber (ab AUTOSAR 4.2 Standard)

Für AUTOSAR 4 ist optional ein Treiber für den System-Basischip (vSBC) erhältlich. Er unterstützt je nach Hardware unter-

schiedliche Peripherien wie Bus-Transceiver und Watchdog. Mit seiner Hilfe können externe Peripherien einfach an die

MICROSAR Software angebunden werden. Bitte erfragen Sie den genauen Funktionsumfang des vSBC-Treibers in Bezug auf

die bei Ihnen eingesetzte Hardware. Optional ist der vSBC-Treiber im Rahmen der Lösung SafeBSW in den Ausprägungen

ASIL A bis ASIL D erhältlich.

Alternativ erhältlich ist ein generischer SBC-Treiber. Dieser stellt einen Rahmen zur Verfügung, mit dem Sie den Hardware-

spezifischen Teil der Implementierung durch einen Zugriff auf die Register des SBC selbst vornehmen können.

14.4 Konfiguration



Bild 34: 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 (SPIDRV, DIODRV oder PORTDRV) 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 naht-

los und schnell mit einem einzigen Werkzeug zu konfigurieren.

MICROSAR

61

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 35: 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-

Signalen 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 Beispiel Zugang zu ADC- oder ICU-Kanälen bieten.

>

MICROSAR

62

Der innerhalb MICROSAR.IO erhältliche vSENT Treiber ist eine Erweiterung zum AUTOSAR-Standard und bietet Zugriff

auf Sensoren welche mittels SENT-Protokoll basierend auf J2716 angebunden sind. Er ist durch die Schnittstellenanbin-

dung an das ICU-Modul Hardware-unabhängig. Er bietet folgende Funktionalität an:

> SENT Master Node Funktionalität

> Unterstützung mehrerer SENT-Kanäle

> Slow- und fast Channel

> Enhanced serial message format bei slow channel

> Timeout-Überwachung für periodische Slow Channel Daten (MICROSAR Erweiterung)

> Debug Modus für das Protokoll-debugging (MICROSAR Erweiterung)

> Bereitstellung beispielhafter SWC-Templates für das Entwicklungswerkzeug DaVinci Developer

> Sender/Receiver-Port für Fast Channel Daten

> Client/Server-Port für Slow Channel Daten

15.3 Konfiguration

Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Details hierzu erfahren Sie in der sepa-

raten Produktinformation.

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

Sender/Receiver-Interfaces 1:n möglich. Runnable Entities in der RTE und Schedulable Entities im SchM sind beliebig konfigu-

rierbar. Für den Zugriff der Funktionssoftware über die RTE auf die I/O-Signale stellt MICROSAR.IO alle notwendigen Cli-

ent/Server Interfaces sowie Code-Templates zur Verfügung. Diese ermöglichen dem Anwender das Aufbereiten und Filtern

der Signale.

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

Implementierung 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

63

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 Funktionssoft-

ware, Basissoftware (BSW) sowie Complex Drivern (CDD).

Bild 36: 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 Flexibili-

tä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.

MICROSAR

64

Beim Generieren der MICROSAR.RTE kann der Anwender zwischen zwei Modi wählen:

> 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 Kapi-

tel 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

MICROSAR

65

erforderlich, da die BRE die Nutzung der existierenden Anwendungs-Architektur ermöglicht. Sie ist dadurch das ideale In-

strument, um ein bestehendes Steuergeräte-Projekt in eine AUTOSAR-Architektur zu migrieren.

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 er-

fahrenen Coaches unterstützen Sie gerne, wenn Sie Ihre Anwendung und BSW-Architektur auf den AUTOSAR-Standard

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

66

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 37: 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

67

Bild 38: 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ätz-

lich 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 Steuer-

gerä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 Zu-

stände und binäre Signale in einem Fenster übersichtlich dar.

Bild 39: 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üs-

se einen Zustandswechsel der BSW-Module verursacht haben. Die dazu benötigten internen Variablen der MICROSAR BSW-

Module 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 wer-

den die folgenden RTE-interne Objekte erfasst:

MICROSAR

68

> 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 Sen-

der/Receiver 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 War-

nungen, 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 übermitteln 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 Anwendungssoft-

ware 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 Konfigura-

tionsdaten 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 40: Erzeugen einer A2L-Datei für den XCP-Master

MICROSAR

69

17.4 Konfiguration



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

70

18 MICROSAR Lösungen

Jetzt folgen die Beschreibungen der bereits eingangs vorstellten Lösungen. Diese Lösungen sind paketübergreifend und kön-

nen die unterschiedlichsten Module aus ganz verschiedenen Pakete beinhalten. Zu den Lösungen gehören: MICROSAR Safe,

MICROSAR Security, MICROSAR Multicore, MICROSAR Variant Handling, MICROSAR Posix, MICROSAR Gateway, MICRO-

SAR J1939, MICROSAR vVIRTUALtarget.

MICROSAR

71

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

entwickelt und können mit sicherheitsrelevanten SWCs auch ohne eine Partitionierung koexistieren. Darüber hinaus können

bei Bedarf auch weitere Sicherheitsanforderungen in der Basissoftware abgebildet werden.

Bild 41: 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

72


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

Ergebnis 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 MICRO-

SAR Safe auch die SafeRTE zur Verfügung.

Für Mixed-ASIL-Systeme (Steuergeräte, die sowohl ASIL-Funktionen als auch Funktionen ohne Sicherheitsanforderungen

enthalten) ist als kleinste mögliche Ausbaustufe ein Umfang notwendig, der die Bausteine SafeOS, SafeWDG und SafeE2E

umfasst. Eine Erweiterung dieses Mindestumfangs erfolgt dann passgenau zu Ihren Anforderungen, bis hin zum kompletten

Basissoftware Stack nach ASIL D.

Bild 42: 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

Betriebssystems. Dabei schottet MICROSAR.OS (SC3/SC4) auf geeigneten Mikroprozessoren, z.B. mit einer Memory Protec-

tion Unit (MPU), die verschiedenen Software-Partitionen voneinander ab. Dies verhindert, dass SWCs unerlaubt in den Spei-

cher 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 Regis-

ter, 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 Da-

ten 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

73

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 Pro-

tection 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 si-

cherheitsrelevante Anwendungen definiert ist. Das Paket SafeWDG realisiert die Anbindung eines internen oder externen

Hardware Watchdog mithilfe der Module WDGIF, WDGDRV bzw. WDGDRVEXT 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 (siehe Kapitel 19.3.1) die Partitionierung von Spei-

cherbereichen. Um die sichere Kommunikation zwischen Anwendungen auf einem Steuergerät zu ermöglichen, ist eine RTE

gemäß ISO 26262 erforderlich. Zur Absicherung der MICROSAR.RTE steht Ihnen das statische Analysewerkzeug RTE Analy-

zer 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 entspre-

chendes 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 durch-

geführt werden. Es wird "freedom from interference" mittels MPU-Unterstützung inkl. des sicheren Kontextwechsels, die

Laufzeitüberwachung und die sichere externe Kommunikation unterstützt. MICROSAR Safe für AUTOSAR 3 beinhaltet die

Hauptgruppen 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 LIB (End to End-Library)

> CRC LIB

SafeWDG > WDGM: Watchdog Manager

> WDGIF: Watchdog Interface

MICROSAR

74

Baustein Inhalt

> WDGDRV: Treiber für interne Watchdog-Bausteine

> WDGDRVEXT: Treiber für externe Watchdog-Bausteinen

> vSBC: Treiber für System Basis Chip Bausteine (mit Watchdog- und Transceiver-Funktion)

MICROSAR

75

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 43: 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

> Authentifikation 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

MICROSAR

76

> Konfiguration von Operationen an kryptografischen Schlüsseln

> Konfiguration von Operationen an Zertifikaten

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 Securi-

ty 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. Die folgende Tabelle zeigt die implementierten

Schnittstellen und die unterstützten Algorithmen sowie Funktionen:

Service CSM Interface Algorithm / Function

Hash Functions

Hash Interface SHA-1

SHA-2 (SHA-256, SHA-512)

Random Numbers Random Interface Random Number Generation acc. to FIPS-186

Message Authentication Code

(MAC) Generation and Verifi-

cation

MAC Interface HMAC based on RIPEMD

HMAC based on SHA

CMAC based on AES

SipHash

Symmetric Encryption and

Decryption

Cipher Interface AES (128, 192, 256) in the modes: CBC, GCM,

CCM CTR, ECB, XTS

RIPEMD-160

Asymmetric Encryption and

Decryption

Cipher Interface RSA (512 - 4096 bit key length)

ECC (160, 192, 224, 256) Curve22519

Key Handling Key Setting Interface

Key Extraction Interface

Key Copying Interface

Key Generation Interface

Key Derivation Interface

Key Exchange Interface

KDF (counter mode) acc. to NIST 800-108, Key

Pair Generation using Extra Random Bits acc. to

FIPS 186-4, KDF2 based on HMAC-SHA1, KDF

based on HMAC-SHA1, ECDH (128-512 bit key

length) acc. to X9.63, ECDHE

Signature Generation and

Verification

Signature Interface Digital signatures based on RSA with 512-4096 bit

key length

ECDSA with 128-512 bit key length

Reading and Incrementation of

Secure Counters

Secure Counter Interface

Parsing and Verification of

Certificates

Certificate Interface Certificates acc. to X509 V2, V3

Tabelle 1: Unterstütze Algorithmen in MICROSAR

MICROSAR

77

20.2.4 Crypto (HW)

Das Modul Crypto (HW) fungiert als Treiber für den Zugriff auf die Security-Algorithmen und Funktionen, die über einen

Hardware Trust Anchor (HTA) bereitgestellt werden. Es sind verschiedene HTA-Typen verfügbar, wie beispielsweise Secure

Hardware Extensions (SHE) oder Hardware Security Modules (HSM). In Abhängigkeit von der Hardware-Plattform und dem

verwendeten 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

Module“ (vHSM) zur Verfügung. Die vHSM Firmware von Vector stellt hierbei die benötigten Algorithmen für den CSM zur

Verfügung.

20.2.5 Secured OnBoard Communication (SecOC)

Das Modul SecOC dient der authentifizierten Kommunikation zwischen zwei Steuergeräten. Durch die Absicherung kann eine

dritte Stelle nicht eingreifen oder vorgeben, sie wäre die richtige Gegenstelle. Manipulative Eingriffe sind dadurch ausge-

schlossen. 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.

20.2.6 Ethernet Firewall (vETHFW)

Die Ethernet Firewall vETHFW stellt die Implementierung einer Firewall für die Ethernet Kommunikation bereit. Ihre Haupt-

aufgabe ist es, unerwünschten ein- oder ausgehenden Datenverkehr zu blockieren, um die Sicherheit des gesamten Netz-

werks 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.7 Hardware Security Module Firmware (vHSM)

Die Firmware für ein Hardware Security Module (vHSM) erlaubt die Umsetzung der Crypto-Algorithmen auf einer dedizierten

Ausführungseinheit (Hardware Security Module) des Mikrocontrollers. Die vHSM-Firmware nutzt dabei alle in Hardware

verfügbaren Crypto-Implementierungen. Falls zusätzliche Algorithmen benötigt werden, werden diese in der geschützten

Umgebung des HSM in Software bereitgestellt.

Die vHSM-Firmware bietet zusätzliche Sicherheit für das Steuergerät unter anderem durch die Implementierung von Secure

Boot Mechanismen und sicherer Schlüsselablage.

Die Anbindung an den MICROSAR-Stack erfolgt über einen speziellen Crypto (HW)-Treiber, den „Crypto (vHSM)“.

20.2.8 Security Add-On

Das Security Add-On 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.

MICROSAR

78

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

79

21 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 zwi-

schen 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 Basisfunk-

tionalität, Sonderfunktionen und Erweiterbarkeit bietet MICROSAR Gateway die nötige Flexibilität um spezifische Anwen-

dungsfälle abzudecken.

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 44: Multi-Layer Gateway in MICROSAR

21.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-

support)

> Optional begleitender Support von Gateway-Projekten durch Vector in enger Zusammenarbeit mit dem Tier1

MICROSAR

80


MICROSAR Gateway bietet dem Anwender die notwendige Basissoftware, um Daten auf der jeweils optimalen Protokollebe-

ne 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).

21.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 IPDUM)

> 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

81

Bild 45: 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

82

21.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 explizi-

te Spezifikation von Routinginformationen. Diese werden von DaVinci Configurator Pro eingelesen und in eine Software-

konfiguration 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 Netzwerkbe-

schreibung in den Eingangsdateien ändern, lässt sich die Softwarekonfiguration automatisch aktualisieren.

Bild 46: 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 be-

arbeitet werden. Mehr Details hierzu finden Sie in der separaten Produktinformation.

21.5 Projektsupport

An Gateway Steuergeräte werden besonders häufig sowohl OEM-spezifische als auch anwendungsspezifische Anforderun-

gen gestellt, die ein Standardprodukt in der Regel nicht vollumfänglich erfüllt. Um diese Anforderungen in ihrem Projekt den-

noch 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 Kundenan-

forderungen, als dies in einem durch Release-Zyklen geprägten Produktansatz möglich ist. Innerhalb eines gemeinsamen

MICROSAR

83

Projekts implementieren wir dann gerne auch die zur Erfüllung der Kundenanforderungen notwendigen Produkterweite-

rungen.

Bild 47: Dreischichtige Herangehensweise zur optimalen Entwicklungsunterstützung

MICROSAR

84

22 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. Ent-

scheidend für den Erfolg ist eine optimale Verteilung mit geringen Synchronisationsverlusten, verursacht beispielsweise durch

Wartezeiten. MICROSAR Multi-core unterstützt Sie hierbei umfassend.

22.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-

Konzept von MICROSAR ein

> Bereitstellung von AUTOSAR BSW-Satelliten auf Slave-Prozessorkernen zur Gewährleistung einer laufzeitoptimierten

Abwicklung der Servicefunktionen

> Einfache Konfiguration

> Erhältlich für einzelne MICROSAR-Module

> Mit der bei Vector optional erhältlichen Tool Suite der Firma Timing Architects 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

denen:

> 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.

MICROSAR 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.

22.3 Funktionen

22.3.1 RTE

Die MICROSAR.RTE verwendet im Multi-core Umfeld bevorzugt Shared-Memory, um Laufzeit und Speicherbelegung zu mi-

nimieren. Bei Bedarf werden Spinlocks verwendet, um die Datenkonsistenz abzusichern. Dabei entstehen nur dann Wartezei-

ten für die Prozessorkerne, wenn sie zur gleichen Zeit auf den gleichen Speicherbereich zugreifen.

22.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

gehalten werden können.

MICROSAR

85

22.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 Prozessor-

kerne gültig ist.

22.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

laufzeitoptimierte Abwicklung der Servicefunktionen des WDGM.

22.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.

22.4 Konfiguration

22.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.

22.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 die-

ser Tasks zu einer OS-Applikation. Jede OS-Applikation wird dann wieder einem konkreten Prozessorkern zugeordnet.

Bild 48: 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

finden Sie auf unserer Website https://vector.com/vi_davinci_configurator_pro_de.html.

MICROSAR

86

22.5 Lieferumfang

Im Rahmen der Lieferung erhalten sie alle gewählten Module aus dem MICROSAR-Paket in einem für Multi-core-Projekte

geeigneten Umfang. Einige Module wurden verändert, um effizienter mit den Anforderungen für Multi-core umgehen zu kön-

nen.

> Master-Satellite-Module: WDGM / WGIF, DEM, ECUM, XCP, RTM, DET

> Anwendungs-Proxies: NVM, COM

MICROSAR

87

23 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

entwickeln. Diese Entwicklungskette kostet bei kleinen Änderungen unverhältnismäßig viel Zeit und Geld. Besonders die Ent-

wicklung 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 unterschiedli-

chen Einsatzbereiche. Das reduziert Hardwarekosten und den Aufwand bei der Lagerverwaltung. Im Gegenzug entsteht ein

Mehraufwand 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.

23.1 Post-Build Loadable – Nachträgliche Modifikation von BSW-Merkmalen

23.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

23.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.

23.1.3 Vertrauter Konfigurationsprozess

Der Konfigurationsprozess zum Post-Build-Zeitpunkt findet mit dem Standard-Konfigurationswerkzeug DaVinci Configura-

tor Pro statt. Es steht somit ein mächtiges Werkzeug für die reibungslose Synchronisation mit einer Vielzahl von Datenban-

ken (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

88

Bild 49: MICROSAR Post-Build Loadable Workflow

23.1.4 Lieferumfang "Post-Build Loadable"

> Lizenz für die Freischaltung im Konfigurations-Werkzeug

> Werkzeuge zur Erstellung eines Build Loadable Updates

> Dokumentation

23.2 Der MICROSAR Identity Manager - die Post-Build Selectable Lösung für Mehrfachsteuergeräte

23.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

23.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

89

Baureihe eine unterschiedliche Kommunikationsbeschreibung. Die bei der Konfiguration zugrundeliegenden Datenbanken

können sich bei den verwendeten Varianten deutlich unterscheiden – zum Beispiel durch ein komplett anderes Signallayout

oder eine unterschiedliche Anzahl an Netzwerken.

Bild 50: Einsatz eines Steuergerätes mit unterschiedlichen Funktionen unter Verwendung des Identity Managers

23.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

Description, Legacy-Formate wie DBC, Diagnose Beschreibungen (CDD, ODX)) vorgegeben werden.

23.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 reali-

siert. Dies kann zum Beispiel eine Steckercodierung oder eine Speichercodierung in Flash sein.

23.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

effiziente Speicherverwendung im RAM und ROM besonderen Wert gelegt.

23.2.6 Lieferumfang "Post-Build Selectable"

> Lizenz für die Freischaltung im Konfigurations-Werkzeug

> BSW-Module mit Identity Manager Funktionalität

> Dokumentation

MICROSAR

90

24 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 51: Die MICROSAR J1939 Module nach AUTOSAR 4.3

24.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 Requ-

est 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 gemein-

samer Nutzung der gespeicherten Diagnosedaten des DEM über J1939- und UDS-Diagnose.

MICROSAR

91

> 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

> 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

werden durch Erweiterungen in benachbarten Modulen unterstützt. Darüber hinaus kann MICROSAR.CAN auch zur Imple-

mentierung 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 Adress-Arbitrierung und –

verfolgung erweitert und im J1939TP zusätzlich die Transportprotokolle ETP und FastPacket implementiert. Auch maritime

Anwendungen 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





24.4 Konfiguration



24.5 Weitere relevante MICROSAR Produkte für J1939

> DEM aus MICROSAR.DIAG

> DET, BSWM, ECUM und COMM aus MICROSAR.SYS

MICROSAR

92


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.







gestattet.

MICROSAR

93

25 MICROSAR VTT – Virtuelle Integration mit vVIRTUALtarget

Die Entwicklung eines Steuergerätes beginnt typischerweise mit der Erstellung einzelner Software-Module (SWC). Infolge

immer kürzer werdender Projektzeiten steht jedoch in der Regel nicht die notwendige Zeit zur Verfügung, um zuerst alle not-

wendigen SWCs zu erstellen und diese dann für sich alleine, in der Interaktion untereinander und am Ende auch im Zusam-

menspiel 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 52: Klassischer Steuergeräte-Entwicklungsprozess

Für diese Situation bietet vVIRTUALtarget (VTT) 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

Umgebung 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 53: Steuergeräte-Entwicklungsprozess mit vVIRTUALtarget

Die Steuergeräte-Software und deren Bedatung sind nach der Entwicklung der SWCs und deren System-Integration in ei-

nem fortgeschrittenen Stadium. Neben der Applikation wird nun auch die Konfiguration der Basissoftware konkreter be-

trachtet. Hier bietet vVIRTUALtarget die Möglichkeit, unabhängig von der Zielplattform zu testen.

MICROSAR

94

Bild 54: Der Anwendungsbereich von vVIRTUALtarget (Version vVIRTUALtarget pro derzeit in Entwicklung)

25.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

25.3 Funktionen

vVIRTUALtarget basic ist für die Steuergeräte-Integration vorgesehen und ermöglicht den Test des kompletten Stacks (Ap-

plikation, 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

MICROSAR

95

> Unterstützung von AUTOSAR-konformen 3rd Party Modulen

25.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 wird Microsoft Visual Studio 2013 (Express & Professional) unterstützt.

Bild 55: Das Dual-Target-Prinzip

Als Laufzeitumgebung wird CANoe eingesetzt. Die erzeugte DLL wird dabei im Steuergeräte-Knoten in der CANoe-

Konfiguration referenziert. Ein Debugging des virtuellen Steuergeräts ist über das Visual Studio Projekt möglich. Für die Sti-

mulation ü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.

25.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

entsprechen die MCAL-Schnittstellen und das Verhalten den Spezifikationen nach AUTOSAR 4. Das für vVIRTUALtarget

erhältliche 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. Hier-

bei handelt es sich um dieselben BSW-Module, die auch im realen Steuergerät zum Einsatz kommen.

25.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

96

Bild 56: Der MICROSAR-Workflow erweitert um den Workflow von vVIRTUALtarget

25.5 Konfiguration


ten Produktinformation. Für die Konfiguration der vVIRTUALtarget spezifischen Anteile und die Generierung eines Visual

Studio Projekts ist die Option VTT des DaVinciConfigurator Pro erforderlich.

25.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).

25.7 Systemvoraussetzungen

Unser Produkt vVIRTUALtarget ist eine 64-Bit Anwendung und setzt dementsprechend ein 64-Bit Microsoft Windows voraus.

25.8 Weitere relevante MICROSAR Produkte für VTT

Zum Kennenlernen der virtuellen Integration und Erprobung ihrer Funktionsweise ist das Evaluierungspaket "AUTOSAR Eva-

luation Bundle VTT" erhältlich. Nähere Informationen erhalten Sie im Kapitel "AUTOSAR Evaluierungspaket“.

MICROSAR

97

26 MICROSAR POSIX – Anbindung von AUTOSAR Classic an POSIX-Betriebssysteme

Fahrer-Assistenzsysteme und Infotainment führen zu einer immer stärkeren Verzahnung der etablierten statischen Steuer-

geräte-Lösungen mit neuen, dynamischen Diensten. Aus diesem Grund befinden sich in Steuergeräte-Projekten immer häufi-

ger 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

auszutauschen.

Bild 57: Typische Arbeitsgebiete bei POSIX-basierten Steuergeräten

26.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.

26.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 Trei-

ber zur Verfügung. Zur Anbindung an ein Bordnetz fehlen jedoch die notwendigen höheren Protokollschichten. Ein häufig

vorkommendes Anwendungsbeispiel ist die Diagnoseanbindung über DoIP. Hier ist es von Vorteil, wenn bestehende Imple-

mentierungen übernommen werden können.

MICROSAR

98

Bild 58: 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 Konfigura-

tionswerkzeuge. In der Folge reduziert sich die erforderliche Umstellung beziehungsweise Einarbeitung in diesen Anwen-

dungsfall auf ein Minimum. Gleichzeitig wird durch die Nutzung der freigegebenen Komponenten auch die Buskompatibilität

des POSIX-Steuergeräts sichergestellt.

26.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.

26.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 Betriebssys-

tem Kernels angepasst werden.

MICROSAR

99

26.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 Kommunikation auf das minimal notwendige Maß zu reduzieren.

Bild 59: Verteilte Diagnose in einem POSIX-System

26.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 unterschied-

liche 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 –

verfahren 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 er-

gänzt um das IPC-spezifische Interface sowie die notwendigen Hardware Treiber.

26.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 wirkungs-

voll 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

100

26.3 Konfiguration



MICROSAR

101

27 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.

27.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 In-

tegration 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.

27.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

102

Bild 60: Das MICROSAR Software Integration Package und seine optionalen Zusatzleistungen

27.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-

spezifischen Eingangsdaten bezüglich Kommunikation (z.B. den ECU-Extract) und Diagnose (z.B. ECUC). Die Start Applika-

tion 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 ei-

nes 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

enthalten 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-

Basissoftware

> 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

103

27.2 Das Extended Integration Package (EIP)

Aufbauend auf dem MICROSAR.SIP in Verbindung mit erweiternden SIP-Erweiterungen [siehe oben] unterstützt das

MICROSAR.EIP den weiteren Verlauf einer Initial-Lieferung. Es bietet eine maßgebliche Supportleistung zur schnellen und

umfassenden 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 61: Das Extended Integration Package im Zusammenspiel mit den SIP-Optionen

27.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

MICROSAR

104

bei Erstprojekten im AUTOSAR-Umfeld von Interesse sein kann, sowie beim Vorliegen von besonderen Projektbedingungen im

Rahmen 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

konkrete 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

Vector runden das Leistungspaket ab.

27.3 Konfiguration

Für eine komfortable Konfiguration Ihrer MICROSAR Lieferung empfehlen wir den DaVinci Configurator Pro. Mehr Details

finden Sie in der separaten Produktinformation.

27.4 Weitere relevante MICROSAR Produkte zum SIP und EIP

Unsere Serviceleistungen werden durch ein breites Portfolio an Unterstützungsangeboten ergänzt, die den erfolgreichen

Projekt-Start, die Projekt-Migration und den Projekt-Review unterstützen. Details hierzu entnehmen Sie bitte der separaten

Produktinformation "Services" im Internet unter http://vector.com/pi_embeddedservices_de.

http://vector.com/pi_embeddedservices_de

MICROSAR

105

28 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 Ein-

blick 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).

28.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).

28.3 Funktionen

Das AUTOSAR-Evaluierungspaket enthält die Werkzeuge und Embedded Software von Vector für das Erstellen einer kom-

pletten AUTOSAR-Steuergerätesoftware bestehend aus Softwarekomponenten (SWCs), Runtime Environment (RTE) und

Basissoftware (BSW). Die DaVinci Werkzeuge sind auf AUTOSAR zugeschnitten und erleichtern Ihnen den Entwurf komple-

xer AUTOSAR-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. Mithil-

fe des grafischen Editors beschreiben Sie schnell und übersichtlich Ihre AUTOSAR-Softwarekomponenten und definieren

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

106

Bild 62: Entwurf von Softwarekomponenten mit DaVinci Developer

Bild 63: 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

107

28.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 > IICDRV (Treiber für die Anbindung von externen Peripherie-Bausteinen über den Inter-

Integrated Circuit Bus „ I2C“)

> FLASHTST, RAMTST, CORETST

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

28.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

108

> der „Configuration Conformance Class“ CCC 2.

28.6 Zusätzlich enthaltene Umfänge

> Beispielapplikation als Source-Code und ein ausführlicher Leitfaden zu deren Einsatz.

> AUTOSAR-Training bei Vector

28.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.

28.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 Basissoft-

ware an, wodurch die Inbetriebnahme der Basissoftware im Steuergerät besonders einfach ist. Die VC Hardware der Modell-

reihen 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.

28.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

109

29 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 64: Das MICROSAR.OTA Modul

29.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

angebotenen 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 Verwaltung von Softwareupdates wesentlich vereinfachen.

MICROSAR

110

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.

29.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 die-

ser 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.

29.4 Konfiguration

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

Funktionen wie Optimierungshilfen, optische Darstellung der Flash-Auslastung usw. Mehr Details finden Sie in der Produktin-

formation zum DaVinci Configurator Pro.

29.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.

>

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ährend die Applikation auf dem Steuergerät ohne Beeinträchtigung weiterläuft.

MICROSAR

111

30 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 wer-

den können.

Das Paket MICROSAR.IPC wurde genau für solche Fälle entwickelt. Es bietet alle nötigen Softwaremodule für eine Kommu-

nikation zwischen zwei und mehr Prozessoren bzw. Kernen eines Mikrocontrollers. MICROSAR.IPC ist flexibel gestaltet und

erlaubt 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.

30.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

MICROSAR

112

> Signalbasierte Kommunikation

> Ü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 65: Die zwei grundsätzlichen Anwendungsfälle von MICROSAR.IPC

30.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

MICROSAR

113

> Verbesserte Fairness bei der Übertragung auf Multiplex-Kanälen

> 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 Erweite-

rungen 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

114

30.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

Repräsentation auf dem Übertragungsmedium.

30.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.

30.4.3 Übertragung von Rohdaten

Die Daten werden direkt von der Applikation interpretiert und bereitgestellt. Die Basissoftware und MICROSAR.IPC übertra-

gen 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 übernom-

men.

30.4.4 Systemservice Kommunikation

Über vIpc werden serialisierte Aufrufe von Systemservices übertragen. Diese werden beim empfangenden Endpunkt deko-

diert und ausgeführt. Typisches Beispiel dafür sind Funktionen, die sich auf die Fahrzeugdiagnose beziehen, aber auch die

Steuergerätekalibrierung via XCP.

MICROSAR

115

30.4.5 PDU basiertes Routing

Bei Systemen, deren Feldbusse unterschiedlichen Mikrocontrollern fest zugewiesen sind, müssen oft PDUs zwischen den

Feldbussen 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 einge-

speist.

30.4.6 Signalbasiertes Routing

Dieser Anwendungsfall ist vergleichbar mit dem PDU basierten Routing. Allerdings werden beim signalbasierten Routing

einzelne 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

Signale anzupassen. So kann zum Beispiel ein über einen Feldbus empfangenes Signal mit reduzierter Zykluszeit an den vIpc

Zielendpunkt weitergeleitet werden.

30.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

beispielsweise mit unserem Systemmodellierungswerkzeug PREEvision erzeugt werden.

30.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 definier-

te Schnittstellen der Applikationssoftware bereit und übernimmt die Serialisierung sowie De-Serialisierung gemäß SOME/IP

Protokoll.

MICROSAR

116

31 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