-
Die Erfindung betrifft ein Verfahren zum Simulieren eines Steuergeräts und eine Anordnung zur Durchführung des Verfahrens.
-
Stand der Technik
-
Steuergeräte, die bspw. in Kraftfahrzeugen zur Steuerung und Regelung unterschiedlicher Komponenten und Abläufe eingesetzt werden, sind elektronische Module, die bspw. von Sensoren erfasste Größen aufnehmen, auswerten und auf Grundlage dieser Auswertung Signale zur Steuerung und Regelung an weitere Komponenten, wie bspw. Aktoren, ausgeben.
-
In Kraftfahrzeugen kommunizieren Steuergeräte (ECU: electronic computing unit) über unterschiedliche Systembusse, wobei Informationen über Betriebszustände und weitere relevante Daten im Kraftfahrzeug ausgetauscht werden. Hierbei kann auch eine sogenannte On-Board-Diagnose (OBD) durchgeführt werden.
-
Die in Steuergeräten vorhandene Software lässt sich unterteilen in die sogenannte Infrastruktursoftware, die Basisfunktionen übernimmt und üblicherweise das Betriebssystem und Softwarekomponenten für die Kommunikation umfasst, sowie die Applikationssoftware, welche die gewünschte Funktionalität enthält.
-
Die Entwicklung der Software und der Hardware eines Steuergeräts kann parallel verlaufen. Daher kann es sein, dass Software im Rahmen des Entwicklungsprozesses getestet werden muss, obgleich das reale Steuergerät bzw. dessen Hardware noch nicht zur Verfügung steht. Doch ist es für das Testen notwendig, eine Simulation der Software durchführen zu können. Für diesen Fall ist es bekannt, eine Simulation des Steuergeräts auf einer PC-Plattform durchzuführen.
-
Die Druckschrift
EP 2 172 857 A1 beschreibt ein Rapid Prototyping System, das einen Anwendungskern und einen Simulationskern umfasst. Bei diesem wird durch den Anwendungskern eine sogenannte Kontrollbank ausgeführt, die Nutzerbefehle empfängt und für ein Simulationsprogramm Kontrollsignale erzeugt. Dabei ist vorgesehen, dass mit dem Simulationsprogramm Funktionen eines Kontrollsystems simuliert werden, wobei dieses Kontrollsystem auch als Steuergerät ausgebildet sein kann.
-
Die Druckschrift
DE 10 2005 044 236 A1 beschreibt ein Diagnosegerät, das für eine Simulation mindestens eines Steuergeräts verwendet wird, welches für eine On-Board-Diagnose (OBD) relevant ist. Mit dem Diagnosegerät kann weiterhin eine Kommunikation zwischen dem mindestens einen Steuergerät und mindestens einem Lesewerkzeug überprüft werden. Bei der Simulation des mindestens einen Steuergeräts können auch Fehlersimulationen eingespielt werden.
-
Es ist weiterhin ein als AUTOSAR (AUTomotive Open System Architecture) bezeichneter Standard bekannt, der eine Infrastruktur beschreibt, mit dem Softwarehersteller auf einer beliebigen Plattform eine Software zum Simulieren installieren können. AUTOSAR ist eine Entwicklungspartnerschaft aus Automobilherstellern, Steuergeräteherstellern sowie Herstellern von Entwicklungswerkzeugen, Steuergerätebasissoftware und Mikrocontrollern. Ziel ist es, den Austausch von Software auf verschiedenen Steuergeräten zu erleichtern. Dazu wurde eine einheitliche Softwarearchitektur mit einheitlichen Beschreibungs- und Konfigurationsformaten für eingebettete bzw. embedded Software in Automobilen erarbeitet. AUTOSAR definiert Methoden zur Beschreibung von Software im Fahrzeug, welche sicherstellen, dass Softwarekomponenten wiederverwendet, ausgetauscht, skaliert und integriert werden können. Als Simulationsplattform dient regelmäßig ein PC (Personal Computer).
-
Die AUTOSAR-Validierungsplattform (VAP) simuliert elektronische Steuergeräte (ECU) auf einer Standard-PC-Computerplattform. Die ECU-Hardware ist hin zu höheren Softwareschichten abstrahiert, indem die ECU-Hardware und die entsprechenden Treiber in der AUTOSAR-Basissoftware durch VAP-spezifische Hardwaretreibern ersetzt werden. Die Treibermodule steuern entweder physikalische Hardwarefunktionen mit physischen Einheiten oder simulieren Hardwarefunktionen mit simulierten Einheiten.
-
Eine auf solche Weise abstrahierte und simulierte ECU wird als virtuelle ECU oder auch VECU bezeichnet. Durch Instanziierung mehrerer VECUs auf einer einzigen leistungsfähigen Computerplattform mit mehreren CPUs, das sogenannte VAP-Target, ist VAP in der Lage, ein Netzwerk einer nahezu unbeschränkten Anzahl von VECUs aufzunehmen. Emulierte ECUs verwenden physische Einheiten und sind echtzeitfähig, wenn die Ressourcen des VAP-Target der VECU-AUTOSAR-Software korrekt zugeordnet sind. Simulierte ECUs verwenden simulierte Einheiten und ermöglichen es jeder VECU, alle Ressourcen der CPU zu nutzen.
-
Der Betriebszyklus von AUTOSAR konformer ECU-Software umfasst vier Hauptphasen:
- – Autorisierungsphase: In dieser Phase richtet der Nutzer eine AUTOSAR konforme Konfigurationsdatenbank ein, wobei er geeignete Konfigurationseditoren verwendet.
- – Quellcode-Generationsphase: In dieser wird die Konfigurationsdatenbank verwendet, um die Konfigurationsquelle und die Kopf- bzw. Header-Dateien zu erzeugen.
- – Bildungsphase: In dieser werden Anwendungs-Softwarekomponenten, Hardware unabhängige BSW-Softwarekomponenten (BSW: Steuergerätesoftware), Hardware abhängige Softwarekomponenten (Treiber) und die erzeugten Konfigurationsquelle und Headerdateien kompiliert und mit Bibliotheken verknüpft, um in der ECU ausführbar zu sein.
- – Laufzeitphase: In dieser wird die ausführbare ECU gestartet und betrieben. Im Zusammenhang mit VAP werden Experimente in der Laufzeitphase durchgeführt.
-
Eine ausführbare Standard-ECU ist statisch verbunden und enthält die erforderlichen Hardwaretreibermodule. Variationen für experimentelle Setups, wie bspw. Austausch von Hardware-Implementierungen, Austausch von physischen Einheiten durch simulierte Einheiten und umgekehrt, erfordern ein erneutes Bilden der statisch verbundenen, ausführbaren ECU. Die ursprüngliche, dem Kunden bereitgestellte ECU-Konfiguration muss geändert werden. Der vollständige Betriebszyklus von der Authorisierungsphase bis zur Laufzeitphase muss wiederholt werden.
-
Es gibt verschiedene Nachteile bei einer solchen vorübersetzten Zeitkonfiguration im Zusammenhang der AUTOSAR-Validierungsplattform:
Die ECU-Konfigurationsdatenbank des Kunden muss angepasst und geändert werden.
-
Die VECU-Software muss während der Autorisierung, der Codegenerierung und Bildungsphase überarbeitet werden, wenn die Laufzeitkonfiguration geändert wird. Diese Überarbeitung erfordert weitreichende Kenntnisse von AUTOSAR. Weiterhin stellt dies eine zeitaufwendige und fehleranfällige Aufgabe dar.
-
VAP spezifische Laufzeitkonfigurationen werden nicht durch AUTOSAR-Standardwerkzeuge abgedeckt.
-
Die Autorisierungsphase und Laufzeitphase sind miteinander verbunden, was zu den Arbeitsabläufen der Kunden nur bedingt passt. Ein getrenntes Lizensieren von Autorisierungs- und Laufzeitwerkzeugen ist so nicht möglich.
-
Offenbarung der Erfindung
-
Vor diesem Hintergrund werden ein Verfahren mit den Merkmalen des Anspruchs 1 und eine Anordnung gemäß Anspruch 8 vorgestellt. Weitere Ausführungen ergeben sich aus den abhängigen Ansprüchen und der Beschreibung.
-
Bei dem vorgestellten Verfahren zur Abstraktion einer Hardware eines Steuergeräts auf der Basis von AUTOSAR ist in Ausgestaltung vorgesehen, eine Konfiguration während einer Ladezeit vorzunehmen sowie weiterhin ein Plugin für einen Treiber zu konzipieren. Dabei wird auf Grundlage von Konfigurationsdateien eines realen Steuergeräts ein virtuelles Steuergerät bereitgestellt.
-
Zur Ladezeit kann eine Konfiguration des virtuellen Steuergeräts ausgeführt. Die Ladezeit ist ein Zeitraum, der vor dem eigentlichen Programmablauf, der Simulation mittels VECU, liegt und in dem Konfigurationen vorgenommen werden können.
-
Somit stellt das vorgestellte Verfahren eine sogenannte Konfiguration zur Ladezeit von virtuellen ECUs in Verbindung mit einem Plugin-Treiber-Konzept für Einheitentreiber bereit. Die Ladezeitkonfiguration ist vorteilhaft. So muss die ECU-Konfiguration des Kunden nicht geändert werden, wenn eine VECU zu VAP oder zurück zu der ursprünglichen Hardware portiert wird. Die Laufzeitkonfiguration und Parameter können geändert oder gesetzt werden, ohne die Software überarbeiten zu müssen. Die Autorisierungs- und Laufzeitphase sind streng entkoppelt. Die Autorisierungs-Werkzeugkette ist bei allen experimentellen Umgebungen nicht notwendigerweise erforderlich, was besser zum Arbeitsablauf des Kunden passt und ein Lizensieren vereinfacht.
-
Da die Konfiguration erfolgt, nachdem die VECU-Software in den Speicher des VAP-Targets geladen wurde, sind tiefere Laufzeitkonfigurationsänderungen und Variationen möglich. Weiterhin sind produktinterne Hardwarevariationen vor der ECU-Softwarekonfiguration verborgen.
-
Die vorgestellte Ladezeit-Konfiguration stellt ein flexibles Verfahren dar, um experimentelle Umgebungen für eine ECU-Software-Validierung einzurichten, ohne die AUTOSAR-Konfiguration, die mit dem Standard des Kunden übereinstimmt, ändern zu müssen.
-
Grundsätzlich wird in einem ersten Schritt die Hardware, auf der die Simulation ausgeführt wird, erkannt. Dies kann bedeuten, dass dies dem System bzw. dem VAP mitgeteilt wird. In einem nächsten Schritt wird eine Mikrocontroller-Abstraktionsschicht generiert, in der die Schnittstelle, über die die Hardwaretreiber mit der Software verbunden sind, angepasst ist.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt eine Ausführung des vorgestellten Verfahrens.
-
2 zeigt ein Zustandsdiagramm einer VECU.
-
3 zeigt ein Beispiel für ein Rahmenwerk einer Ladezeitkonfiguration und eines Treiber-Plugins.
-
Ausführungsformen der Erfindung
-
Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
-
In 1 ist eine mögliche Ausführung des vorgestellten Verfahrens in einem Flussdiagramm, einem sogenannten Konfigurationsfluss, beschrieben. In einem ersten Schritt 10 liegen die ECU-Konfigurationsdateien vor. In einem darauffolgenden Schritt 12 wird die ECU-Konfiguration angepasst. Anschließend wird in einem Schritt 14 der modifiziert Code für Treiber generiert. Hierzu wird die Treiber-Konfiguration-VAP 16 verwendet. Der modifitierte Code wird in VAP-Treiber-Proxies 18 eingegeben. Hierin erfolgt eine Übersetzung von Symbolen zu einer Sprungtabelle. Diese Treiberproxies 18 werden verwendet, um in einem nächsten Schritt 20 eine ausführbare Version der VECU zu bilden. Diese VECU wird in einem nächsten Schritt 22 verwendet, um die ausführbare Version der VECU auf das VAP-Target herunterzuladen. Diese geladene VECU wird in einem nächsten Schritt 24 ausgeführt.
-
Anschließend wird in einem Schritt 26 die ECU konfiguriert, hierzu werden Plugins geladen, Plugins initialisiert und Sprungtabellen ausgefüllt. In Sprungtabellen werden die Einsprung-Adressen von Software-Funktionen hinterlegt.
-
Hierzu werden VAP-Treiber-Plugins 28 verwendet. Parallel dazu (Schritt 40) erfolgt die Entwicklung der Plugins. Dann erfolgt in einem Schritt 30 das Starten der ausführbaren Version der VECU, anschließend (Schritt 32) ein Stoppen der ausführbaren Version und abschließend (Schritt 34) ein Entladen der ausführbaren Version.
-
In 2 sind in einem Zustandsdiagramm Zustände einer VECU wiedergegeben. Ein erster Zustand 50 ENTLADEN wird nach dem Starten eingenommen. Durch Laden der VECU in die VAP-Target-Steuerung (Pfeil 52) wird der Zustand 54 GELADEN eingenommen. Wird die VECU wieder entladen (Pfeil 56) erfolgt ein Rücksprung zum Zustand 50.
-
Ausgehend von irgendeinem Zustand 60 kann im Falle eines Fehlers (Pfeil 62) der Zustand 64 FEHLER eingenommen werden. Lädt ausgehend hiervon die VAP-Target-Steuerung die VECU, wird der Zustand 54 GELADEN eingenommen. Ausgehend von diesem Zustand 54 wird, wenn die VECU gestartet wird oder ein Autostart erfolgt, der Zustand 70 STARTUP eingenommen, in dem alte Plugins entladen, neue Plugins geladen und die gesammelte Konfiguration angewendet wird.
-
Im nächsten Zustand 72 AUSFÜHREN wird die VECU zur Ausführung gebracht. Ausgehend von diesem Zustand 72 erfolgt, wenn die VECU-Kontrolle eine Pause erfordert (Pfeil 74) die Einnahme des Zustands 77 PAUSE. Wird die Wiederaufnahme gefordert, wird wieder Zustand 72 eingenommen.
-
Ausgehend vom Zustand 72 wird, wenn die VECU-Steuerung dazu auffordert (Pfeil 76) der Zustand 78 ABGESCHLOSSEN eingenommen. Anschließend wird der Zustand 80 ABSCHALTEN eingenommen. Ausgehend vom Zustand 80 wird, wenn die VECU erneut geladen wird (Pfeil 82) der Zustand 54 eingenommen. Ausgehend vom Zustand 72 wird, wenn ein Fehler entdeckt wird (Pfeil 84) der Zustand 86 ERROR eingenommen. Wird ausgehend von diesem Zustand 86 die VECU erneut gestartet oder diese gestoppt (Pfeil 90) so erfolgt ein Übergang zum Zustand 80.
-
1 zeigt somit eine Übersicht des allgemeinen Konfigurationsflusses und 2 zeigt die zugeordneten Zustände der VECU. Sobald die VECU geladen wurde, was dem Zustand 54 entspricht, ist diese in dem Speicher der CPU und es gibt einen vollständigen Zugriff auf den gesamten Speicher und die Peripheriehardware. Die VECU AUTOSAR-Software läuft jedoch noch nicht.
-
Während der Laufzeitkonfiguration im Zustand 54 GELADEN werden Informationen gesammelt. Dieses Sammeln während der Laufzeitkonfiguration wird entweder interaktiv durchgeführt, wobei das VAP-Steuerwerkzeug verwendet wird, oder automatisch von einer vorab definierten Laufzeitkonfigurationsdatenbank. Die VECU tritt in den Zustand 70 STARTUP ein, wenn der Nutzer dazu auffordert, oder automatisch, wenn die Sammlung zur Laufzeitkonfiguration abgeschlossen ist. Im Zustand 70 STARTUP werden Gerätetreiber-Plugins geladen, wobei die darunter liegenden dynamischen Verbindungssysteme des Betriebssystems verwendet werden. Nachdem die Treiber-Plugins geladen wurden, wird die zuvor gesammelte Konfiguration ausgeführt. Während der Ausführung der Laufzeitkonfiguration werden die Treiber-Plugins initialisiert und die VECU-Software wird parametrisiert. Die VECU-Software ist nunmehr in der Lage, die ECU-Hardware vollständig zu abstrahieren und startet. Die VECU ist nunmehr im Zustand 72 AUSFÜHREN.
-
Unter einem Plugin ist ein Erweiterungsmodul zu verstehen, das ein Softwaremodul darstellt, das von einer Softwareanwendung während seiner Laufzeit entdeckt und eingebunden werden kann, um dessen Funktionalität zu erweitern.
-
Während des Zustands AUSFÜHREN dürfen die Laufzeitkonfigurationssammlung der VECU und die Treiber-plugins sich nicht ändern. Die Treiber-Plugins können im Zustand AUSFÜHREN nicht entladen werden. Es ist jedoch noch möglich, die VECU zu steuern und spezifische Laufzeitparameter zu Experimentzwecken zu ändern.
-
Die Rekonfiguration und der Austausch von Treiber-Plugins, bspw. der Austausch von simulierten Geräten durch physische Geräte, erfordern ein Abschalten der laufenden VECU-Software. Nachdem die VECU den Betrieb abgeschlossen hat, tritt diese in den Zustand 80 ABSCHALTEN, während die Treiber-Plugins sich vorbereiten, entladen oder erneut geladen zu werden, indem alle zugeordneten Systemressourcen freigegeben werden. Die VECU kann dann wieder den Zustand 52 GELADEN einnehmen und Treiber-Plugins können refonfiguriert oder sogar ausgetauscht werden.
-
3 zeigt das Rahmenwerk für die Ladezeitkonfiguration und das Treiber-Plugin, das insgesamt mit der Bezugsziffer 100 bezeichnet ist. Somit wird der logische Aufbau einer Software, am Beispiel CAN, die auf einem VAP-Target ausgeführt wird, gezeigt. Das VAP-Target ist bspw. ein PC. Die Darstellung zeigt die Hardware unabhängige VECU-Software 102, die den AUTOSAR-Bereich darstellt, und die Hardware- und Software-Struktur 104 auf der PC-Plattform. Eine ausführbare Version 106 der statischen VECU ist umrandet verdeutlicht.
-
Weiterhin sind eine VAP-Steuerung 108, ein VECU-Manager 110, ein PC 112, auf dem die Anwendung zur Ausführung kommt, und ein VAP-Hardware-Manager 114 dargestellt.
-
In der VECU-Software 102 sind die Identifizierer der Protokoll-Dateneinheit (protocol data unit ID) 116, Hardware-Objekt-handles 118, Controller 120 und eine CAN-Schnittstelle 122 vorgesehen. Ein Hardware-Objekt-handle repräsentiert eine abstrakte Referenz auf eine CAN-Mailbox-Struktur, die CAN bezogene Parameter enthält.
-
In der Hard- und Software-Struktur 104 ist ein erster Proxy 130 für einen Treiber A und ein zweiter Proxy 132 für einen Treiber B vorgesehen. Weiterhin sind ein Plugin X 134, ein Plugin Y 134, die eine Anbindung zu realen Treibern darstellen, CAN-Knoten 138 und eine Anzahl von Puffern 140 bereitgestellt.
-
Weiterhin ist eine Reihe von Schnittstellen gezeigt, nämlich eine AUTOSAR-API 150 mit Namenskonvention, eine AUTOSAR-API 152 ohne Namenskonvention, eine Plugin-API 154, eine Plattform API 156, eine Linux-Bibliotheks-API 158 für ein dynamisches Laden, eine API 160 für RTPC-Dienste, eine Schnittstelle 162 zum Steuern bzw. Überwachen der VECU-Software zur Laufzeit, eine VECU-Steuerungsschnittstelle 164 und eine VAP-Target-Steuerungsschnittstelle 166. API (application programming interface) steht dabei für eine Schnittstelle zur Anwendungsprogrammierung.
-
Das in 3 beispielhaft gezeigte Rahmenwerk 100 besteht aus folgenden Funktionskomponenten:
Treiberkonfiguration vor dem Kompilieren,
VECU-Manager,
VECU-Software,
Gerätetreiber-Proxy-Module,
Gerätetreiber-Plugin-Module,
Plugin-Ladeeinheit,
Konfigurationssammlung,
Konfigurationsausführung.
-
Der AUTOSAR-Softwareerstellungsprozess beruht auf einer statisch verbundenen ausführbaren Version der VECU, wobei Module in der ECU-Abstraktionsschicht zwischen Treibermodulimplementierungen für verschiedene zugrundeliegende Hardware durch Namenskonvention unterscheiden. Alle globalen Symbole, wie bspw. Funktionen und Variablen, der API (application programming interface: Programmerschnittstelle), die durch ein Treiber-Softwaremodul exportiert werden, werden erweitert, indem Verkäufer spezifische Informationen verwendet werden.
-
Diese implementationsspezifischen Symbolreferenzen können durch generische, implementierungsunabhängige, dynamisch gemeinsam genutzte Bibliotheken erfüllt werden, die in jede ECU-Implementierung passen müssen.
-
Jede statistische AUTOSAR konforme ausführbare Version der VECU erfordert eine AUTOSAR konforme Konfiguration der Treiberparameter, die typischerweise in dem ECU-ROM platziert sind. Lediglich der Gehalt und der C-Typenname der Konfigurationsstruktur sind standardisiert. Die interne Struktur des Konfigurationsdatensatzes ist spezifisch und transparent für höhere Softwareschichten. Das Letzere ermöglicht Treibern, Verkäufer spezifische Parameter einzubinden, die für Standard-AUTOSAR-Funktionen nicht sichtbar sind. Das Plugin-Konzept verwendet diesen Ansatz, indem dieses seine eigene interne VAP spezifische Struktur bereitstellt. Diese Struktur ersetzt Kundenstrukturen auf dieselbe Weise wie Proxytreiber-Module Kundentreibermodule ersetzen. VAP-spezifische Treiberkonfigurationen verstanden durch Treiber-Plugin-Module können leicht an diesem Punkt eingebunden werden. Es ist zu empfehlen, die Konfiguration in Speicherorte mit Ladezeitschreibzugriff anzuordnen. Diese Konfigurationsstrukturen werden zusammen mit der Proxytreiber-Modul-Codegeneration erzeugt.
-
Der VECU-Manager ist die Hauptausführungsstrang eines VECU-Prozesses. Dieser läuft, wenn die VECU geladen wird. Der VECU-Manager dient der VAP-Steuer-Schnittstelle und hat Zugriff auf das Datensystem des Computers. Dieser sammelt die VECU-Ladezeitkonfiguration, lädt Gerätetreiber-Plugin-Module und führt die VECU-Ladezeitkonfiguration aus. Dieser steuert ebenfalls die VECU-Software und überwacht deren Status während der Laufzeit.
-
Die VECU-Software enthält alle AUTOSAR definierten Software-Komponenten, wie bspw. Anwendungscode, Echtzeitbetriebssystem und grundlegende Software-Module.
-
Die Gerätetreiber-Proxymodule werden als eine Anpassungs- bzw. Adaptionsschicht zwischen der statisch verbundenen ausführbaren Version der VECU und den dynamisch geladenen Gerätetreiber-Plugin-Modulen verwendet. Ein Gerätetreiber-Proxy führt die folgenden spezifische Aufgaben durch:
Bereitstellen der AUTOSAR konformen API,
Übersetzen der namenbasierten Treiberimplementierung-Unterscheidung in adressbasierte Treiberimplentierung-Unterscheidung, wobei indizierte Sprungtabellen verwendet werden, die Symboladressen eher während der Ladezeit als während der Bildungszeit auflösen.
-
Da die Gerätetreiber-Proxymodule AUTOSAR konfigurationsspezifische Symbolnamen präsentieren müssen, werden diese automatisch während der AUTOSAR-Autorisierungsphase erzeugt. Für jeden kundendefinierten Hardware-Treiber wird ein Proxymodul erzeugt, wobei die Verkäufer-ID von der kundenerzeugten AUTOSAR-Konfigurationsdatenbank genommen wird. Die Codeerzeugung für Gerätetreiber-Proxymodule ist einfach, da die internen Funktionen der Proxytreibermodule AUTOSAR-Standardsignaturen und lediglich Adressübersetzungen bereitstellen müssen und eine Vorwärtsfunktionalität aufrufen.
-
Die Gerätetreiber-Pluginmodule enthalten die tatsächlichen Gerätefunktionen ohne Namenserweiterung. Es gibt ein Gerätetreiber-Plugin-Modul für jede VAP-Hardware oder jeden simulierten Gerätetyp. Die Gerätetreiber-Plugin-Module stellen eine Plugin-API mit den folgenden Diensten bereit:
-
– Erhalte Symbolreferenzen
-
Die Plugin-Module liefern einen Treiber spezifischen Satz von Laufzeitreferenzen, die durch das Rahmenwerk der Ladezeitkonfiguration verwendet werden, um die Sprungtabellen der Gerätetreiber-Proxymodule zu füllen.
-
– Setze Symbolreferenzen
-
Die Plugin-Module stellen eine Sprungtabelle bereit, um Funktionen in den Gerätetreiber-Proxymodulen zurückzurufen. Die Gerätetreiber-Proxymodul spezifischen Rückruffunktionen-Referenzen werden in diese Sprungtabellen eingesetzt.
-
– Initialisierung
-
Die Plugin-Module werden initialisiert. Es ist zu bemerken, dass dies nicht die AUTOSAR-ECU-Software-Initialisierung der Treiberfunktionalität ist. Der Letztere ist Teil des Dienstes, der durch das Plugin-Modul bereitgestellt wird.
-
– Deinitialisierung
-
Die Plugin-Module setzen alle zugewiesenen Ressourcen frei und sind bereit, um von dem Speicher entladen zu werden.
-
Die Konfigurationssammlung ist ein Dienst, der durch die VECU außerhalb AUTOSAR bereitgestellt wird. Dieser besteht aus einem Satz von Datenstrukturen, die während der Initialisierung der Gerätetreiber-Plugin-Module verwendet werden. Diese Datenstrukturen enthalten die folgende Ladezeitkonfigurationsinformation:
- – Gerätetreiber-Plugin-Auswahl,
- – Plugin spezifische Gerätetreiber, nicht-AUTOSAR-Parameter,
- – Laufzeitwerte für AUTOSAR-Parameter.
-
Die Konfigurationssammlung stellt also Mittel bereit, um diese Ladezeitkonfigurationsinformation von der VAP-Steuerschnittstelle oder von den Konfigurationsdateien zu empfangen.
-
Die Plugin-Modul-Ladeeinheit ist ein generischer Dienst, der durch die VECU außerhalb der AUTOSAR-Software bereitgestellt wird. Dieser verwendet die Konfigurationssammlung, um die ausgewählten Treiber-Plugins zu laden.
-
Die Konfigurationsausführung ist ein Dienst, der durch die VECU außerhalb der AUTOSAR-Software bereitgestellt wird. Dieser führt die folgenden Funktionen aus:
- – Initialisieren der geladenen Gerätetreiber-Plugins, wobei die Konfigurationssammlung spezifischen Nicht-AUTOSAR-Parameter verwendet werden,
- – Parametrisieren der VECU, wobei die Konfigurationssammlungslaufzeitwerte für AUTOSAR-Parameter verwendet werden.
-
Der AUTOSAR-Software-Erzeugungsprozess beruht auf einer statisch verbundene VECU, die ausführbar ist, wobei Module in der ECU-Abstraktionsschicht sich zwischen Treibermodulen und anderen Modulen unterscheiden.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- EP 2172857 A1 [0006]
- DE 102005044236 A1 [0007]
