MICROSAR Produktinformation

Transcription

MICROSAR
Produktinformation
MICROSAR
Inhaltsverzeichnis
1
MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software ............................................................................. 3
2
MICROSAR.OS – Das Echtzeitbetriebssystem von Vector für den AUTOSAR-Standard .................................................. 9
3
MICROSAR.COM – AUTOSAR Basissoftware-Module für die Kommunikation ................................................................ 12
4
MICROSAR Gateway – Basissoftware für Gateway Steuergeräte .................................................................................... 15
5
MICROSAR.CAN – AUTOSAR Basissoftware-Module für die CAN-Kommunikation ........................................................ 20
6
MICROSAR.FR – AUTOSAR Basissoftware-Module für die FlexRay-Kommunikation ..................................................... 23
7
MICROSAR.LIN – AUTOSAR Basissoftware-Module für die LIN-Kommunikation ............................................................ 26
8
MICROSAR.ETH – AUTOSAR Basissoftware-Module für Ethernet-basierte Kommunikation ........................................ 29
9
MICROSAR V2G – Basissoftware-Module für die Kommunikation mit externer Infrastruktur ....................................... 34
10
MICROSAR AVB – Basissoftware-Module für die Audio/Video-Kommunikation via Ethernet ....................................... 37
11
MICROSAR.MEM – AUTOSAR Basissoftware-Module für das Memory Management..................................................... 40
12
MICROSAR.SYS – Systembezogene Basissoftware Module für AUTOSAR ...................................................................... 43
13
MICROSAR.DIAG – AUTOSAR-kompatible Umsetzung des UDS-Protokolls .................................................................... 47
14
MICROSAR.MCAL – AUTOSAR-Treiber zur Ansteuerung der Mikrocontroller-Peripherie ............................................... 52
15
MICROSAR.EXT – AUTOSAR-Treiber zur Ansteuerung von externen Bausteinen ............................................................ 56
16
MICROSAR.IO – AUTOSAR Input Output Hardware Abstraktion ...................................................................................... 58
17
MICROSAR.RTE – Die optimierte Ablaufumgebung für Softwarekomponenten nach dem AUTOSAR-Standard ........ 61
18
MICROSAR AMD – AUTOSAR-Monitoring und -Debugging ................................................................................................ 64
19
MICROSAR Safe – Sicherheit nach ISO 26262 bis ASIL D für Steuergeräte-Software.................................................... 68
20
MICROSAR Security – Zugriffs-Sicherheit für AUTOSAR-Steuergeräte ........................................................................... 71
21
MICROSAR Multi-core – Die AUTOSAR Lösung für Mehrkern-Prozessoren .................................................................... 74
22
MICROSAR Variantenhandling - Lösungen für die flexible Konfigurationen in AUTOSAR ............................................... 77
23
MICROSAR J1939 – AUTOSAR Basissoftware-Module speziell für Nutzfahrzeuge ......................................................... 80
24
MICROSAR VTT – Virtuelle Integration mit vVIRTUALtarget Basic ................................................................................... 82
25
MICROSAR.SIP und MICROSAR.EIP – Der Schnelleinstieg in Ihr AUTOSAR Projekt ........................................................ 86
26
AUTOSAR Eval Package – Komplettpaket zur Evaluierung von AUTOSAR-Basissoftware und -Tools .......................... 90
27
Weiterführende Informationen ............................................................................................................................................... 94
V2.2 09/2016
Bitte denken Sie über Ihre Verantwortung gegenüber der Umwelt nach, bevor Sie dieses Dokument ausdrucken.
2
MICROSAR
1
MICROSAR - Die Vector Lösung für AUTOSAR Steuergeräte-Software
MICROSAR ist die AUTOSAR-Lösung von Vector für Ihre Steuergeräte-Software. MICROSAR besteht aus der
MICROSAR.RTE und den MICROSAR Basissoftware-Modulen (BSW), die den gesamten Umfang des AUTOSAR-Standards
sowie viele Erweiterungen abdecken. Jedes AUTOSAR BSW-Modul ist einem MICROSAR-Paket zugeordnet. Die detaillierten
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.
1.1
Liste der verfügbaren MICROSAR Pakete
Bild 1: Die MICROSAR Pakete enthalten alle Module des AUTOSAR 4.2 Standards.
MICROSAR beinhaltet die folgenden Teilpakete:
Paket
Inhalt
MICROSAR AMD
Monitoring und Debugging von Anwendung und MICROSAR-BSW
MICROSAR AVB
Basissoftware-Module für die Audio/Video-Kommunikation via Ethernet
MICROSAR MCAL
Treiber zur Ansteuerung der Mikrokontroller-Peripherie
MICROSAR CAN
Basissoftware-Module für die CAN-Kommunikation
MICROSAR COM
Basissoftware-Module für die Netzwerk-unabhängige Kommunikation und Gateways
MICROSAR EXT
Treiber zur Ansteuerung von externen Bausteinen
MICROSAR FR
Basissoftware-Module für die FlexRay-Kommunikation
MICROSAR DIAG
Basissoftware-Module für die Diagnose
MICROSAR.IO
Bindeglied zwischen Mikrokontroller-Peripherie und Anwendung
MICROSAR ETH
Basissoftware-Module für Ethernet-basierte Kommunikation
MICROSAR.LIBS
AUTOSAR-Libraries
MICROSAR.LIN
Basissoftware-Module für die LIN-Kommunikation
MICROSAR.MEM
Basissoftware-Module für die Verwaltung von nichtflüchtigem Speicher
3
MICROSAR
Paket
Inhalt
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
1.2
Anwendungsgebiete
Die BSW-Module aus den MICROSAR-Paketen sichern die Grundfunktionalität des Steuergeräts. Sie enthalten die
Implementierung der AUTOSAR-Standardservices, die Sie für Ihre Funktionssoftware benötigen. Weil die AUTOSARArchitektur eine konsequente Hardware-Abstraktion verfolgt, können Sie mit MICROSAR Ihre Funktionssoftware plattformunabhängig entwickeln.
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 ControllerDerivats 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. die Diagnose-Module.
Alle benötigten MICROSAR BSW-Module konfigurieren Sie entsprechend der Anforderungen aus Ihrem Projekt und
integrieren 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 BRE
(Basic Runtime Environment) optional unterstützt. BRE 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 BRE beschleunigt und vereinfacht
somit den Aufbau von AUTOSAR 4 basierten Projekten, welche keine RTE verwenden.
1.3
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
4
MICROSAR
1.4
Serieneinsatz
Die MICROSAR BSW-Module werden bereits in 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.5
Unterstützung von AUTOSAR 4.x und 3.x
Sowohl für AUTOSAR 4.x als auch für 3.x erhalten Sie von Vector die komplette Basissoftware aus einer Hand. Bei der
Migration Ihrer Projekte profitieren Sie von einem einheitlichen Entwicklungsworkflow für AUTOSAR 4.x und 3.x:
> Die Konfigurationswerkzeuge DaVinci Developer und DaVinci Configurator Pro sind für beide Releases ausgelegt. Somit
vermeiden Sie einen Werkzeugwechsel.
> MCAL-Treiber aus unterschiedlichen AUTOSAR-Releases lassen sich mit MICROSAR kombinieren.
Im Falle einer Migration von AUTOSAR 3 nach 4 unterstützen wir Sie bei der Anpassung Ihrer Anwendungssoftware an die im
AUTOSAR 4.x-Standard geänderten Schnittstellen.
Ein weiterer Vorteil von MICROSAR liegt in den vielen Erweiterungen in den BSW-Modulen für AUTOSAR 3.x, die erst in
AUTOSAR 4.x spezifiziert sind. Beispiele hierfür sind das Multi-Core Betriebssystem, sowie die Unterstützung für J1939, XCP
und Ethernet/IP.
1.6
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
AUTOSAR-Werkzeuge von Vector (DaVinci) 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 frühzeitig die Gültigkeit einzelner Parameter sowie komplexer
Parametergruppen untereinander. Bei ungültigen Konfigurationen bieten sie – wenn möglich – Korrekturvorschläge an. Diese
Erweiterung der AUTOSAR-Methode vereinfacht die Integration der Basissoftware in Ihr Steuergerät und reduziert die
Integrationszeit.
Die DaVinci–Werkzeuge unterstützen Sie optimal bei der Konfiguration der RTE und der BSW-Module. In einem Bottom-upProzess werden beispielsweise die SWC Service-Ports (inkl. Runnables) automatisch passend zur BSW-Konfiguration
erzeugt. Diese Automatisierung nimmt Ihnen Aufgaben ab, die sich häufig wiederholen und bei manueller Durchführung
fehleranfällig sind. Sie sparen damit Zeit und Kosten.
5
MICROSAR
Bild 2: Mit dem DaVinci Configurator Pro konfigurieren Sie die BSW-Module und die RTE.
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.7
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.
6
MICROSAR
1.8
AUTOSAR Monitoring and Debugging (AMD)
Das Paket AMD vereinfacht den Test und die Analyse von BSW und Anwendungs-Funktionen, indem wichtige
Statusinformationen und Ereignisse an Tools wie CANape oder CANoe.AMD zur Auswertung übertragen werden. Zusätzlich
bietet AMD die Möglichkeit, Laufzeitmessungen an der BSW und Anwendungs-Funktionen durchzuführen. Weitere
Informationen erhalten Sie im Kapitel über MICROSAR AMD.
1.9
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.10 Steuergeräte-Varianten und Nachladen der BSW-Konfiguration
Um Logistikkosten bei AUTOSAR-Steuergeräten einzusparen, sind die MICROSAR Module mit der Option Identity Manager
erhältlich. Mit dieser Option werden mehrere Konfigurationen (z.B. Linke- oder rechte Tür) im Steuergerät abgelegt. Dies
ermöglicht den mehrfachen Verbau eines identischen Steuergerätes innerhalb einer Baureihe oder in unterschiedlichen
Baureihen.
Die BSW-Option „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.
Weitere Informationen erhalten Sie im Kapitel "MICROSAR Variantenhandling".
1.11 Funktionale Sicherheit nach ISO 26262: MICROSAR Safe
Für den Einsatz der MICROSAR BSW in sicherheitsrelevanten Funktionen bietet Vector zusammen mit TTTech Automotive
eine komplette Lösung für Ihr AUTOSAR-Steuergerät. Weitere Informationen entnehmen Sie bitte dem Kapitel über
MICROSAR Safe.
1.12 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
Konfiguration der MICROSAR Module empfehlen wir unseren DaVinci Configurator Pro. Details hierzu erfahren Sie in der
separaten Produktinformation.
1.13 Optionale Lieferung von Sourcecode
Die MICROSAR Module sind auf Anfrage auch als Sourcecode erhältlich. Der Sourcecode ermöglicht Pre-compileOptimierungen und vereinfacht das Testen.
1.14 Lizenz und Wartung
Vector bietet Ihnen eine flexible Lizenzierung - individuell nach Ihren Anforderungen. Im Rahmen eines Pflegevertrags
erhalten Sie Software-Updates und bleiben damit auf dem aktuellen Stand der Entwicklung.
1.15 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
7
MICROSAR
> 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.16 Die komplette AUTOSAR-Lösung von Vector
Die AUTOSAR-Lösung von Vector besteht aus den DaVinci Werkzeugen, der MICROSAR-Basissoftware und der
MICROSAR.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.17 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: embedded@de.vector.com
> Telefon: +49 711 80670-400
1.18 Schulungen
Im Rahmen unseres Schulungsangebotes bieten wir Ihnen für MICROSAR verschiedene Schulungen und Workshops in
unseren Seminarräumen sowie inhouse bei Ihnen an. Mehr Informationen zu den einzelnen Schulungen und die Termine finden
im Internet unter www.vector-academy.de.
8
MICROSAR
2
MICROSAR.OS – Das Echtzeitbetriebssystem von Vector für den AUTOSAR-Standard
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.
Bild 4: MICROSAR.OS Modul nach AUTOSAR 4.2
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
> Optional: Als Multi-core Betriebssystem verfügbar
> Optional: Sicherer Kontextwechsel nach ISO26262 / ASIL D
> Qualitätsprozess nach SPICE Level 3
> Grafisches Konfigurationswerkzeug zum einfachen Konfigurieren des Betriebssystems
> Verfügbar für viele 8-, 16-, 32- und 64-Bit-Mikrocontroller
2.2
Eigenschaften
MICROSAR-OS basiert auf der AUTOSAR-OS-Spezifikation, einer Erweiterung des praxiserprobten BetriebssystemStandards OSEK/VDX-OS. Dieser Standard wurde um Funktionen für Zeitüberwachung und Speicherschutz erweitert. So
bietet der implementierte High Resolution Timer Mechanismus Zeitauflösungen von weniger als 1ms ohne Erhöhung der
Interrupt-Last. In Abhängigkeit vom Controller sind damit Auflösungen bis in den Mikrosekundenbereich möglich.
Die Implementierung von MICROSAR.OS durch Vector erfolgt in voller Konformität mit der AUTOSAR-OS-Spezifikation und
unter-stützt alle Skalierbarkeitsklassen:
> SC1: Echtzeitbetriebssystem, implementiert nach dem OSEK/VDX-OS Standard und erweitert um Schedule Tables
> SC2: Echtzeitbetriebssystem mit Zeitsynchronisation und Überwachung des zeitlichen Verhaltens einzelner Tasks und
Interrupt Service Routinen
9
MICROSAR
> SC3: Echtzeitbetriebssystem mit Speicherschutzmechanismen auf Mikrocontrollern mit entsprechender HardwareUnterstützung
> SC4: Kombination der Skalierbarkeitsklassen SC2 und SC3
2.3
Optionale Erweiterungen
2.3.1 Synchronisation mit der globalen Systemzeit
Schedule Tables können mit der globalen Systemzeit synchronisiert werden, die z. B. über den FlexRay-Bus übertragen wird.
Dadurch erreichen Sie die synchronisierte und gleichzeitige Ausführung von Aufgaben in einem verteilten System.
2.3.2 Speicherschutz (SC3, SC4)
Der Speicherschutz stellt sicher, dass Anwendungskomponenten sich nicht gegenseitig die Daten zerstören. Dadurch wird die
Integration von Anwendungen einfacher und zuverlässiger.
2.3.3 Timing Protection (SC2, SC4)
Durch die Timing Protection wird sichergestellt, dass die während der Entwurfsphase getroffenen Annahmen hinsichtlich der
Ausführungszeit eingehalten werden. Ein defekter Anwendungsteil kann somit die Laufzeit der anderen laufenden Prozesse
nicht beeinträchtigen.
2.3.4 Laufzeit Messungen (SC2, SC4)
Mit den Funktionen der Skalierbarkeitsklassen 2 und 4 können Sie die Ausführungszeiten und die Interrupt Sperrzeiten von
Anwendungen messen. Diese Messdaten können später als praxis-basierte Werte beim Entwurf und bei der Integration
künftiger Anwendungen verwendet werden.
2.4
Betriebssystem für Anwendungen nach ISO26262
Für sicherheitsrelevante Anwendungen nach ISO 26262 erhalten Sie von Vector die nach ASIL D entwickelte BetriebssystemVariante MICROSAR.OS SafeContext. Sie basiert auf den AUTOSAR-Skalierbarkeitsklassen SC3 bzw. SC4 und ist zuständig
für den Speicherschutz und einen sicheren Kontextwechsel. Um „Freedom from Interference“ in Hinsicht auf Speicherschutz
zu erreichen, benötigen Sie einen geeigneten Prozessor, z.B. mit Memory Protection Unit (MPU).
Mit MICROSAR.OS SafeContext können Sie sicherheitsrelevante
Standardkomponenten auf derselben CPU verwenden.
Anwendungskomponenten
zusammen
mit
Lieferumfang für MICROSAR.OS SafeContext:
> Betriebssystem-Kern als Sourcecode
> Grafisches Konfigurationstool für Windows 7 / Windows XP
> Kommandozeilen-basierter Generator
> Beschreibungsdateien für DaVinci Configurator Pro
> Dokumentation
> Read-back Tool
> Safety Manual
Mehr Details über die Vector Lösung für Safety entnehmen Sie bitte dem Kapitel über MICROSAR Safe.
2.5
Multi-Core Betriebssystem
MICROSAR.OS Multi-Core ist eine Weiterentwicklung des bewährten Echtzeitbetriebssystems MICROSAR.OS von Vector.
Sie setzen es überall dort ein, wo ein Mehrkern-System nach AUTOSAR-Spezifikation entwickelt werden soll. MICROSAR.OS
Multi-Core basiert auf der AUTOSAR-Spezifikation 4.x, kann aber auch in AUTOSAR 3.x Projekten eingesetzt werden.
10
MICROSAR
2.5.1 Funktionen des Multi-Core Betriebssystems
Das Multi-Core Betriebssystem ermöglicht den parallelen und unabhängigen Betrieb mehrerer Prozessorkerne mit jeweils
einer eigenen Instanz des AUTOSAR-Betriebssystems. Dabei entsprechen Konfiguration und Systemdienste denen des
Single-Core Betriebssystems. Es sind auch die gleichen Erweiterungen, SC2 bis SC4 sowie High Resolution Timing, erhältlich.
Zusätzlich bietet die Multi-Core-Variante Mechanismen zum Koordinieren und Synchronisieren von Tasks, die auf
unterschiedlichen Kernen ablaufen.
2.5.1.1
Synchronisierter Start-up
Das Betriebssystem stellt sicher, dass alle Kerne hochgefahren und initialisiert sind, bevor die jeweilige Anwendung gestartet
wird.
2.5.1.2
Inter-Core Koordination
Prozesse auf unterschiedlichen Kernen werden über Task-Aktivierungen, das Setzen von Events, das Starten und Anhalten
von Alarmen oder ScheduleTables synchronisiert.
2.5.1.3
Shared Resource Access
Soll von unterschiedlichen Kernen auf gemeinsam genutzte Ressourcen zugegriffen werden, so stellt das Betriebssystem mit
Spinlocks einen Koordinationsmechanismus bereit.
2.5.1.4
Inter-Core Kommunikation
Für den konsistenten Datenaustausch zwischen zwei Kernen stellt das Betriebssystem mit dem Inter-OS-ApplicationCommunicator (IOC) eine effiziente Schnittstelle zur Verfügung.
2.6
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
Integration in eine automatisierte Entwicklungsumgebung zu ermöglichen.
2.7
Lieferumfang
Der Lieferumfang von MICROSAR.OS umfasst:
> Betriebssystem-Kern als Sourcecode
> Grafisches Konfigurationstool für Windows XP / Windows 7
> Kommandozeilen-basierter Generator
> Beschreibungsdateien für DaVinci Configurator Pro
> Dokumentation
11
MICROSAR
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äteKommunikation. 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ändige Einbindung der busspezifischen Kommunikationsmodule für CAN, CAN-FD, J1939, FR, LIN und ETH in die
Steuergerätesoftware.
Bild 5: Die MICROSAR.COM Module nach AUTOSAR 4.2
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)
3.2
Anwendungsgebiete
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
MICROSAR.COM ermöglichen das Routing von Signalen sowie von TP- oder Applikations-Botschaften.
12
MICROSAR
3.3
Funktionen
Die BSW-Module aus MICROSAR.COM enthalten die in AUTOSAR 4.x definierten Funktionen:
> 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
Funktionssoftware in PDUs.
> Der PDU Router (PDUR) stellt den Modulen COM, DCM und den Complex Drivers eine Schnittstelle zu den
Kommunikationsmodulen (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 zwischen 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
> 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
Kommunikationskanäle.
> 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.
> 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
Übertragung kann hierbei auch der LDCOM eingesetzt werden.
> E2EXF: Ermöglicht die End-To-End Verschlüsselung für Netzwerk-Kommunikation beim Einsatz des AUTOSAR
transformer concept (also mithilfe der Serialisierung durch COMXF oder SOMEIPXF).
> SecOC: Informationen zur Secured OnBoard Communication (SecOC) entnehmen sie bitte dem Kaptiel "MICROSAR
Security".
Über den AUTOSAR-Standard hinaus beinhaltet MICROSAR.COM die folgenden wichtigen Dienste:
> COM: Ungültigkeitserklärung von TX-Signalen bei RX-Signal Timeout
> COM: Optimierungen zur Reduktion der Mainfunction Laufzeiten (Empfangsseitig: Cachen von Empfangsereignissen,
Sendeseitig: Konfiguration mehrerer Zeitdomänen.)
> COM: 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.
> COM, PDUR & IPDUM : Pre-Compile und Post-build loadable Optimierungen wie z.B. das Finden und Entfernern
redundanter Daten
> NM: Synchrones sleep und wake-up von mehreren Netzwerken über unterschiedliche NM-Koordinatoren
> NM: Backup Koordinator
Die folgenden Funktionen sind optional erhältlich:
> COM: PDU-Replication (für AUTOSAR 4.x)
> 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.
> NM: Unterstützung von OSEK NM (konfigurierbar)
> NM: Mischbetrieb von OSEK- und AUTOSAR-NM auf einem Kanal
13
MICROSAR
> PDUR: Unterstützung für
> TP- und Botschafts-Routing,
> Routing anhand von Metadaten beim Range-Routing
> Routen von variablen Adressen ("dynamisches Gateway")
> Routen von dynamischen PDU-Längen.
> Post-build loadable und Post-build selectable: Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling ".
> Gateway Mirroring: Diese Funktion erlaubt das Spiegeln von internen Bussen auf den Diagnosezugang. Dadurch ist es
möglich, die normalerweise 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. Mit den
beiden optionalen Erweiterungen ist es zusätzlich möglich,
> mehrere interne CAN, LIN, FlexRay und ETH Kanäle auf den Diagnose Ethernet zu spiegeln
> CAN, LIN oder FlexRay Kanäle auf den Diagnose CAN oder Diagnose FlexRay zu spiegeln.
> High End Features: 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 Gateway-Option.
3.4
Konfiguration
Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Mehr Details finden Sie in der
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.
Bild 6: Konfiguration der Kommunikationsmodule mit dem DaVinci Configurator Pro
14
MICROSAR
4
MICROSAR Gateway – Basissoftware für Gateway Steuergeräte
Gateway Steuergeräte sind zentrale Knotenpunkte in der oft heterogenen Netzwerkarchitektur eines Fahrzeugs. In dieser
Rolle verbindet ein Gateway die verschiedenen Netzwerke, um die Datenübertragung zwischen verteilten Steuergeräten auch
über unterschiedliche Netzwerktypen hinweg zu ermöglichen. Die Leistungsindikatoren eines Gateways bewegen sich dabei
im Spannungsfeld zwischen hohen Datendurchsätzen sowie geringer Ressourcenbelastung (insb. RAM und CPU Auslastung)
und niedrigen Latenzzeiten bei der Übertragung.
Vector bietet für Gateways optimierte Module, die sowohl ein Routing auf unterschiedlichen Protokollebenen als auch
zwischen unterschiedlichen Bus-Systemen (CAN, LIN, FlexRay, Ethernet) ermöglicht. Aufbauend auf diesen Basisfunktionen
bietet MICROSAR Gateway eine Reihe von Sonderfunktionen, beispielsweise zur Spiegelung von Sub-Netzwerken und ein
modulares Plug-In Konzept zur Erweiterung der vorhandenen Funktionalität. Durch dieses dreistufige Konzept aus
Basisfunktionalität, Sonderfunktionen und Erweiterbarkeit bietet MICROSAR Gateway die nötige Flexibilität um spezifische
Anwendungsfälle 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 7: Multi-Layer Gateway in MICROSAR
4.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 (CDDsupport)
> Optional begleitender Support von Gateway-Projekten durch Vector in enger Zusammenarbeit mit dem Tier1
15
MICROSAR
4.2
Anwendungsgebiete
MICROSAR Gateway bietet dem Anwender die notwendige Basissoftware, um Daten auf der jeweils optimalen
Protokollebene zwischen CAN-, LIN-, FlexRay- und Ethernet-Netzwerken zu routen. Dieser flexible Ansatz erlaubt den Einsatz
von MICROSAR Gateway in der Entwicklung von
> lokalen Gateways (beispielsweise im Türbereich)
> Domänencontroller (zum Beispiel Body Controller)
> zentralen Gateways (beispielsweise als zentraler Diagnosezugang oder für Connectivity-Anwendungen).
4.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überschreitungen, 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überschreitungen, minimaler Sendeabstand, etc.)
> Möglichkeit zur Durchführung von Konvertierungen (Endianess, Signallänge, Signalinhalte)
> Unterstütze Netzwerke: Netzwerkunabhängiges Routing
16
MICROSAR
Bild 8: Routing auf unterschiedlichen Protokollebenen
> Erweiterbare Basissoftware (Plug-In Architektur)
> Effiziente Integration von eigener Software in den Datenfluss (realisiert über Complex Device Driver (CDD) nach
AUTOSAR)
> 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
werden
> Callouts zur Integration von eigener Software in den Kontrollfluss (oft auch mit der Möglichkeit die Daten zu
beeinflussen)
> 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
Variantenhandling".
17
MICROSAR
4.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
explizite Spezifikation von Routinginformationen. Diese werden von DaVinci Configurator Pro eingelesen und in eine
Softwarekonfiguration 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
Routinginformationen abzuleiten.
> Konfiguration über proprietäre Daten (z.B. .xls): Die Werkzeugkette von Vector bietet zusätzlich die Möglichkeit,
Routinginformationen über eine separate Zusatzdatei zu definieren. Diese Datei erlaubt es, in einem von Vector
spezifizierten XML Format (Vector System Description Extension, VSDE) Nachrichten und Signale aus den
Netzwerkdateien zueinander 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
DaVinci Configurator Pro Option WF (Workflow) erstellen Sie spezifische Scripte für Ihr Projekt, über die Sie
programmatisch Routinginformationen ergänzen.
Die mit diesen Verfahren erzeugte Softwarekonfiguration ist dabei kein einmaliger Vorgang. Sollten sich die
Netzwerkbeschreibung in den Eingangsdateien ändern, lässt sich die Softwarekonfiguration automatisch aktualisieren.
Bild 9: 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
bearbeitet
werden.
Mehr
Details
hierzu
finden
Sie
in
der
separaten
Produktinformation
unter
http://vector.com/vi_davinci_configurator_pro_de.html.
4.5
Projektsupport
An Gateway Steuergeräte werden besonders häufig sowohl OEM-spezifische als auch anwendungsspezifische
Anforderungen gestellt, die ein Standardprodukt in der Regel nicht vollumfänglich erfüllt. Um diese Anforderungen in ihrem
Projekt dennoch effizient abzubilden, bietet Vector einen zweistufigen Ansatz:
> Zunächst unterstützt MICROSAR Gateway eine Vielzahl von Erweiterungsmöglichkeiten im Sinne einer Plug-In
Architektur, 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
18
MICROSAR
Kundenanforderungen, als dies in einem durch Release-Zyklen geprägten Produktansatz möglich ist. Innerhalb eines
gemeinsamen Projekts implementieren wir dann gerne auch die zur Erfüllung der Kundenanforderungen notwendigen
Produkterweiterungen.
Bild 10: Dreischichtige Herangehensweise zur optimalen Entwicklungsunterstützung
19
MICROSAR
5
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 11: Die MICROSAR.CAN Module nach AUTOSAR 4.2
5.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 Controller.
5.2
Anwendungsgebiete
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.
20
MICROSAR
5.3
Funktionen
Die BSW-Module in MICROSAR.CAN enthalten die in AUTOSAR 4.x definierten Funktionen. Über den Standard hinaus
beinhaltet MICROSAR.CAN die folgenden wichtigen Dienste:
> CANIF: Double Hash Search Algorithmus zur effizienten Filterung der Empfangsbotschaften
> CANNM, CANTP: Pre-Compile Optimierungen z.B. für Einkanalsysteme
> CANSM: Unterstützung des ECU Passive Mode
> CANTP: Unterstützt Mixed Addressing (11 bit CAN ID); typischerweise für CAN/LIN Gateway Anwendungen
> CANTP: Optimiertes Routing mit z.B. Burst Transmission zusammen mit dem PDUR aus MICORSAR COM
> CANTP: Konfigurierbare Kompatibilität zu ISO 15765-2
> CANTSYN: 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.
Folgende Funktionalitäten sind optional erhältlich:
> J1939: Netzwerkmanager J1939NM, Request Manager J1939RM, Diagnosemodul J1939DCM und in J1939TP die
Transport Protokolle BAM und CMDT für J1939-Netzwerke
> CAN-Treiber: Erhöhen der Full CAN Objekte durch Kombination von mehreren CAN-Controllern auf einem physikalischen
CAN-Bus (Common CAN)
> Für CANIF: Unterstützung eines externen CAN-Controllers
> Post-build loadable und Post-build selectable: Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling ".
5.4
Konfiguration
5.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ältlichen 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 BSWModule:
> 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.
5.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
Verwendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für CAN-Steuergeräte enthält
MICROSAR 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
Generische Messen erfordert die Verwendung von CANoe.AMD oder CANape als XCP Tools.
21
MICROSAR
> 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.
> Weitere Informationen zu J1939-Steuergeräte in Nutzfahrzeugen finden Sie im Kapitel "MICROSAR J1939".
5.7
Die Vector Toolchain für die Entwicklung von CAN-Steuergeräten
Bild 12: Vector bietet Ihnen ein umfassendes Portfolio für Ihre CAN-Projekte
22
MICROSAR
6
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 13: Die MICROSAR.FR Module nach AUTOSAR 4.2
6.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
6.2
Anwendungsgebiete
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.
6.3
Funktionen
Die BSW-Module in MICROSAR.FR enthalten die in AUTOSAR 4.x definierten Funktionen, wobei FRISOTP eine Ergänzung zu
AUTOSAR 3.x ist. Über den Standard hinaus beinhaltet MICROSAR.FR die folgenden wichtigen Dienste:
> FRDRV: Optimiertes Wakeup During Operation (WUDOP)
> FRDRV & FRIF: Unterstützung der folgenden APIs: CancelTransmit und L-PDU-Rekonfiguration
23
MICROSAR
> FRIF: Dual Channel Redundancy für die redundante Übertragung von Frames sowie PDU-spezifische Voting-Funktion für
die SWCs
> FRDRV, FRIF, FRNM, FRTP: Pre-Compile Optimierungen z.B. für Einkanalsysteme
> FRSM: 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
> FRTSYN: Time Synchronization over FlexRay (FRTSYN) implementiert das Generalized Precision Time Protokoll (gPTP)
nach IEEE 802.1AS. Damit kann eine Uhrensynchronisation zwischen FR-Steuergeräten realisiert werden. Als
übergeordneter Zeit-Koordinator steht das BSW-Modul Synchronized Time Base Manager (STBM) aus MICROSAR.SYS
zur Verfügung.
> Postbuild loadable und Postbuild selectable: Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling".
6.4
Betriebssystem
Die FlexRay Basissoftware-Module können ganz ohne Betriebssystem verwendet werden. Sinnvollerweise wird ein AUTOSAROS oder ein konventionelles OSEK-OS (z.B. Vector osCAN) verwendet. Ideal geeignet für FlexRay-Anwendungen ist das
MICROSAR.OS von Vector.
6.5
Konfiguration
6.6
Weitere MICROSAR Produkte für einen kompletten FlexRay-Kommunikations-Stack
Entsprechend der AUTOSAR-Architektur bildet MICROSAR.FR zusammen mit den BSW-Modulen aus den separat
erhältlichen Paketen MICROSAR.COM, MICROSAR.MCAL, MICROSAR.SYS und MICROSAR.EXT einen kompletten
Kommunikations-Stack für FlexRay. Für die Anbindung von MICROSAR.FR an die Applikation und an die Hardware benötigen
Sie noch folgende BSW-Module:
> Hardwarespezifischen FlexRay-Treiber (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.
6.7
Weitere MICROSAR Produkte für FlexRay
> MICROSAR XCP erlaubt gemäß ASAM XCP das Messen und Kalibrieren. MICROSAR.XCP wurde dabei besonders auf die
Verwendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für FlexRay-Steuergeräte enthält
MICROSAR XCP die passende Transportschicht FRXCP.
nicht gestattet.
24
MICROSAR
6.8
Die Vector Toolchain für die Entwicklung von FlexRay-Steuergeräten
Bild 14: Vector bietet Ihnen ein umfassendes Portfolio für Ihre FlexRay-Projekte
25
MICROSAR
7
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 TransportProtokoll 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 15: Die MICROSAR.LIN Module nach AUTOSAR 4.2
7.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
7.2
Anwendungsgebiete
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.
7.3
Funktionen
Die BSW-Module aus MICROSAR.LIN enthalten die in AUTOSAR 4.x definierten Funktionen. Über den Standard hinaus
enthält MICROSAR.LIN die folgenden wichtigen Dienste:
> LINIF: Konfigurierbares Wakeup Delay
26
MICROSAR
> LINIF und LINTP: Getrennt konfigurierbares Speicher-Mapping der Konfigurationsdaten von LINIF und LINTP. Dies ist für
Controller mit segmentiertem Speicher besonders interessant. Dazu sind im Lieferumfang von MICROSAR.LIN zwei
getrennte Generatoren für LINIF und LINTP enthalten.
> LINIF/LINSM: Benachrichtigung über Schedule Table End
> LINIF: konfigurierbare schedule tables zur Reduzierung der maximalen Task-Laufzeiten bei mehrkanaligen Systemen
> LINIF: Wakeup über den LIN-Tranceiver. Nach einem externen Wecken entfällt durch diese Funktion das Versenden eines
(unerwünschten) zweiten WakeUp-Pulses durch den Master.
> LINSM: Erweiterte Abfrage der LINSM Sub-Modi für die kontrollierte Umschaltung der LIN Schedule Tables
> LINSM: Optimiertes Startup Verhalten durch automatische Auswahl einer Schedule Table (konfigurierbar;)
> LINIF: LINTP-Implementierung für die segmentierte Übertragung von z.B. UDS Diagnose Kommunikation
> LINTP: Erweiterung der Gateway-Funktionalität zum exakten Umschalten der Schedule Tables bei Diagnose-Anfragen
und –Antworten
> Postbuild loadable und Postbuild selectable: Details hierzu finden Sie im Kapitel "MICROSAR Variantenhandling.
7.4
Konfiguration
7.5
Weitere MICROSAR Produkte für einen kompletten LIN-Kommunikations-Stack
Entsprechend der AUTOSAR-Architektur bildet MICROSAR.LIN zusammen mit den BSW-Modulen aus den separat
erhältlichen Paketen MICROSAR.COM, MICROSAR.MCAL und MICROSAR.EXT einen kompletten Kommunikations-Stack für
LIN. Für die Anbindung von MICROSAR.LIN an die Applikation und an die Hardware benötigen Sie noch folgende BSWModule:
> 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.
7.6
Weitere relevante MICROSAR Produkte für LIN
Verwendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für LIN-Steuergeräte enthält
MICROSAR XCP die passende Transportschicht LINXCP. Da XCP-on-LIN nicht offiziell definiert ist, handelt es sich bei
dieser XCP-on-LIN-Implementierung um eine Erweiterung des ASAM Standards.
nicht gestattet.
27
MICROSAR
7.7
Die Vector Toolchain für die Entwicklung von LIN-Steuergeräten
Bild 16: Vector bietet Ihnen ein umfassendes Portfolio für Ihre LIN-Projekte
28
MICROSAR
8
MICROSAR.ETH – AUTOSAR Basissoftware-Module für Ethernet-basierte Kommunikation
Mit dem Internet Protokoll und den darüber liegenden 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 sowie einen nach Automotive-Standard
entwickelten TCP/IP-Stack 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 17: Die MICROSAR.ETH BSW-Module nach AUTOSAR 4.2
8.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 (MICROSAR
AVB) in den AUTOSAR Ethernet- und TCP/IP-Stack
> Einfache Einbindung kundenspezifischer Funktionen/Module auf allen Ebenen
8.2
Anwendungsgebiete
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.
Durch den größeren Datendurchsatz von Ethernet lassen sich die gesamten Software-Download- und Diagnose-Zeiten
erheblich verkürzen. Ein im Fahrzeug vorhandenes Gateway kann die Diagnoseanfragen an Fahrzeug-interne Netzwerke
weiterleiten. Damit können Sie über DoIP beispielsweise mehrere CAN-Steuergeräte parallel re-programmieren. In
29
MICROSAR
Kombination mit weiteren MICROSAR-Paketen realisiert MICROSAR.ETH die dafür benötigte Gateway-Funktionalität. Wird
MICROSAR.ETH im Flash Bootloader (FBL) eingesetzt, kann ein Steuergerät, das mit dem Ethernet-Netzwerk verbunden ist
(z.B. das Gateway selbst), direkt über DoIP re-programmiert werden.
Zum Messen und Kalibrieren von Ethernet-Steuergeräten steht Ihnen MICROSAR XCP on Ethernet zur Verfügung, mit dem
Sie auch hier von der erhöhten Bandbreite profitieren. XCP-Routing erweitert ein Gateway um die Möglichkeit, über den
Ethernet-(Fahrzeug-)Zugang auch CAN- und FlexRay-Steuergeräte mittels XCP zu kalibrieren.
Neben den Anwendungsgebieten Diagnose, Messen und Kalibrieren, bei denen die Ethernet-basierte Kommunikation
zwischen externer Infrastruktur und dem Fahrzeug stattfindet, bietet MICROSAR.ETH auch die Möglichkeit, Fahrzeuginterne Ethernet-Netzwerke effizient zu nutzen. Mittels "scalable service oriented middleware over IP" (SOME/IP) können
Sie beispielsweise Daten Service-orientiert übertragen. Für die Verwaltung von Services kommt unter anderem das BSWModul Service Discovery (SD) zum Einsatz, das mit AUTOSAR 4.1.1 eingeführt wurde. Neben der reinen Service-Orientierung
bietet SOME/IP auch eine dynamische Datenserialisierung, deren Implementierung als RTE-Transformer zur Verfügung steht.
Weitere Informationen zum SOME/IP-Transformer finden Sie in den Kapiteln zu MICROSAR.RTE und MICROSAR.COM.
Natürlich können Sie Daten auf Ethernet weiterhin auch Signal- und PDU-basiert übertragen.
Teile aus MICROSAR.ETH dienen außerdem als Basis für die Vehicle-to-Grid-Kommunikation und das Audio/Video Bridging.
Weitere Details zu diesen Anwendungsgebieten finden Sie in den Kapiteln zu MICROSAR.V2G und MICROSAR.AVB.
8.3
Funktionen
Die folgenden BSW-Module aus MICROSAR.ETH enthalten die in AUTOSAR 4.2 definierten Funktionen. Für den Einsatz in
einem AUTOSAR 4.1, 4.0 oder AUTOSAR 3.x Software-Stack verfügen sie über entsprechend kompatible Schnittstellen:
> ETHIF: 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 VLANBehandlung zuständig. Die Hardware-unabhängige Ansteuerung von Ethernet-Switch-Treibern (ETHSWTDRV und
ETHSWTDRV EXT) ist seit AUTOSAR 4.2 Bestandteil des ETHIF.
> ETHSM: 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.
> ETHTSYN: Time Synchronization over Ethernet (ETHTSYN) implementiert das generalized Precision Time Protokoll
(gPTP) nach IEEE 802.1AS. Damit kann eine Uhrensynchronisation zwischen Ethernet-Steuergeräten realisiert werden.
> ETM: Das Ethernet Testability Module (ETM) implementiert eine standardisierte Gegenstelle für ProtokollKonformitätstests. Über dieses Modul kann eine extern angeschlossene Testumgebung definierte Aktionen im TCP/IPStack auslösen, wie beispielsweise das Versenden eines UDP Pakets oder der Aufbau einer TCP-Verbindung. Das ETMModul wird in AUTOSAR 4.3 spezifiziert und ist bereits als Vorabversion verfügbar.
> TCPIP: 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:
> IPv4, ICMPv4, ARP und DHCPv4 (Client)
> IPv6, ICMPv6, NDP und DHCPv6 (Client)
> UDP und TCP
Unter Umständen werden für manche Anwendungsfälle, beispielsweise bei der Kommunikation mit Fahrzeug-externer
Infrastruktur, zusätzliche Funktionen eines TCP/IP-Stacks benötigt. Hierfür sind zwei TCPIP Add-ons verfügbar, welche
die nachfolgend aufgeführten IETF RFCs beinhalten:
> IPv6 Extensions
> RFC3810 “Multicast Listener Discovery Version 2 (MLDv2) for IPv6” (RFCs 2710, 2711, 3590)
> RFC4941 “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”
30
MICROSAR
> TCP Extensions
> RFC1323 “TCP Extensions for High Performance” (RTTM – Round-Trip Time Measurement)
> RFC2018 “TCP Selective Acknowledgment Options”
> RFC5482 “TCP User Timeout Option”
> RFC5681 “TCP Congestion Control (RFCs 6298, 6582)
Im Zusammenhang mit der Ethernet-Switch Unterstützung in AUTOSAR 4.2 wurde das TCPIP-Modul um einen DHCPv4Server ergänzt, der IP-Adressen Switch Port-basiert vergibt. Dieser DHCPv4-Server ist ebenfalls als TCPIP-Add-on
verfügbar.
> SOAD: Der Socket Adaptor (SOAD) setzt die in AUTOSAR definierte Kommunikation über PDUs in Socket-orientierte
Kommunikation 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über liegenden Module auch in einer Nicht-AUTOSARUmgebung, wie beispielsweise Linux, eingesetzt werden.
> DOIP: 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).
> SD: Service Discovery (SD) ist erstmals in AUTOSAR 4.1.1 spezifiziert. Über das in diesem Modul implementierte
Protokoll teilt ein Steuergerät seinen Kommunikationspartnern die Verfügbarkeit seiner Dienste mit. Zusätzlich können
sich Steuergeräte registrieren, um automatische Benachrichtigungen zu erhalten, z.B. bei einem Signalupdate.
> UDPNM: Mittels UDP Network Management (UDPNM) realisieren Sie das synchrone Einschlafen von EthernetSteuergeräten.
> TLS: Dieses Modul enthält einen Transport Layer Security Client. Mit TLS wird TCP-basierte Kommunikation
verschlüsselt. Der verwendete Verschlüsselungsalgorithmus ist wählbar.
Optionen:
> Post-build loadable: Dieses Feature ist für die Module SOAD und SD erhältlich.
8.4
Konfiguration
Die Ethernet- und TCP/IP-spezifischen Konfigurationsparameter werden für AUTOSAR 3.x als Erweiterung in der „ECU
Configuration Description (ECUC)“ gespeichert. Dies gilt auch innerhalb von AUTOSAR 4.x für die nicht spezifizierten
Konfigurationsparameter.
8.5
Weitere relevante MICROSAR Produkte
Entsprechend der AUTOSAR-Architektur bildet MICROSAR.ETH zusammen mit den BSW-Modulen aus den separat
erhältlichen 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ältlich.
> 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.
31
MICROSAR
> 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.
Verwendung 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.
8.6
Weitere relevante Produkte für Ethernet
Mit der CANoe-Option „.Ethernet“ erweitern Sie Ihre bestehende CANoe Installation komfortabel um die Möglichkeit,
Ethernet-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
konfigurierbar) auch zwei Highspeed CAN Kanäle.
32
MICROSAR
8.7
Die Vector Toolchain für die Entwicklung von Ethernet-Steuergeräten
Bild 18: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet-Projekte
33
MICROSAR
9
MICROSAR V2G – Basissoftware-Module für die Kommunikation mit externer Infrastruktur
Mit Ethernet und dem darüber liegenden 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
Hybridfahrzeugen und für die Kommunikation mit der Infrastruktur über Internettechnologien, wie z.B. HTTP. Alle Module aus
diesem Paket sind nicht in AUTOSAR spezifiziert. Allerdings sind sie nahtlos in die Vector AUTOSAR-Lösung integriert. Die
Erweiterungen werden sowohl für AUTOSAR 4.x als auch für AUTOSAR 3.x angeboten. Als Basis für MICROSAR V2G werden
Module aus dem MICROSAR.ETH Paket benötigt. Details hierzu finden Sie in Kapitel 9.5.
Bild 19: Die MICROSAR V2G BSW-Module, eingebettet in eine AUTOSAR 4.2 Umgebung
9.1
Die Vorteile von MICROSAR V2G im Überblick
> Implementierung aller notwendigen Protokolle für Smart-Charge-Communication (SCC)
> 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
9.2
Anwendungsgebiete
MICROSAR V2G ermöglicht Ihnen im Zusammenspiel mit einer entsprechenden Ladesäule das intelligente Laden von Elektround Hybridfahrzeugen. Unterstützt werden die Standards
> ISO 15118 und
> DIN 70121
mit den dazugehörigen Möglichkeiten zum Wechsel- und Gleichstromladen (AC und DC).
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.
34
MICROSAR
9.3
Funktionen
Die folgenden BSW-Module sind in MICROSAR V2G enthalten:
> DNS: Das Modul DNS 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.
> HTTP: Das Hypertext Transfer Protokoll übermittelt beispielsweise Browseranfragen an einen Server. Das Modul enthält
einen HTTP-Client.
> XML Security: Mit diesem Modul erzeugen und validieren Sie XML-Signaturen auf EXI-kodierten Daten, basierend auf
dem W3C XML Security Standard.
> EXI: Mit dem Modul EXI werden XML-Dokumente interpretiert und in ein Binär-Format konvertiert. Damit lassen sich die
Dateien effizienter verarbeiten und übertragen, um Kommunikationsbandbreite einzusparen.
> SCC: Dieses Modul ist zuständig für die Smart-Charge-Communication nach ISO 15118 bzw. DIN 70121 und beinhaltet
das dafür verwendete Transportprotokoll V2GTP. Es unterstützt das Gleich- und Wechselstromladen sowie die
dazugehörigen Profile Plug-and-Charge (PnC) und External Identification Means (EIM).
Innerhalb einer AUTOSAR 3.x Umgebung sind zusätzlich folgende Module verfügbar:
> XML Engine: 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
> JSON: Dieses Modul enthält einen JSON-Parser. JSON ist ein JavaScript-basiertes Datenaustauschformat und kann
anstelle von XML verwendet werden.
9.4
Konfiguration
Die Module des MICROSAR V2G Pakets werden mit dem DaVinci Configurator Pro konfiguriert. Mehr Details finden Sie in der
Die spezifischen Konfigurationsparameter werden als Erweiterung in der „ECU Configuration Description“ gespeichert.
9.5
Weitere relevante MICROSAR Produkte
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 (ETHDRV) aus MICROSAR.MCAL und ein Ethernet-Transceiver-Treiber (ETHTRCV)
aus MICROSAR.EXT benötigt. Hier sind für den Fall von Smart-Charge-Communication spezielle Treiber und TransceiverTreiber für Powerline-Kommunikation (PLC) verfügbar.
Falls die Steuerung der Smart-Charge-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
MICROSAR.SYS zur Verfügung.
Das Modul DEM aus dem Paket MICROSAR.DIAG können Sie zur Verwaltung der erkannten Systemereignisse (Fehler und
Umgebungsdaten) einsetzen.
9.6
Weitere relevante Produkte für Ethernet
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-ChargeCommunication Add-On können Sie in CANoe zudem den SCC-Datenverkehr analysieren. Damit sind Sie in der Lage,
basierend auf dem DIN-Standard, komplexe Fahrzeug- und Ladesäulen-Simulationen aufzubauen.
Für das VT-System bietet Vector eine Einschubkarte für Powerline-Kommunikation an.
35
MICROSAR
9.7
Die Vector Toolchain für die Entwicklung von Ethernet/V2G-Steuergeräten
Bild 20: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet/V2G-Projekte
36
MICROSAR
10 MICROSAR AVB – Basissoftware-Module für die Audio/Video-Kommunikation via Ethernet
MICROSAR AVB (Audio/Video Bridging) über Ethernet ermöglicht eine schnelle und zuverlässige Übertragung von
Audio/Video Daten. Das Paket MICROSAR AVB enthält verschiedene BSW-Module, die auf dem Ethernet-Interface, z.B. aus
MICROSAR.ETH, aufsetzen. Die auf AUTOSAR 4.x basierte Lösung unterstützt AVTP (Audio/Video Transport Protocol), RTP
(Transport Protocol for Real-Time Applications), SRP (Stream Reservation Protocol), PTP (Precision Time Protocol) und auf
Anfrage BMCA (Best Master Clock Algorithm). Damit ergibt sich die Möglichkeit, AVB-Endpunkte sowie BridgeFunktionalität zu implementieren.
Bild 21: Die MICROSAR AVB BSW-Module nach AUTOSAR 4.2
10.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
10.2 Anwendungsgebiete
10.2.1 A/V-Streaming
MICROSAR AVTP und RTP ermöglichen den Austausch von Audio/Video Daten, inklusive deren Zeitstempel, zwischen
verschiedenen Endpunkten. Das AVTP ist ein Schicht 2 Protokoll und ist nach der Spezifikation IEEE 1722/1722a umgesetzt.
Das RTP hingegen ist ein Schicht 3 Protokoll und setzt auf UDP auf. RTP ist nach der Spezifikation IETF RFC 3550 umgesetzt.
37
MICROSAR
10.2.2 Auswahl des genauesten Zeitgebers
Bevor eine systemweit genaue Zeit dargestellt werden kann, muss das Gerät - typischerweise eine Bridge - mit dem
genauesten Zeitgeber festgelegt werden. Dieser kann statisch vorgegeben oder dynamisch mittels BMCA ermittelt werden.
Dabei kommt die Spezifikation IEEE 802.1AS zum Einsatz.
10.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
gleichen, 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 PTP-Modul nach Spezifikation IEEE
802.1AS umgesetzt.
Um eine exakte Zeitmessung zu ermöglichen, ist unter Umständen eine erweiterte Hardware-Unterstützung notwendig, die
typischerweise im „HighEnd-Feature“ des Ethernet-Treibers umgesetzt ist.
10.3 Funktionen
Die folgenden BSW-Module aus MICROSAR AVB enthalten die in den oben genannten IEEE-Spezifikationen definierten
Funktionen. Hinzu kommen alle notwendigen Software-Merkmale, die eine nahtlose Integration in eine AUTOSAR-Umgebung
zulassen.
> AVTP
> 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
> PTP
> Initialisierung aller notwendigen Hardware-Schnittstellen
> Ethernet-Frames mit Ethertype 0x88F7 werden aus dem ETHIF dem PTP zugeleitet
> 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
> BMCA
> Unterstützung von: PortAnnounceReceive, PortAnnounceInformation, PortRoleSelection, PortAnnounceTransmit
> SRP
> Registrierung von Datenströmen mit Identifizierung und Zugriffskontrolle
> RTP
> RTP stellt eine Ende-zu-Ende Netzwerktransportfunktion bereit passend für Anwendungen, welche über multicast
oder unicast Netzwerkdienste Echtzeitdaten übermitteln, wie beispielsweise Audio, Video oder Simulationsdaten. RTP
unterstützt die folgenden Profile:
> IETF RFC 6184 RTP Payload Format for H.264 Video
> IEEE 1733 Layer 3 Transport Protocol for Time-Sensitive Applications in Local Area Networks
10.4 Konfiguration
Die AVB-spezifischen Konfigurationsparameter werden als Erweiterung in der „ECU Configuration Description“ gespeichert.
38
MICROSAR
10.5 Schnittstellen zu angrenzenden MICROSAR Produkten
Entsprechend der MICROSAR Architektur bildet MICROSAR AVB zusammen mit den BSW-Modulen aus den separat
erhältlichen 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.
10.6 Weitere relevante MICROSAR Module für Ethernet
> TCPIP, SOAD, DOIP, SOME/IP aus MICROSAR.ETH
> DET, ECUM, COMM und NM, aus MICROSAR.SYS
> MICROSAR XCP
10.7 Weitere relevante Produkte für Ethernet
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
konfigurierbar) auch zwei Highspeed CAN-Kanäle.
10.8 Die Vector Toolchain für die Entwicklung von Ethernet/AVB-Steuergeräten
Bild 22: Vector bietet Ihnen ein umfassendes Portfolio für Ihre Ethernet/AVB-Projekte
39
MICROSAR
11 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 23: Die MICROSAR.MEM Module nach AUTOSAR 4.2
11.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 Flashund/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.
11.3 Funktionen
Die BSW-Module in MICROSAR.MEM enthalten die in AUTOSAR 4.x definierten Funktionen. In jedem Memory-Stack sind die
BSW-Module NVM und MEMIF aus MICROSAR.MEM erforderlich. Sie übernehmen – ohne Kenntnisse der Speicherattribute –
den blockorientierten und technologie-unabhängigen Zugriff auf die Speicherbereiche. Je nach Anwendungsfall benötigt Ihr
Memory-Stack zusätzliche BSW-Module:
40
MICROSAR
> 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
geeigneten 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.
Über den Standard hinaus enthält MICROSAR.MEM die folgenden wichtigen Dienste:
> Fest definierte Maximallaufzeiten aller MICROSAR.MEM Funktionen. Dies erlaubt Systemoptimierungen zur Verkürzung
der Zugriffszeiten
> NVM: Allokierung von RAM zur CRC-Speicherung
> NVM: Dedizierte Schnittstelle zum Diagnose-Modul DCM zum direkten Auslesen und Modifizieren von Datenblöcken
> NVM und EA: Zusätzliche, konfigurierbare Transaktionssicherheit, wie sie standardmäßig im Modul FEE enthalten ist
> FEE: Leistungsfähige Verwaltung der Speicherdaten
> FEE: Gemeinsame Nutzung des FEE-Moduls durch Flash Bootloader (FBL) und Anwendung möglich - auch mit
gemeinsamen Speicher-Blöcken. Dabei kann die Aktualisierung der Steuergerätesoftware ohne Anpassung des FBLs
erfolgen.
> FEE/EA: Redundante Ablage von Management-Daten zur Steigerung der Zuverlässigkeit der Datenzugriffe
> FEE: Flexible Platzierung der FEE-Sektoren im DataFlash
> FEE: Services für die Behandlung von Unterspannungs-Situationen
> FEE: 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.
> NVM: Blocktyp “DATASET_ROM” mit mehreren ROM-Blöcken
> FEE: Update-Unterstützung zur Anpassung des nicht-flüchtigen Speichers nach Steuergeräte-Umprogrammierung mit
neuer Konfigurationstabelle (Inhalt und Größe)
> FEE: Die Variante "Small sector FEE" wird empfohlen, wen nein Flash Speicher mit einer hohen Zahl an Sektoren mit
kleiner Sektor-Größe benutzt wird. Die Variante bietet dann folgende Vorteile:
> Es müssen weniger Management Daten gespeichert warden, so dass mehr Platz für Nuterdaten zur Verfügung steht
> Die Evaluierung des gültigen Nutzerdatensatzes ist deutlich schneller, so dass dem entsprechend das Hochstarten und
auch die Schreibvorgänge schneller ablaufen.
11.4 Konfiguration
Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Dieser enthält einige
arbeitserleichternde Funktionen wie Optimierungshilfen, optische Darstellung der Flash-Auslastung u.s.w. Mehr Details
finden Sie in der separaten Produktinformation.
41
MICROSAR
Bild 24: Konfiguration der MICROSAR.MEM Module mit DaVinci Configurator Pro
11.5 Weitere relevante MICROSAR Produkte für Ihren Memory-Stack
Entsprechend der AUTOSAR-Architektur bilden die Memory-Dienste aus MICROSAR.MEM zusammen mit weiteren
plattformspezifischen BSW-Modulen aus dem separat erhältlichen Paket MICROSAR.MCAL und MICROSAR.EXT einen
kompletten 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.
Abhängig von der gewünschten Sicherheitsstufe können Sie Ihre Speicherdaten mit dem Checksummen-Modul (CRC) aus
dem Paket MICROSAR.LIBS absichern.
42
MICROSAR
12 MICROSAR.SYS – Systembezogene Basissoftware Module für AUTOSAR
Die Systemdienste aus den MICROSAR.SYS Basissoftware Modulen (BSW) decken einen wichtigen Teil der
Grundfunktionalität Ihres AUTOSAR-Steuergeräts ab. Sie werden von der Funktionssoftware (via RTE) und den übrigen
BSW-Modulen aufgerufen. Die Module von MICROSAR.SYS bieten alle wichtigen Funktionen für das Zustands-Handling des
Steuergerätes.
Bild 25: Die MICROSAR.SYS Module nach AUTOSAR 4.2
12.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.
12.3 Funktionen
Die BSW-Module in MICROSAR.SYS enthalten die in AUTOSAR 4.x definierten Funktionen:
43
MICROSAR
> BSWM: 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.
> COMM: Der „Communication Manager“ kontrolliert den Zustandswechsel der am Steuergerät angeschlossenen
Kommunikationskanäle sowie der im Steuergerät konfigurierten Teilnetze. Er hält das Steuergerät bei Bedarf wach und
kommunikationsfähig. Weiterhin koordiniert er den Zugriff aller SWCs auf die Kommunikationskanäle und Teilnetze.
Optional unterstützt COMM den Bus Type „Internal“.
> BSWM und COMM: Unterstützung des Teilnetzbetriebs
> DET: Der Development Error Tracer sammelt Fehler während dem Entwicklungsprozess aus den SWCs und den BSWModulen. Optional unterstützt DET auch Service Ports.
> ECUM: Der ECU State Manager ist für Startup, Shutdown und WakeUp zuständig. In AUTOSAR 3.x gibt es weitere fest
definierte Betriebszustände, die der ECUM verwaltet. In AUTOSAR 4.x werden diese Betriebszustände flexibel vom
Anwender im BSWM definiert. Damit lassen sich individuelle Energiesparzustände realisieren oder unterschiedliches
Hochfahrverhalten erzielen.
> SCHM: 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 Funktionalität des SCHM.
> WDGM und WDGIF: Der Watchdog Manager überwacht die korrekte Arbeitsweise der Funktionssoftware mit den
Modulen WDGIF und WDGDRV (MICROSAR.MCAL).
Über den AUTOSAR-Standard hinaus beinhaltet MICROSAR.SYS die folgenden wichtigen Dienste:
> COMM: Kompatibel zu OSEK NM (für AUTOSAR 3.x)
> WDGM, WDGIF: Präzises Überwachen der Einhaltung definierter Zeitfenster für den Watchdog (auch für
hochauflösende Window-Watchdogs)
> ECUM: 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
Steuergerä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 compatible Service SWC interfaces
Folgende BSW-Module sind optional erhältlich:
> CSM: Der Crypto Service Manager bietet den SWCs und den BSW-Modulen einen einheitlichen Zugriff auf kryptographische Funktionen wie z.B. die Verschlüsselung AES 128 (Advanced Encryption Standard).
> STBM: Der Synchronized Time-Base Manager 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. Für die Bus-Systeme CAN, FR und ETH steht mit dem Tsyn-Modul ein Communication Service für die
fahrzeugweite Zeitsynchronisation von Steuergeräten zur Verfügung.
> WDGM: Der Watchdog Manager bietet Program Flow und Deadline Monitoring zur Überwachung der SWCs
12.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.
44
MICROSAR
In der Praxis kann dies schnell beliebig komplex werden, da aufgrund der von AUTOSAR vorgegebenen Konfigurationsstruktur
selbst eine einfache Konfiguration eine Vielzahl von ineinander greifenden 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 zugrunde liegende logische Ausdruck besteht wiederum aus einer oder mehreren Bedingungen (Condition), die auf
den eingegangen Modes (RequestPorts) basieren.
Auch Standardaufgaben wie das Konfigurieren einer Zustandsmaschine in Anlehnung an ECUM-Fix in AUTOSAR 3, der
Aufruf der entsprechenden Initialisierungsfunktionen der BSW-Module mit den passenden Parametern oder das An- und
Abschalten von PDU-Gruppen (I-PDU) stellen selbst erfahrene Entwickler vor eine Herausforderung.
Hierbei unterstützt Sie der DaVinci Configurator Pro mit intelligenten und mächtigen Assistenten, die viele der oben
erwähnten Aufgaben bereits automatisch erstellen können. Nachfolgend können Sie diese per Click automatisch
konfigurieren lassen. Dies gilt insbesondere für
> die ECU-Zustandsmaschine (ECU State Handling, siehe Bild)
> das Initialisieren der Basissoftwaremodule (Module Initialization)
> das Schalten der PDU-Gruppen (Communication Control).
Bild 26: Vorkonfigurierte State Machine / Auto-Configuration der BSWM mit dem DaVinci Configurator Pro. Ebenfalls zu sehen sind die AutoConfiguration 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
Configurator 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
45
MICROSAR
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.
12.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.
12.6 Konfiguration
Bild 27: Konfiguration des COMM Moduls mit DaVinci Configurator Pro.
12.7 Weitere relevante MICROSAR Produkte
> 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
MICROSAR.SYS.)
46
MICROSAR
13 MICROSAR.DIAG – AUTOSAR-kompatible Umsetzung des UDS-Protokolls
MICROSAR.DIAG enthält die BSW-Module für die Umsetzung des UDS-Protokolls ISO 14229-1:2006 (bzw. ISO 142291:2013) 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 28: Die MICROSAR.DIAG Module nach AUTOSAR 4.2
13.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
> OBDII 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
47
MICROSAR
Ü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
MICROSAR.DIAG erhältlich.
MICROSAR DIAG kann für heutige und zukünftige gesetzliche Anforderungen wie EURO VI eingesetzt werden. Die
Unterstützung von OBDII (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,
Services oder DTCs im generierten Diagnose-Code zusammengefasst werden.
13.3 Funktionen
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:
13.3.1 Funktionen des Diagnostic Event Managers (DEM)
Das DEM-Modul verwaltet den Fehlerspeicher eines Steuergeräts. Es ist in OEM-spezifischen Varianten und als OEMunabhängige Variante für AUTOSAR 4.x und 3.x erhältlich. Standardmäßig werden vom DEM-Modul die folgenden
Funktionen 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
> Compressed Configuration Data, zur Optimierung der Code-Größe
> Unterstützung von Sammelfehlern
> für "Mixed-AUTOSAR" – Projekte geeignet
> OBD II (ISO 15031 / SAE J1979) mit Unterstützung für Master und Primary OBD-Steuergeräte
> WWH-OBD (ISO27145)
Die DEM-Grundfunktionalität zwischen AUTOSAR 4.x und AUTOSAR 3.x ist weitgehend identisch. Die Unterschiede liegen in
der Schnittstellen-Definitionen. Vector bietet Ihnen eine Migrationslösung an, mit der Sie Ihre AUTOSAR 3.x-kompatiblen
SWCs in ein AUTOSAR 4.x-Projekt übernehmen können.
13.3.2 Funktionen des Diagnostic Communication Managers (DCM)
Der DCM verarbeitet die UDS- und OBDII-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 komplette
Liste der dabei unterstützten Services finden Sie in der Tabelle in Kapitel 13.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 informieren wir
Sie über die Details.
48
MICROSAR
Darüber hinaus enthält der DCM folgende Erweiterungen:
> 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
Folgende Funktionen sind optional erhältlich:
> Unterstützung von OBD II (ISO15031-5)
> WWH-OBD (ISO27145)
13.3.3 Funktionen des Function Inhibition Managers (FIM)
Der MICROSAR FIM enthält standardmäßig den Funktionsumfang von AUTOSAR 4.x und 3.x.
13.3.4 Funktionen des Diagnostic Request Managers (DRM)
Der MICROSAR DRM sendet Diagnoseanfragen zum eigenen oder zu anderen Steuergeräten und empfängt deren
Antwortbotschaften. Für die Anwendung stellt er eine API zum Senden und Empfangen der UDS Services bereit. Der DRM 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 extern
angeschlossener Tester und stellt die Basis für die Implementierung von On-Board Testern.
13.3.5 Funktionen des Diagnostic Transformer (DiagXF)
Der MICROSAR DIAGXF erlaubt das konsistente Schreiben und Lesen mehrerer Datenelemente in einem Data Identifier in
einem einzigen Durchgang. Der DIAGXF benötigt das Modul DCM und eine RTE.
13.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
Autorentool“ CANdelaStudio.
Bild 29: Mit CANdelaStudio bedaten Sie die MICROSAR.DIAG Module.
49
MICROSAR
Bild 30: Die Bedatung von MICROSAR.DIAG erfolgt mit CANdelaStudio und DaVinci Configurator Pro.
13.5 Lieferumfang
Zusätzlich zum Standard-Lieferumfang erhalten Sie einen Konverter für CANdela Diagnostic Descriptions.
13.6 Dienstleistungen für Diagnoseanwendungen:
> Kunden-spezifische Erweiterungen von MICORSAR.DIAG
> Erstellung von kunden-spezifischen Diagnose-Applikationen
> Integration der Diagnose in Ihre Steuergeräte-Software
13.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
Informationen hierzu finden Sie in der separaten CANdelaStudio Produktinformation.
Für die Diagnose von Nutzfahrzeugen benötigen Sie die J1939-spezifischen Module aus MICROSAR.CAN.
13.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)
SecurityAccess
27
… calculate seed/key for each security
level
… calculate seed/key for each security level
50
MICROSAR
(ISO 14229-1)
Service ID
(hex)
AUTOSAR 4.x:
The SWC has to …
AUTOSAR 3.x:
The SWC has to …
CommunicationControl
28
TesterPresent
3E
-
-
ControlDTCSetting
85
- (handled in DEM module)
Data Transmission Functional Unit
ReadDataByIdentifier
22
… handle data acquisition for each
DataElement
… 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
ClearDiagnosticInformation
14
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
RoutineId
… start (stop/request result) for each
RoutineId
Bild 31: UDS Diagnose Services beim Modul DCM
Das Modul DCM aus MICROSAR.DIAG unterstützt optional die folgenden OBD II Diagnose Services:
(ISO 15031-5)
Service
ID
(hex)
The SWC has to …
Diagnostic Service Definition for CAN
Request Current Powertrain Diagnostic Data
01
… handle data acquisition for each PID other than the "supported ID"
and DEM ones
Request Powertrain Freeze Frame Data
02
Request Emission-Related Diagnostic Trouble Codes
03
Clear/Reset Emission-Related Diagnostic Information
04
Request On-Board Monitoring Test Results for Specific
Monitored 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
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
"supported ID" and DEM ones
Request Emission-Related Diagnostic Trouble Codes with
Permanent Status
0A
Bild 32: OBD2 Diagnose Services beim Modul DCM
51
MICROSAR
14 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 33: Die MICROSAR.MCAL Module nach AUTOSAR 4.2
14.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
Konfigurationswerkzeug
> 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.
52
MICROSAR
14.3 Funktionen
Das Paket MICROSAR.MCAL enthält die Treiber-Module CAN, ETH, FR, LIN, und IIC sowie in der Version für AUTOSAR 4.x
das Test-Module RamTst. Die Module entsprechen AUTOSAR 4.x und sind für eine Vielzahl der gängigen Mikrocontroller
verfügbar. Für Projekte nach AUTOSAR 4.2 ist auch ein Ethernet Switch Treiber erhältlich.
Darüber hinaus enthält MICROSAR.MCAL die folgenden Erweiterungen:
> CANDRV: Benachrichtigung (Callback) beim Botschaftsempfang und nach erfolgreichem Versenden einer Botschaft.
Damit ist es möglich, automatisch anwenderspezifischen Code aufzurufen.
> FRDRV: Unterstützung der Self Diagnostic. Wenn der FlexRay-Controller einen Fehler erkennt, benachrichtigt er die
Anwendung, damit diese den Fehlerstatus abrufen kann.
Folgende Funktionalitäten bzw. Module sind optional erhältlich:
> CANDRV: Die Option „HighEnd“ bietet erweiterte Filtermöglichkeiten für Multiple Basic CAN-Objekte, Empfangsqueue
zur Verkürzung der Interrupt Laufzeit während des Empfangs, Individual Polling von Mailboxen zum Sicherstellen der
Datenkonsistenz sowie Reduzierung der Interrupt Last.
> IICDRV: Der IICDRV enthält Treiber für die Anbindung von externen Peripherie-Bausteinen über den Inter-Integrated
Circuit-Bus (I2C) (AUTOSAR-Erweiterung).
> Post-build loadable / Post-build selectable: Diese Features sind für ausgewählte MCALs als Option verfügbar.
14.4 Konfiguration
Bild 34: Konfiguration mit dem DaVinci Configurator Pro, Hauptbildschirm
14.5 MICROSAR MCAL Integration Package
Das MICROSAR MCAL Integration Package umfasst mehrere Arbeitspakete, durch die eine möglichst reibungslose
Integration eines 3rd Party MCALs in die Vector Embedded- und Werkzeugumgebung erreicht wird. Hierbei nehmen wir in
Abstimmung mit Ihnen und dem Halbleiterhersteller den beigestellten MCAL des Halbleiterherstellers zusammen mit der
53
MICROSAR
Vector 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 35: Ablaufschema des MCAL Integration Package
Vor der Auslieferung wird der MCAL in der Regel entfernt, so dass kundenseitig die durch den Halbleiterhersteller zur
Verfügung gestellten Pakete ergänzt werden müssen. Um diesen Schritt zu vereinfachen liegt der Lieferung ein Script bei,
das die Zusammenführung der Pakete weitestgehend automatisiert und unabdingbare Änderungen an den Paketen des
Halbleiterherstellers durchführt. Durch dieses Vorgehen wird auch eine spätere, eigenständige Aktualisierung des MCALs
durch den Kunden ermöglicht.
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 36: Leistungsprofil des MCAL Integration Package
54
MICROSAR
14.5.1 Abstimmung und Koordination mit dem Kunden
> Beratung bezüglich der Terminschiene des MCAL-Herstellers
> Ü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
14.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.)
14.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.
Grundvoraussetzungen 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
Abstrahierungen zur erleichterten Konfigurationserstellung und -validierung, so bietet Vector geeignete Mittel, die den
parallelen Einsatz von unterschiedlichen Konfigurationsdateien und Konfigurationstools erleichtern.
55
MICROSAR
15 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“
spezifiziert. Sie entsprechen AUTOSAR 4.x, sind für den jeweiligen Baustein optimiert und stehen für eine Vielzahl gängiger
Bausteine zur Verfügung.
Bild 37: Die MICROSAR.EXT Module nach AUTOSAR 4.2
15.1 Die Vorteile von MICROSAR.EXT im Überblick
> Optimale Ansteuerung Ihrer externen Transceiver- und Speicher-Bausteine
> Unterstützung von Transceivern für den Teilnetzbetrieb
> Zusätzliche Unterstützung von LIN- und Ethernet-Transceivern
> Vereinfachte Konfiguration durch Berücksichtigung von Parameterabhängigkeiten mit anderen Modulen
> Beschleunigte Entwicklung durch Plausibilitäts- und Vollständigkeitsprüfungen im Konfigurator
Mit MICROSAR.EXT erhalten sie eine fertige Lösung für die Ansteuerung Ihrer externen Peripheriebausteine. Beim Wechsel
eines externen Bausteins auf eine andere Hardware ist daher keine Anpassung der Funktionssoftware erforderlich. Sie
müssen lediglich die betroffenen Treiber aus MICROSAR.EXT auswechseln.
Je nach Anforderung Ihrer Anwendung fügen Sie weitere Pakete (z.B. MICROSAR.CAN, MICROSAR.MEM, etc.) hinzu und
erhalten einen kompletten Kommunikations-Stack oder eine Speicherverwaltung nach AUTOSAR-Spezifikation.
Für den Teilnetzbetrieb in CAN-Netzwerken benötigen Sie spezielle Transceiver. Für viele dieser Transceiver ist bereits ein
passender Treiber (CANTRCV) in MICROSAR.EXT erhältlich.
56
MICROSAR
15.3 Funktionen
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)
> Ethernet-Switch Treiber (ab AUTOSAR 4.2 Standard)
Für AUTOSAR 4 ist optional ein Treiber für den System-Basischip (SBC) erhältlich. Er unterstützt je nach Hardware
unterschiedliche 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 SBC-Treibers in Bezug auf
die bei Ihnen eingesetzte Hardware. Optional ist der SBC-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 Hardwarespezifischen Teil der Implementierung durch einen Zugriff auf die Register des SBC selbst vornehmen können.
15.4 Konfiguration
Bild 38: 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
entsprechenden 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. HalbleiterHerstellern, in den DaVinci Configurator Pro zu integrieren. Dies ermöglicht Ihnen, die gesamte Steuergeräte-Software
nahtlos und schnell mit einem einzigen Werkzeug zu konfigurieren.
57
MICROSAR
16 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 39: Das MICROSAR.IO Cluster
16.1 Die Vorteile von MICROSAR.IO im Überblick
> Schnelle Implementierung von anwenderspezifischem Code für die Erfassung und Bereitstellung von Sensor und
Aktuator 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
16.2 Anwendungsgebiete und Funktionen
Die Digital Input Output Hardware Abstraction (DIOHWAB) stellt eine Verbindung zwischen Anwendung und DIO-Signalen
aus dem MCAL her. Dafür erzeugt das Modul DIOHWAB 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
DIOHWAB-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.
Der innerhalb MICROSAR.IO erhältliche SENT 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 Schnittstellenanbindung an
das ICU-Modul Hardware-unabhängig. Er bietet folgende Funktionalität an:
> SENT Master Node Funktionalität
> Unterstützung mehrerer SENT-Kanäle
58
MICROSAR
> 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
16.3 Konfiguration
Für eine komfortable Konfiguration empfehlen wir unseren DaVinci Configurator Pro. Details hierzu erfahren Sie in der
16.3.1 DIOHWAB
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 DIOHWAB 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
konfigurierbar. Für den Zugriff der Funktionssoftware über die RTE auf die I/O-Signale stellt MICROSAR.IO alle notwendigen
Client/Server Interfaces sowie Code-Templates zur Verfügung. Diese ermöglichen dem Anwender das Aufbereiten und
Filtern der Signale.
Bild 40: Konfiguration des Moduls DIOHWAB mit DaVinci Configurator Pro
16.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.
59
MICROSAR
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.
60
MICROSAR
17 MICROSAR.RTE – Die optimierte Ablaufumgebung für Softwarekomponenten nach dem AUTOSARStandard
Die MICROSAR.RTE (Runtime Environment) ist die skalierbare und hoch optimierte Laufzeitumgebung von Vector. Die RTE
ist ein von AUTOSAR eingeführtes Modul und verwaltet die Kommunikation zwischen den Softwarekomponenten (SWCs).
Sie stellt dabei die Konsistenz des gesamten Informationsflusses sicher und bildet die Schnittstelle zwischen
Funktionssoftware, Basissoftware (BSW) sowie Complex Drivern (CDD).
Bild 41: Das MICROSAR.RTE Modul nach AUTOSAR 4.2
17.1 Die Vorteile von MICROSAR.RTE im Überblick
> Leicht konfigurierbar und skalierbar
> Tiefgehende Konsistenzprüfung der Konfiguration
> Hoch optimierter Code mit intelligenten Synchronisationsmechanismen
> Schneller Einstieg in AUTOSAR durch z.B. generiert Code Templates für die Softwarekomponenten (SWCs)
> Für Migrationsprojekte geeignet
> Vereinfachter Test der Applikation durch XCP-Zugriff auf Ports, InterRunnable-Variablen und Per-Instance Memory
Wenn die Funktionssoftware eines Steuergeräts über AUTOSAR-konforme SWCs implementiert ist, benötigt der Anwender
die RTE als Laufzeitumgebung. Dieser modulare Aufbau der Steuergerätesoftware bietet dem Anwender maximale
Flexibilität: Eine manuell entwickelte oder durch modellbasierte Werkzeuge entworfene SWCs kann in mehreren
Steuergeräte-Projekten verwendet werden. Hierzu ist lediglich für das konkrete Steuergerät das Umkonfigurieren und die
neue Generierung der RTE sowie ggf. der BSW-Module erforderlich. Darüber hinaus ist auch die Mehrfachverwendung einer
SWC auf einem Steuergerät möglich.
61
MICROSAR
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.
17.3 Funktionen
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 SCHMModuls. Dieses war vorher in MICROSAR.SYS enthalten. Mehr Information über das SCHM-Modul finden Sie im Kapitel
„MICROSAR.SYS“.
> Unterstützung der Transformer-Schnittstellen für COMXF, SOMEIPXF und E2EXF. Details hierzu erhalten Sie im Kapitel
MICROSAR.COM.
> Externe Client/Server Kommunikation (Inter-ECU) über den optional erhältlichen Transformer SOMEIPXF.
Über den Standard hinaus beinhaltet MICROSAR.RTE für AUTOSAR 3.x die folgenden wichtigen Dienste:
> 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.
> 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".
Auf Anfrage erhältlich sind:
> Unterstützung von internen, externen und background Runnable Triggern (für AUTOSAR 4.x)
> Skalierung von Ports und Signalen (für AUTOSAR 4.x)
> Range Checks (für AUTOSAR 4.x)
62
MICROSAR
Bild 42: MICROSAR.RTE ermöglicht das Generieren von Code Templates für die SWCs der Funktionssoftware
17.4 Basic Runtime Environment (BRE)
Die Basic Runtime Environment (BRE) erlaubt die Integration einer nicht-AUTOSAR-basierten Anwendung mit der
MICROSAR Basissoftware. Bei Verwendung der BRE ist ein formelles Design der SWCs nach AUTOSAR-Definition nicht
erforderlich, da die BRE die Nutzung der existierenden Anwendungs-Architektur ermöglicht. Sie ist dadurch das ideale
Instrument, um ein bestehendes Steuergeräte-Projekt in eine AUTOSAR-Architektur zu migrieren.
Bei Verwendung der BRE greift die Applikation direkt auf die Funktionen der Basissoftware zu, ohne dass hierzu AUTOSARkonforme SWCs definiert werden müssen. In diesem Anwendungsfall wird die RTE als Bindeglied zwischen SWCs und BSW
nicht verwendet, sondern durch Anwendungs-Code ersetzt.
Um die Integration der Anwendung mit der MICROSAR Basissoftware zu erleichtern, stellt die BRE Basisfunktionalitäten zur
Verfügung, die normalerweise von der AUTOSAR-RTE übernommen werden:
> Generierung der Typdefinition für BSW-Module der Service Schicht
> Aufrufen der BSW Main Functions basierend auf einem konfigurierbaren Task Mapping
> Generierung der Exclusive Areas für die BSW-Module
Da die BSW AUTOSAR-konforme Schnittstellen besitzt, setzt die Verwendung der BRE voraus, dass die Applikation die
Schnittstellenfunktionen der RTE zur BSW selbst übernimmt.
Grundsätzlich ist MICROSAR.RTE die umfassende Lösung für ein Steuergeräte-Projekt im AUTOSAR-Umfeld. Unsere
erfahrenen Coaches unterstützen Sie gerne, wenn Sie Ihre Anwendung und BSW-Architektur auf den AUTOSAR-Standard
anheben möchten.
17.5 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.
17.6 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.
63
MICROSAR
18 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 43: Die MICROSAR AMD Module nach AUTOSAR 4.2
18.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 BasisSoftware-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.
64
MICROSAR
Bild 44: MICROSAR AMD ermöglicht im Zusammenspiel mit CANoe.AMD einen einfachen Zugriff auf Steuergeräte-interne Informationen
18.3 Funktionen
Die Funktionalität der Module DBG (Debugging) und DLT (Diagnostic Log and Trace) ist in AUTOSAR 4.x spezifiziert
Zusätzlich zum AUTOSAR-Standard bietet MICROSAR AMD die Möglichkeit, CPU-Last und beliebige Laufzeiten zu ermitteln.
Zur Anzeige und Analyse werden die mit MICROSAR AMD ausgelesenen Werte an einen XCP-Master übertragen. Als XCPMaster 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 RTM.
Mit diesen Werkzeugen und einer Beschreibung der Mess-Objekte in Form einer ASAM A2L-Datei wählen Sie die Steuergeräte-internen Daten aus und analysieren deren Abläufe. Speziell für AMD wurde CANape um das „Digital Fenster“ mit der
„Status“-Signaldarstellung und CANoe mit dem speziellen „State Tracker“ Fenster erweitert. Damit stellen Sie diskrete
Zustände und binäre Signale in einem Fenster übersichtlich dar.
Bild 45: Auswerten von Statusänderungen mit dem State Tracker Fenster in CANoe.AMD
18.3.1 Erfassen von internen Variablen aus den AUTOSAR BSW-Modulen
Mit dem BSW-Modul DBG aus MICROSAR AMD überprüfen Sie bei Steuergerätetests, welche externen und internen
Einflüsse einen Zustandswechsel der BSW-Module verursacht haben. Die dazu benötigten internen Variablen der MICROSAR
BSW-Module sendet das DBG-Modul mittels XCP an den Master.
18.3.2 Erfassen von internen Variablen aus der MICROSAR.RTE
Beim Einsatz einer MICROSAR.RTE als Laufzeitumgebung in Ihrer Steuergerätesoftware kann der Datenfluss zwischen
SWCs mit XCP überwacht werden. Nach der Aktivierung der Option „Measurement Support“ bei der RTE-Konfiguration
werden die folgenden RTE-interne Objekte erfasst:
65
MICROSAR
> Inter-Runnable Variablen
> Sender/Receiver Ports
> Mode Ports
> Per-Instance Memory
Damit überwachen Sie die Intra- und Inter-ECU Kommunikation sowie messen oder stimulieren nicht verbundenen
Sender/Receiver Ports.
18.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
Warnungen, 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.
18.3.4 Ermitteln von CPU-Last und Laufzeit
Mit MICROSAR AMD und CANoe.AMD erfassen Sie die Laufzeit frei wählbarer Code-Abschnitte aus der
Anwendungssoftware oder den BSW-Modulen. Die Ergebnisse der Messungen werden in HTML- und CSV-Reports angezeigt,
die mit dem CANoe Test Feature Set erzeugt werden.
18.3.5 Erzeugen der A2L-Datei für den XCP-Master
Sie erzeugen die A2L-Beschreibungsdatei für den XCP-Master mit den DaVinci Werkzeugen auf Basis der Konfigurationsdaten aus der Steuergerätekonfigurationsdatei (ECUC). Falls symbolische Namen für Werte der messbaren Objekte
existieren, sind diese für die spätere Visualisierung ebenfalls hinterlegt. Es ist auch möglich, weitere Applikations-spezifische
A2L-Fragmente in die Master A2L-Datei mit aufzunehmen. Vor der Messung aktualisieren Sie mit dem ASAP2 Updater die
A2L-Datei mit den tatsächlichen Adressen der Variablen. Der ASAP2-Updater ist im Lieferumfang von CANape und
CANoe.AMD enthalten.
Bild 46: Erzeugen einer A2L-Datei für den XCP-Master
66
MICROSAR
18.4 Konfiguration
18.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
18.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-Beeinflussung. 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ö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.
67
MICROSAR
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
Funktionalitä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 47: Die MICROSAR Safe Module nach AUTOSAR 4.2. 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
Die Module aus MICROSAR Safe sind "Safety Elements out of Context" (SEooCs), die nach ISO 26262 / ASIL D entwickelt
sind.
68
MICROSAR
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
MICROSAR 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 48: 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
Protection Unit (MPU), die verschiedenen Software-Partitionen voneinander ab. Dies verhindert, dass SWCs unerlaubt in den
Speicher anderer SWCs schreiben und so Daten verfälschen. Zusätzlich wird sichergestellt, dass bei einem Task-Wechsel oder
Interrupt der Kontext korrekt umgeschaltet wird.
SafeOS verbessert die Unterstützung von sicheren Systemen mit hohen Anforderungen an die Verfügbarkeit durch ein nach
ISO 26262 entwickeltes Scheduling mit zugehöriger Timing Protection und Applikationsterminierung.
SafeOS enthält weitere Funktionen zur Unterstützung der Partitionierung durch die MPU, z.B. Zugriff auf privilegierte
Register, MPU-Testfunktionen und Datenaustausch über Partitions- und Kerngrenzen hinweg.
19.3.2 SafeE2E - Sichere Inter-ECU-Kommunikation
Daten, die zwischen sicherheitsrelevanten Anwendungen auf verschiedenen Steuergeräten ausgetauscht werden, müssen auf
korrekte Übertragung geprüft werden. Eine Checksumme sichert dazu den Dateninhalt ab. Die korrekte Reihenfolge der
Daten wird durch einen Botschaftszähler überwacht. Schlägt eine dieser Prüfungen fehl, wird die Anwendung informiert und
kann darauf entsprechend reagieren. Dadurch werden Fehler wie Maskerade, Ausfall, Vertauschung, etc. erkannt.
Innerhalb von SafeE2E stehen Ihnen die Transformer COMXF, SOMEIPXF und E2EXF nach AUTOSAR 4.2 zur Verfügung, um
eine sichere Kommunikation nach diesem Schema zu gewährleisten. Alternativ bieten wir mit dem ebenfalls erhältlichen
Protection Wrapper eine AUTOSAR-konforme und signalbasierte Schnittstelle. Diese ermöglicht das komfortable Anwenden
der E2E-Absicherung in der Applikation oberhalb der RTE.
69
MICROSAR
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
sicherheitsrelevante 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
Speicherbereichen. 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
Analyzer optional zur Verfügung.
19.3.5 Absicherung der Hardware
Die Module von MICROSAR Safe setzen voraus, dass die Hardware hinreichend sicher für den Einsatz im Kundenprojekt ist.
Wenn diese Forderung durch die Hardware nicht erfüllt wird, können Sie dies unter Umständen durch geeignete SoftwarePrüffunktionen erreichen. Dazu müssen Sie die spezifischen Sicherheitsziele betrachten.
SafeOS enthält in Bezug auf die MPU bereits zusätzliche Funktionen. Weitere Funktionen zur Absicherung von RAM, Flash,
MPU, IO, etc. können als Projektarbeit angeboten werden.
19.4 Konfiguration
Für die Konfiguration der BSW-Module aus MICROSAR Safe empfehlen wir das Werkzeug DaVinci Configurator Pro. Details
hierzu erfahren Sie in der separaten Produktinformation.
19.5 Lieferumfang
MICROSAR Safe ist für den AUTOSAR 4 Standard entwickelt. Zusätzlich zu den BSW-Modulen enthält jede Lieferung von
MICROSAR Safe auch das für sicherheitsrelevante Steuergeräte erforderliche Sicherheitshandbuch (Safety Case) für die
nach ASIL entwickelten Module. Das ausgelieferte Gesamtpaket ist dabei stets ein SEooC für das im Projekt ein
entsprechendes Safety Case Dokument von Vector zur Verfügung gestellt wird.
MICROSAR Safe ist auch für AUTOSAR 3 verfügbar. Somit können Mixed-ASIL-Projekte nach AUTOSAR 3 Standard
durchgefü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
SafeOS
Inhalt
> 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
> WDGDRV: Treiber für interne Watchdog-Bausteine
> WDGDRVEXT: Treiber für externe Watchdog-Bausteinen
> SBC: Treiber für System Basis Chip Bausteine (mit Watchdog- und Transceiver-Funktion)
70
MICROSAR
20 MICROSAR Security – Zugriffs-Sicherheit 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
Integrität, Authentizität und Vertraulichkeit von Information zu schützen. Vector bietet Ihnen in diesem Bereich die in
AUTOSAR 4.2 spezifizierten Komponenten an.
Bild 49: Security Module nach AUTOSAR 4.2. Über den CSM kann eine Hardware entsprechend der Standard Secure Hardware Extension (SHE) genutzt
werden.
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
> Authentifikation von Kommunikationsendpunkten
> Schutz gegen unautorisiertes Lesen von Daten
20.2 Funktionen
Die Security-Funktionalität ist in zwei Module aufgeteilt: In der Crypto Abstraction Library (CAL) steht eine AUTOSARLibrary bereit, während in dem System-Service-Layer der Crypto Service Manager (CSM) verwendet werden kann.
Beide Module bieten nahezu die gleichen Dienste an, haben aber verschiedene technische Eigenschaften und werden
unterschiedlich verwendet. Beide Module sind als Wrapper-Module ausgelegt, sie bieten somit nur abstrakte Schnittstellen
und damit einen logischen Dienst an, z.B. symmetrische Verschlüsselung. Der tatsächliche Algorithmus, der angewendet
werden soll (z.B. AES-128) wird durch die ECU-Konfiguration festgelegt. Sowohl CAL als auch CSM bieten folgende
Funktionen:
71
MICROSAR
> Zugriff auf die kryptographischen Dienste.
> Bis zu 32 verschiedene Dienstkonfigurationen können für jeden kryptographischen Dienst angelegt werden. Dadurch wird
festgelegt, durch welchen Algorithmus der Dienst erbracht werden soll.
> Synchrone Ausführung des Dienstes.
> Große Datenströme können inkrementell bearbeitet werden („Streaming“).
20.2.1 Die Crypto Abstraction Library (CAL)
> Als AUTOSAR-Bibliothek ist sie zustandslos, der Kontext einer Berechnung wird also vom Aufrufer verwaltet. Der Dienst
wird im Task des Aufrufers abgearbeitet, wobei beliebig viele Aufrufer parallel Anfragen stellen können.
> Alle Dienste sind in Software realisiert.
> Die Implementierung des Algorithmus befindet sich in dem Hilfsmodul Cryptographic Primitive Library (CPL). Bei Wahl
der CAL benötigen Sie auch das Hilfsmodul CPL aus dem Cluster MICROSAR.LIBS zur symmetrischen oder
asymmetrischen Ausführung.
20.2.2 Der Crypto Service Manager (CSM)
> Das Modul gehört dem Layer "Services" an.
> Der Manager bietet Zugriff auf kryptografische Dienste durch den RTE-Port-Mechanismus an. Alternativ können auch
BSW-Module oder CDDs direkt auf die Dienste zugreifen.
> Er kann für synchrone oder asynchrone Ausführung konfiguriert werden.
> Die Implementierung des Algorithmus befindet sich in dem Hilfsmodul Cryptographic Library Module (CRY). Bei Wahl
des CSM benötigen Sie auch das Hilfsmodul CRY aus dem Cluster MICROSAR.SYS zur symmetrischen oder
asymmetrischen Ausführung.
> Die Dienste können in einem CRY-Modul direkt in Software umgesetzt oder an einen Treiber weitergereicht werden, mit
dem die Security-Hardware gesteuert wird.
Derzeit noch nicht als Paket definierte Dienste bieten wir Ihnen auf Nachfrage gerne an.
20.2.3 Secured OnBoard Communication (SecOC)
Dieses Modul 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
ausgeschlossen. Bei der SecOC besteht eine Interaktion mit dem PDU-Router, steuerbar ist sie durch die Applikation. Das
Modul bietet dabei folgende Funktionalitäten:
> Übertragung von authentifizierten und integritätsgeschützten I-PDUs. Hierbei berechnen je nach gewählter Variante die
Module CSM oder CAL die Echtheitsbestätigung.
> Verhinderung von replay attacks. Hierbei kommt ein Zähler zum Einsatz, der über die MAC-Adresse oder eine Signatur
die Aktualität der Signale prüft, um Attacken zu verhindern.
20.3 Unterstütze Algorithmen
Service
API <service> name
Data Stream
CSM
CAL
Algorithms
Hash functions
Hash
Yes
Yes
Yes
Yes
Checksum
Checksum
Yes
Yes
Yes
CRC-16, CRC-32
RandomGenerate
No
Yes
Yes
FIPS-186
RandomSeed
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Random numbers
MacGenerate
Message Authentication Code
MacVerify
Yes
SymBlockEncrypt
ECB Mode
SymBlockDecrypt
Yes
HMAC-RIPEMD-160,
HMAC-SHA-1,
HMAC-SHA-256
AES, DES,
Triple DES, RC2
72
MICROSAR
Service
CBC Mode
Key generation
Key management
Asymmetrical encryption
Signature
Key exchange
Wrapping symmetric Key using public
Key
Key Update
Key Extraction
Wrapping asymmetric private Key
using public Key
Compression
API <service> name
SymEncrypt
SymDecrypt
Data Stream
Yes
CSM
CAL
Yes
Yes
Yes
Yes
KeyDerive
Yes
Yes
Yes
SymKeyGenerate
No
Yes
No
KeyDeriveSymKey
No
Yes
No
SymKeyUpdate
Yes
Yes
No
SymKeyExtract
Yes
Yes
Yes
SymKeyWrapSym
Yes
Yes
Yes
AsymPrivateKeyWrapSym
Yes
Yes
Yes
AsymEncrypt
Yes
Yes
Yes
AsymDecrypt
Yes
Yes
Yes
SignatureGenerate
Yes
Yes
Yes
SignatureVerify
Yes
Yes
Yes
KeyExchanageCalcPubVal
No
Yes
Yes
KeyExchangeCalcSecret
Yes
Yes
Yes
KeyExchangeCalcSymKey
Yes
Yes
No
SymKeyWrapAsym
Yes
Yes
Yes
AsymPrivateKeyUpdate
Yes
Yes
No
AsymPublicKeyUpdate
Yes
Yes
No
AsymPublicKeyExtract
Yes
Yes
Yes
AsymPrivateKeyExtract
Yes
Yes
Yes
AsymPrivateKeyWrapAsym
Yes
Yes
Yes
Compress
Yes
Yes
Yes
Decompress
Yes
Yes
Yes
Algorithms
AES, DES,
Triple DES, RC2
PKCS #5 V2.0
X9.63
RSA (512, 1024, 1536, 2048 bit)
RSA (512, 1024, 1536, 2048)
ECC (160, 192, 224, 256)
EDHC
20.4 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.
20.5 Umsetzung
> Je nach Bedarf wird die Crypto Abstraction Library oder der Crypto Service Manager angeboten
> Die benötigten Security-Algorithmen stehen sowohl in CPL wie auch in CRY als Software-Implementierung zur
Verfügung
> Interne oder externe Security-Hardware, z.B. nach HIS-SHE, kann auf Anfrage unterstützt werden
73
MICROSAR
21 MICROSAR Multi-core – Die AUTOSAR Lösung für Mehrkern-Prozessoren
Durch die Einführung von Multi-core Prozessoren verändert sich nachgelagert auch das Design der AUTOSAR-Software.
Einzelne AUTOSAR-Anwendungen können auf unterschiedliche Prozessorkerne verteilt und dann zeitgleich betrieben werden.
Entscheidend für den Erfolg ist eine gute Verteilung mit geringen Synchronisationsverlusten zum Beispiel durch Wartezeiten.
MICROSAR Multi-core unterstützt Sie hierbei umfassend.
21.1 Die Vorteile von MICROSAR Multi-core im Überblick
> Voll integriert in das MICROSAR Gesamtpaket: Effiziente Lösung zwischen MICROSAR.OS und MICROSAR.RTE durch:
> Nutzung einer einzigen OS-Konfiguration für alle Prozessorkerne
> Nutzung von Shared Memory und effizienter Spinlocks für die RTE zur Reduktion 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 BSW-Satelliten auf Slave-Prozessorkernen zur Gewährleistung einer laufzeitoptimierten Abwicklung
der Servicefunktionen; Verfügbar für einzelne Module
> Sehr geringer Konfigurationsaufwand
Das Einsatzgebiet von MICROSAR Multi-core umfasst den Betrieb der vorhandenen Prozessorkerne mit
> der BSW auf einem der vorhandenen Kerne und
> beliebiger Aufteilung der Anwendungssoftware auf alle verfügbaren Kerne.
Ziel dieser Herangehensweise ist es, die Anwendung mit dem höchsten Maß an CPU-Nutzung auf mehrere Prozessorkerne zu
verteilen. MICROSAR Multi-core bietet hierbei folgende Funktionalitäten:
> 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.
21.3 Funktionen
21.3.1 RTE
Die MICROSAR.RTE verwendet im Multi-core Umfeld bevorzugt Shared Memory, um Laufzeit und Speicherbelegung zu
minimieren. Bei Bedarf werden Spinlocks verwendet, um die Datenkonsistenz abzusichern. Dabei entstehen nur dann
Wartezeiten für die Prozessorkerne, wenn sie zur gleichen Zeit auf den gleichen Speicherbereich zugreifen.
21.3.2 Operating System
Für alle beteiligten Prozessorkerne ist nur eine einzige OS-Konfiguration notwendig. Über den AUTOSAR-Standard
hinausgehend bietet MICROSAR Multi-core effiziente Spinlocks, wodurch die Daten in allgemein zugänglichen
Speicherbereichen gehalten werden können.
21.3.3 ECU Manager
Der ECU-Manager läuft auf dem Hauptprozessorkern. Das Handling zwischen den Kernen wird jeweils über einen Satelliten
auf jedem weiteren Kern bewerkstelligt. Hierdurch ist auch beim ECUM nur eine einzige Konfiguration erforderlich, die für alle
Prozessorkerne Gültigkeit hat.
74
MICROSAR
21.3.4 Watchdog Manager
Der Watchdog Manager läuft ebenfalls auf dem Hauptprozessorkern. Auf allen weiteren Kernen besteht ein Satellit, welcher
die "checkpoint reached" Funktion der Anwendung verarbeitet und deren Status mit dem Master synchronisiert. Dies
gewährleistet eine laufzeitoptimierte Abwicklung der Servicefunktionen des WDGM.
21.4 Konfiguration
21.4.1 Konfiguration des OS
Für das Betriebssystem wird in der Konfiguration ein Prozessorkern statisch zugewiesen. Hierdurch wird festgelegt, welcher
Prozessorkern als Master fungiert und welche Kerne als Slave.
Bild 50: Zuweisung der Prozessorkerne mit DaVinci Configurator Pro
21.4.2 Konfiguration der RTE
Die RTE muss wissen, welche Software auf welchem Prozessorkern läuft. Nur dann ist die RTE in der Lage
> die Konsistenz des Datenaustauschs zu sichern
> im Bedarfsfall die runnables auch Prozessorkern-übergreifend zu aktivieren
Hierzu erfolgt bei der Konfiguration ein mapping der einzelnen runnables auf OS Tasks und nachfolgend die Zuweisung dieser
Tasks zu einer OS-Applikation. Jede OS-Applikation wird dann wieder auf einen konkreten Prozessorkern gemappt.
Bild 51: Mapping von SWCs, Tasks und OS Instanzen auf die Prozessorkerne, schematische Darstellung
Für eine komfortable Konfiguration Ihres Steuergerätes empfehlen wir den DaVinci Configurator Pro. Mehr Details hierzu
75
MICROSAR
Bild 52: Mapping von Funktionen auf OS-Tasks im Da Vinci Configurator Pro
21.5 Weitere relevante Produkte für MICROSAR Multi-core
> MICROSAR.RTE: Die RTE regelt die Prozessorkern-übergreifende Kommunikation
> WDGIF und WDGM aus MICROSAR Safe: Auf jedem Prozessorkern befindet sich jeweils eine eigene Instanz der beiden
Watchdog-Module, dies gewährleistet einen effizienten API-Zugriff.
> ECUM aus MICROSAR.SYS: Der ECU Manager stellt sicher, dass das System auf allen Prozessorkernen korrekt und
synchron hochgefahren wird.
> Sie benötigen zusätzlich hardwareabhängige Module wie das Betriebssystem MICROSAR.OS und einen WDG Treiber.
21.6 Lieferumfang
Im Rahmen der Lieferung erhalten sie alle gewählten Module aus dem MICROSAR-Paket in einem für Multi-core Projekte
geeigneten Umfang.
76
MICROSAR
22 MICROSAR Variantenhandling - Lösungen für die flexible Konfigurationen in AUTOSAR
Bei der traditionellen Aufgabenverteilung der Steuergeräteentwicklung definiert der Fahrzeughersteller die Kommunikationsund 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
Entwicklung von Steuergeräten mit einer volatilen BSW-Konfiguration kann durch die Flexibilität des optionalen MICROSAR
Post-Build Loadable profitieren.
Zusätzlich nimmt in den Automobilen die Anzahl der Steuergeräte, die in unterschiedlichen Varianten verbaut werden können
stetig zu - sogenannte Mehrfachsteuergeräte. Ihr Vorteil ist das Verwenden einer einzigen Hardware für die
unterschiedlichen Einsatzbereiche. Das reduziert Hardwarekosten und den Aufwand bei der Lagerverwaltung. Im Gegenzug
entsteht ein 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.
22.1 Post-Build Loadable – Nachträgliche Modifikation von BSW-Merkmalen
22.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
AUTOSAR
> Post-Build Loadable ist als Option für zahlreiche BSW-Module und Funktionen verfügbar
22.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 BSWParameter 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.
22.1.3 Vertrauter Konfigurationsprozess
Der Konfigurationsprozess zum Post-Build-Zeitpunkt findet mit dem Standard-Konfigurationswerkzeug DaVinci
Configurator Pro statt. Es steht somit ein mächtiges Werkzeuge für die reibungslose Synchronisation mit einer Vielzahl von
Datenbanken (DBC, SystemDescription, ODX, CDD…) zur Verfügung.
Über die MICROSAR Post-Build Loadable-Werkzeugkette wird in einem einfachen Schritt eine HEX-Datei der aktualisierten
BSW-Konfiguration erzeugt, die mit Standard-Flash-Werkzeugen in das Steuergerät geladen werden kann.
77
MICROSAR
Bild 53: MICROSAR Post-Build Loadable Workflow
22.1.4 Lieferumfang "Post-Build Loadable"
> Lizenz für die Freischaltung im Konfigurations-Werkzeug
> Werkzeuge zur Erstellung eines Build Loadable Updates
> Dokumentation
22.2 Der MICROSAR Identity Manager - die Post-Build Selectable Lösung für Mehrfachsteuergeräte
22.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
22.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
Teilenummer realisiert werden. Gefertigt wird also nur noch ein einziges Steuergerät, das beim Hochfahren über die ihm
zugewiesene 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
Baureihe eine unterschiedliche Kommunikationsbeschreibung. Die bei der Konfiguration zugrunde liegenden Datenbanken
können sich bei den verwendeten Varianten deutlich unterscheiden – zum Beispiel durch ein komplett anderes Signallayout
oder eine unterschiedliche Anzahl an Netzwerken.
78
MICROSAR
Bild 54: Einsatz eines Steuergerätes mit unterschiedlichen Funktionen unter Verwendung des Identity Managers
22.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.
22.2.4 Variantenauswahl
Sofern ein Steuergerät mehrere Konfigurationsvarianten unterstützt, wird die zu verwendende Variante bei der
Steuergeräte-Initialisierung ausgewählt. Die Quelle der Varianteninformation ist frei definierbar und wird durch die
Anwendung realisiert. Dies kann zum Beispiel eine Steckercodierung oder eine Speichercodierung in Flash sein.
22.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.
22.2.6 Lieferumfang "Post-Build Selectable"
> Lizenz für die Freischaltung im Konfigurations-Werkzeug
> BSW-Module mit Identity Manager Funktionalität
> Dokumentation
79
MICROSAR
23 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 J1939Netzen 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 55: Die MICROSAR J1939 Module nach AUTOSAR 4.2
23.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ützung der voll-dynamischen Adressierung und Adressüberwachung für selbstkonfigurierende Steuergeräte.
> J1939NM kann gemeinsam mit CANNM eingesetzt werden, um Adress-Arbitrierung und Sleep/Wakeup zu kombinieren.
> J1939RM: Direkte Anbindung an die Module J1939NM, J1939DCM, COM und RTE sowie CDDs. Voller Zugriff auf
Request mit Timeout-Überwachung und Acknowledgement (SAE J1939-21).
> J1939TP:
> Vollständige Implementierung des J1939-Transportprotokolls nach SAE J1939-81 mit den Varianten BAM und CMDT
(RTS/CTS), erweitert um die Unterstützung für das erweiterte Transportprotokoll nach ISO 11783-3 (ETP) und das
FastPacket Transportprotokoll gemäß NMEA2000.
> Automatische Auswahl des richtigen Transportprotokolls (direkt, BAM, CMDT, ETP) anhand der Botschaftsgröße und
der Zieladresse, Empfang von Botschaften über beliebige Transportprotokolle.
> J1939TP (BAM und CMDT) auch für AUTOSAR 3.x.
> J1939DCM: Diagnosemodul für die Nutzfahrzeug-Diagnose gemäß SAE J1939-73. Voll integrierte Lösung mit
gemeinsamer Nutzung der gespeicherten Diagnosedaten des DEM über J1939- und UDS-Diagnose.
> Routing von Botschaften basierend auf ihrer PGN, unabhängig von Quell- und Zieladressen, auch direkt aufeinander
folgender Botschaften
80
MICROSAR
> 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
Implementierung 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.
23.3 Funktionen
Die BSW-Module für J1939 enthalten die in AUTOSAR 4.x definierten Funktionen, insbesondere:
> J1939NM: Adress-Arbitrierung gemäß SAE J1939-81 für J1939-Netzwerke mit unveränderlichen Adressen
> J1939RM: Unterstützung des Anfrage/Antwortprotokolls (Request, Acknowledgement) gemäß SAE J1939-21
> J1939TP: J1939-Transport-Layer mit Unterstützung für Broadcast- (BAM) und gerichtete Kommunikation (CMDT bzw.
RTS/CTS) gemäß SAE J1939-21
> J1939DCM: Unterstützung der wichtigsten Diagnose-Botschaften aus SAE J1939-73, Parallel-Betrieb mit DCM
Folgende Funktionalitäten gehen über den AUTOSAR-Standard hinaus und sind optional erhältlich:
> J1939NM/CANIF: Erweiterung um voll-dynamische Adressierung, mit automatischer Änderung der eigenen Adresse im
Konfliktfall und automatischer Anpassung aller verwendeten Adressen an aktuelle Änderungen
> J1939TP: Erweiterung um die Transport-Protokolle ETP (nach ISO11783-3 bzw. -7) und FastPacket (nach NMEA200)
23.4 Konfiguration
23.5 Weitere relevante MICROSAR Produkte für J1939
> DEM aus MICROSAR.DIAG
> DET, BSWM, ECUM und COMM aus MICROSAR.SYS
Verwendung zusammen mit CANoe.XCP und CANoe.AMD sowie CANape optimiert. Für CAN-Steuergeräte enthält
MICROSAR XCP die passende Transportschicht CANXCP.
Über den AUTOSAR-Standard hinaus unterstützt MICROSAR XCP das generische Auslesen von Messobjekten. In der
nicht gestattet.
81
MICROSAR
24 MICROSAR VTT – Virtuelle Integration mit vVIRTUALtarget Basic
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
notwendigen SWCs zu erstellen und diese dann für sich alleine, in der Interaktion untereinander und am Ende auch im
Zusammenspiel mit der Basissoftware auf der Ziel-Hardware zu testen.
Zahlreiche Projekte stellen sich heute so dar, dass bereits in einer sehr frühen Projektphase mit Testläufen begonnen werden
muss, teilweise in einer Phase, in der die spätere Ziel-Hardware noch nicht schlussendlich definiert wurde.
Bild 56: Klassischer Steuergeräte-Entwicklungsprozess
Für diese Situation bietet vVIRTUALtarget (VTT) die passende Lösung. vVIRTUALtarget ist eine Laufzeitumgebung, 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 57: Steuergeräte-Entwicklungsprozess mit vVIRTUALtarget
Die Steuergeräte-Software und deren Bedatung sind nach der Entwicklung der SWCs und deren System-Integration in
einem fortgeschrittenen Stadium. Neben der Applikation wird nun auch die Konfiguration der Basissoftware konkreter
betrachtet. Hier bietet vVIRTUALtarget die Möglichkeit, unabhängig von der Zielplattform zu testen.
82
MICROSAR
Bild 58: Der Anwendungsbereich von vVIRTUALtarget (Version Pro in Entwicklung)
24.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
> Die Dual-Target Option erlaubt 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 Workflow in Steuergeräte-Entwicklung durch den Einsatz von vVIRTUALtarget Basic.
> Verbesserte Simulation von Unterbrechungen durch Interrupts und Task-Preemption.
MICROSAR vVIRTUALtarget ist überall einsetzbar, wo die Steuergeräte-Integration beschleunigt werden soll. Für die
Stimulation und Messung von Kommunikation und I/O Interfaces wird eine CANoe Lizenz benötigt.
24.3 Funktionen
vVIRTUALtarget Basic ist für die Steuergeräte-Integration vorgesehen und ermöglicht den Test des kompletten Stacks
(Applikation, SWCs, BSW) in einer virtuellen Umgebung. Es bietet dabei folgende Funktionen:
> Frühzeitiger Test des kompletten Stack, auch wenn das reale Steuergerät noch nicht verfügbar ist.
> Verwenden derselben MICROSAR-Konfiguration sowohl auf der Ziel-Hardware als auch in vVIRTUALtarget.
> Komfortableres Testen der Steuergeräte-Software in der virtuellen Umgebung
> Unterstützung von AUTOSAR-konformen 3rd Party Modulen
24.3.1 vVIRTUALtarget im Verbund mit CANoe
Das Tool vVIRTUALtarget erzeugt basierend auf der aktuellen MICROSAR-Konfiguration ein Visual Studio Projekt, in dem aus
den BSW-Modulen und der Applikation sehr komfortabel eine "System under Test" Windows-DLL (SUT DLL) erstellt werden
83
MICROSAR
kann. Nachfolgend ist dann ein Debugging möglich. Unsere Lösung vVirtualTarget ist entwickelt für Microsoft Visual Studio
2013 (Express & Professional).
Bild 59: Das Dual Target-Prinzip
Für das Debugging stehen zwei Möglichkeiten zur Verfügung: Zum einen kann das Debugging direkt in der Laufzeitumgebung
von vVIRTUALtarget durchgeführt werden. Zum anderen kann CANoe als Laufzeit- bzw. Debug-Umgebung verwendet
werden, hier können schließlich die Busse und IO-Schnittstellen der erzeugten SUT DLL stimuliert und visualisiert werden.
24.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“ SC1 ohne Multi-core-Erweiterungen.
Die übrigen BSW-Module benötigen keine Anpassung, um in der Umgebung von vVIRTUALtarget ausgeführt zu werden.
Hierbei handelt es sich um dieselben BSW-Module, die auch im realen Steuergerät zum Einsatz kommen.
24.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 benötigen gegebenenfalls
besondere Einstellungen, sofern Sie durch das Konfigurationstool DaVinci Configurator Pro nicht automatisch abgeleitet
werden können.
84
MICROSAR
Bild 60: Der MICROSAR-Workflow erweitert um den Workflow von vVIRTUALtarget
24.5 Konfiguration
separaten Produktinformation. Die Konfiguration der vVIRTUALtarget -Laufzeitumgebung erfolgt über die Option.VTT, die
für den DaVinciConfigurator Pro erhältlich ist.
24.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), oder die Lieferung erfolgt als DualTarget SIP in Verbindung mit Treibern für eine vom Kunden definierte reale Hardware-Plattform (realer MCAL +
vVIRTUALtarget MCAL).
24.7 Systemvoraussetzungen
Unser Produkt vVIRTUALtarget ist eine 64-Bit Anwendung und setzt dem entsprechend ein 64-Bit System voraus.
24.8 Weitere relevante MICROSAR Produkte für VTT
Zum Kennenlernen der virtuellen Integration und Erprobung ihrer Funktionsweise ist das Evaluierungspaket "AUTOSAR
Evaluation Bundle VTT" erhältlich. Nähere Informationen erhalten Sie im Kapitel "AUTOSAR Evaluierungspaket.
85
MICROSAR
25 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
entscheidenden 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.
25.1 Das Software Integration Package (SIP)
Das MICROSAR.SIP ist eine Standard-Lieferposition und stellt eine möglichst breite Verwendbarkeit Ihres Stacks in den
Mittelpunkt. 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.
Unterstü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
Steuergerä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
Compiler/Linker–Optionen). Hier betrachten wir Ihre konkreten Randbedingungen des Projekts möglichst nahe, damit
die Integration des Produkts bei Ihnen problemlos erfolgen kann. So wählen wir beispielsweise aus der Produkt-Familie
des von Ihnen gewählten Microcontrollers ein Evaluation Board mit geeignetem Derivat aus und testen hierauf das
Software-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.
25.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.
86
MICROSAR
Bild 61: Das MICROSAR Software Integration Package und seine optionalen Zusatzleistungen
25.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ätespezifischen Eingangsdaten bezüglich Kommunikation (z.B. den ECU-Extract) und Diagnose (z.B. ECUC). Die Start
Applikation demonstriert die grundsätzliche SIP-Funktionalität basierend auf den bestellten Modulen. Dies sind beispielweise:
> Kommunikation: Die in der Start Applikation beinhalteten SWCs demonstrieren den Empfang und das Senden eines
Signal auf Ebene der runnables. Die BSW wird so konfiguriert, dass das System initialisiert wird und auf allen in den
Eingangsdaten beschriebenen Bus-Systemen kommuniziert.
> Diagnose: Die in der Start Applikation beinhalteten SWCs werden erweitert um eine beispielhafte Implementierung
eines RDBI/WDBI Dienstes auf runnable Ebene. Darüber hinaus bietet sie die Möglichkeit, einen Diagnostic Trouble
Code (DTC) auszulösen.
> Memory: Die in der Start Applikation beinhalteten SWCs werden um eine beispielhafte Implementierung erweitert die
es erlaubt, Daten in einen NV-Block zu schreiben.
Für die Ausführung dieser Teilpunkte ist Voraussetzung, dass die dazu erforderlichen MICROSAR Module in der Lieferung
enthalten sind.
Zu der Basisleistung des SIP sind darüber hinausgehend folgende erweiterte Dienstleistungen erhältlich:
Vom Fahrzeughersteller unabhängige Erweiterungen ermöglichen Ihnen einen einfachen Start durch die Umsetzung
wesentlicher 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 AUTOSARBasissoftware
87
MICROSAR
> 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.
25.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
Verwendung 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 62: Das Extended Integration Package im Zusammenspiel mit den SIP-Optionen
88
MICROSAR
25.2.1 Das Anwendungsgebiet des EIP
Das MICROSAR.EIP stellt eine erweiterte Dienstleistung dar mit dem Ziel, sehr kurzfristig nach der Auslieferung eine
Mustervorlage für den ersten Vernetzungstest beim OEM verfügbar zu haben. Das EIP ist daher eine Option, welche
insbesondere 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
Serviceleistung 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
Mitarbeiter 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.
25.3 Konfiguration
Für eine komfortable Konfiguration Ihrer MICROSAR Lieferung empfehlen wir den DaVinci Configurator Pro. Mehr Details
25.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.
89
MICROSAR
26 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
Entwicklung Ihrer ersten Steuergerätesoftware mit AUTOSAR-konformer Softwarearchitektur. Sie erhalten damit einen
tiefen Einblick in die AUTOSAR-Welt, vom Entwurfs- und Konfigurationsprozess bis zur konkreten Basissoftware. OEMspezifische BSW-Module z.B. für Diagnose erhalten Sie in unserem MICROSAR Prototypen SIP (siehe Ende dieses Kapitels).
26.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
AUTOSAR
> 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).
26.3 Funktionen
Das AUTOSAR-Evaluierungspaket enthält die Werkzeuge und Embedded Software von Vector für das Erstellen einer
kompletten 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
komplexer 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.
Mithilfe 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
komfortable 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
Netzwerke und Steuergeräte. Diese Daten exportieren Sie über Standardformate und verwenden sie zur automatischen
Konfiguration der MICROSAR Diagnose-Basissoftware.
90
MICROSAR
Bild 63: Entwurf von Softwarekomponenten mit DaVinci Developer
Bild 64: 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.
26.4 Enthaltene BSW-Pakete
Die folgende Tabelle gibt Ihnen einen Überblick der einzelnen MICROSAR Pakete, die im AUTOSAR-Evaluierungspaket
enthalten sind. Eine komplette Beschreibung der jeweiligen Pakete entnehmen Sie den separaten Kapiteln in diesem
Dokument.
Im EVAL-Bundle
enthalten:
MICROSAR.OS
Erhältliche Optionen
> 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
91
MICROSAR
Im EVAL-Bundle
enthalten:
MICROSAR.MEM
Erhältliche Optionen
> 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 InterIntegrated Circuit Bus „ I2C“)
> FLASHTST, RAMTST, CORETST
MICROSAR. IO
MICROSAR. RTE
Zusätzlich können zum Evaluierungspaket hinzubestellt werden:
Modul
MICROSAR. EXT
MICROSAR. VTT
MICROSAR Safe
Beschreibung
> Module zur Ansteuerung von externen Bausteinen
> Lösung für virtuelle Integration mit vVIRTUALtarget
> Komplette Lösung für sicherheitsrelevante Funktionssoftware nach ISO 26262
26.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
> der „Configuration Conformance Class“ CCC 2.
26.6 Zusätzlich enthaltene Umfänge
> Beispielapplikation als Source-Code und ein ausführlicher Leitfaden zu deren Einsatz.
> AUTOSAR-Training bei Vector
26.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.
92
MICROSAR
26.8 Verfügbare Hardware-Plattformen
Das AUTOSAR-Evaluierungspaket ist für die gängigsten 16-Bit und 32-Bit Hardware-Plattformen verfügbar. Aufgrund der
Hardwareabhängigkeit der MICROSAR.MCAL Module und dem MICROSAR.OS können verbindliche Aussagen nur auf Basis
der konkreten Derivatsnummer der Prozessoren gegeben werden. Hier steht Ihnen das Vector Sales Team gerne zur
Verfügung.
Innerhalb einer Evaluierung können Sie zeitliche und personelle Ressourcen sparen, indem sie die VC-Hardware von Vector
einsetzen. Passend zu der VC-Hardware bietet Vector auch die entsprechende Unterstützung in der MICROSAR
Basissoftware an, wodurch die Inbetriebnahme der Basissoftware im Steuergerät besonders einfach ist. Die VC121
Hardware wird softwareseitig durch folgende Inhalte unterstützt:
> VC121 SW LIB
> MCAL VC121
> vFlash (mit passendem Template für den integrierten Flash Bootloader auf der VC121)
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.
26.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.
93
MICROSAR
27 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.
94
Mehr Informationen
Besuchen Sie unsere Website für:
> News
> Produkte
> Demo-Software
> Support
> Seminare und Workshops
> Kontaktadressen
www.vector.com

MICROSAR Produktinformation

Transcription

Similar documents

Quo Vadis SAE J1939

Produktinformation CANbedded

408 Salzburg

Realistische Darstellung von CAD-Modellen

Produktinformation

ESCAR Presentation: Current Status of the AUTOSAR Security

Preview - UVS Info