DE102021202133A1

DE102021202133A1 - Verfahren, Vorrichtung und Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Steuergerät

Info

Publication number: DE102021202133A1
Application number: DE102021202133.6A
Authority: DE
Inventors: Ulrich Mayer
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-03-05
Filing date: 2021-03-05
Publication date: 2022-09-08

Abstract

Die Offenbarungen betrifft ein Verfahren (100), eine Vorrichtung (510) und eine Konfigurationsumgebung (530) zum Erzeugen von Konfigurationsdaten für ein Steuergerät (520) gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug.

Description

Stand der Technik
Die Offenbarung betrifft ein Verfahren, eine Vorrichtung und eine Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Steuergerät gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug.
Mit AUTOSAR (AUTomotive Open System ARchitecture) wird eine Entwicklungspartnerschaft aus Automobilherstellern, Steuergeräteherstellern sowie Herstellern von Entwicklungswerkzeugen, Steuergeräte-Basis-Software und Mikrocontrollern bezeichnet, deren Ziel darin besteht, den Austausch von Software auf verschiedenen Steuergeräten zu erleichtern.
AUTOSAR stellt eine Reihe von Spezifikationen zur Verfügung, die grundlegende Softwaremodule beschreiben, Anwendungsschnittstellen definieren und eine gemeinsame Entwicklungsmethodik auf der Grundlage eines standardisierten Austauschformats erstellen. Basissoftwaremodule, die durch die AUTOSAR Layered Software Architecture zur Verfügung gestellt werden, können in Fahrzeugen unterschiedlicher Hersteller und Elektronikkomponenten unterschiedlicher Anbieter eingesetzt werden.
Die AUTOSAR Classic Plattform ist der Standard für eingebettete Echtzeit-Steuergeräte auf Basis von OSEK. Neue Anwendungsfälle, wie zum Beispiel das autonomes oder teilautonomes Fahren, erforderten die Entwicklung der AUTOSAR Adaptive Plattform. Weitere Informationen sind beispielsweise verfügbar unter https://www.autosar.org/standards/adaptive-platform/.
Im Vergleich zur AUTOSAR Classic Platform verknüpft die AUTOSAR-Laufzeitumgebung für die Adaptive Platform Dienste und Clients dynamisch während der Laufzeit.
Für die Adaptive Plattform stehen zwei Arten von Schnittstellen zur Verfügung: Dienste und Anwendungsprogrammierschnittstellen (APIs). Die Plattform besteht aus Funktionsclustern, die in Dienste und die AUTOSAR Adaptive Plattform Basis gruppiert sind. Funktionscluster fassen Funktionalitäten der Adaptiven Plattform zusammen, definieren die Clusterung der Anforderungsspezifikation und beschreiben das Verhalten der Software-Plattform aus Anwendungs- und Netzwerksicht. Funktionscluster beschränken jedoch nicht das endgültige Software-Design der Architektur, die die Adaptive Plattform implementiert. Adaptive Plattform-Dienste umfassen Update- und Konfigurationsverwaltung, Statusverwaltung Netzwerk Management, und Diagnose. Funktionscluster in der AUTOSAR Adaptive Platform Basis müssen mindestens eine Instanz pro (virtueller) Maschine umfassen, während Dienste im fahrzeuginternen Netzwerk verteilt sein können.
Die Offenbarung ist inhaltlich in den des Adaptive AUTOSAR Standard, insbesondere AUTOSAR Adaptive Release 19.11 und spätere, speziell in das AUTOSAR Dokument Specification of Manifest einzuordnen. Das Dokument beschreibt die im Standard vorgesehenen, und insbesondere zur Laufzeit wirksamen, Konfigurations-Möglichkeiten für die Adaptive AUTOSAR Software. Der AUTOSAR Standard definiert ein XML-basiertes Austauschformat, ARXML, und eine Methodik wie die beteiligten Stakeholder der Entwicklungspartnerschaft ihre Anteile beitragen. Die in AUTOSAR Methodik definierten Schritte finden auf dem Backend statt, wobei die bestehende Infrastruktur für das Handling von ARXML Daten Windows, Eclipse oder Java basiert ist. Diese umfängliche Infrastruktur ist auf einer meist Unix oder C++ basierten Zielumgebung nicht verfügbar. Der AUTOSAR Standard definiert kein konkretes Verfahren wie die Inhalte der ARXML-Daten in der Zielumgebung wirksam werden können. Der vorliegenden Offenbarung liegt die Aufgabe zugrunde, ein Verfahren bereitzustellen, mit dem diese Aufgabe gelöst werden kann.
Offenbarung der Erfindung
Bevorzugte Ausführungsformen betreffen ein Verfahren zum Erzeugen von Konfigurationsdaten für ein Zielsystem, insbesondere ein Steuergerät gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug, umfassend die folgenden Schritte:

Bereitstellen von XML-Daten, insbesondere AUTOSAR-ARXML-Daten, wobei die XML-Daten gemäß dem AUTOSAR-Standard definierte Anforderungen erfüllen;
Erstellen einer Beschreibung einer Konfigurations-Struktur in Abhängigkeit des Zielsystems, insbesondere des Steuergeräts, insbesondere einer Steuergeräteumgebung, und
Extrahieren von Konfigurationsdaten aus den XML-Daten in Abhängigkeit der Beschreibung der Konfigurations-Struktur.

Die vorliegende Offenbarung stellt ein Verfahren zur Aufbereitung von Konfigurationsdaten für Adaptive AUTOSAR Software bereit, mit dem sichergestellt werden kann, dass die bereitgestellten XML-Daten nach der Installation auf dem Zielsystem, insbesondere in der Zielumgebung, Zielsystems zur Anwendung zu kommen.
Bei dem Zielsystem handelt es sich beispielsweise um ein Steuergerät mit einer Unix oder C++ basierten Umgebung. Auf dieser ist keine umfängliche Infrastruktur für das Handling von XML-Daten verfügbar. Das offenbarte Verfahren für bereitgestellte XML-Daten der Adaptive AUTOSAR Software beschreibt, wie Konfigurationsdaten aus den bereitgestellten XML-Daten extrahiert werden, um nach der Installation auf der Zielumgebung zur Anwendung zu kommen und dabei insbesondere die für Steuergeräte im Automotive Bereich erforderlicher Absicherung, automotive safety integrity level D, ASIL-D, zu gewährleisten.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Erstellen der Beschreibung der Konfigurations-Struktur umfasst:

Charakterisieren einer Struktur, insbesondere einer Verschachtelungsstruktur, der Konfigurationsdaten und/oder Charakterisieren von Transformationsregeln zum Extrahieren von Konfigurationsdaten aus den XML-Daten und/oder Erzeugen von Dokumentation und Entwicklungsressourcen zum Extrahieren der Daten und/oder Anwenden der Konfigurationsdaten. Die Struktur wird insbesondere in Bezug auf Knoten und/oder Attribute und/oder Referenzen und/oder Container charakterisiert.

Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Extrahieren von Konfigurationsdaten aus den XML-Daten umfasst: Extrahieren von Inhalten aus den XML-Daten, insbesondere pro Funktionscluster, basierend auf Transformationsregeln, und/oder Extrahieren einer, Plattformkonfiguration.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Verfahren weiter umfasst, wenigstens einen Schritt zum Bearbeiten der Konfigurationsdaten.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Bearbeiten der Konfigurationsdaten einen Schritt zum Patchen der Konfigurationsdaten umfasst. Dieser Schritt findet insbesondere im Entwicklungs- und/oder Testkontext Anwendung. Durch Patchen werden die Konfigurationsdaten erweitert und/oder modifiziert. Auf diese Weise können beispielsweise, insbesondere neue, Funktionen getestet werden, die beispielsweise in den XML-Daten noch nicht vorgesehen ist.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Bearbeiten der Konfigurationsdaten wenigstens einen Schritt zum Erstellen von Daten, insbesondere für eine Plattformkonfiguration und/oder für eine Funktionscluster-Konfiguration und/oder für eine Modellzusammenführung, umfasst. Unter der Datenerstellung für die Plattformkonfiguration wird gemäß der vorliegenden Offenbarung die Spezifizierung einer vorgesehenen Konfiguration für beteiligte Funktionscluster in einem gegebenen Umfang verstanden. Umfasst ist beispielsweise eine bestimmte Applikation, ein bestimmtes Funktionscluster oder eine Kombination von Applikationen und/oder Funktionsclustern. Dabei kann es sich um einen manuellen Editier-Anwendungsfall handeln. Unter der Datenerstellung für die Funktionscluster-Konfiguration wird gemäß der vorliegenden Offenbarung verstanden, dass Inhalte der Konfigurationsdaten einem bestimmten Funktionscluster zugeordnet werden. Davon umfasst sind vorzugsweise, aber nicht ausschließlich, auch Teile der Konfigurationsdaten, für die keine Transformationsregeln existieren und die daher nicht automatisch durch Extrahieren aus den XML-Daten generiert werden können. Unter Modellzusammenführung wird hier verstanden, dass Inhalte aus zwei oder mehr Dateien in ein gemeinsames Modell geladen und in einer einzigen Datei gespeichert werden. Die innere Ordnung dieser Datei wird für die Verwendung in der Zielumgebung optimiert. Die Dateien, die in zu einem Modell zusammengeführt werden, umfassen Daten, die entweder einer Plattformkonfiguration oder einem Funktionscluster zugeordnet sind.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Bearbeiten der Konfigurationsdaten ein Anpassen der Konfigurationsdaten an eine vorgebbare Version der Konfigurations-Struktur umfasst. In diesem Schritt werden beispielsweise Versionsänderungen in der Konfigurations-Struktur auf die Konfigurationsdaten angewendet. Anwendungsfälle sind beispielsweise ein Upgrade auf eine kompatible Version der Konfigurations-Struktur oder eine Downgrade auf eine frühere Version. Ein Upgrade betrifft insbesondere nur die Versionierungs-Metadaten und hat keine Auswirkung auf den eigentlichen Inhalt der Konfigurationsdaten. Bei einem Downgrade können gegebenenfalls Daten entfernt werden.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Verfahren wenigstens einen Schritt zum Hinzufügen von Metadaten, insbesondere Metadaten-Attributen, zu den Konfigurationsdaten umfasst. Anhand der Metadaten-Attribute wird beispielsweise gekennzeichnet, ob es sich um extrahierte, gepatchte, oder einer Plattformkonfiguration oder einem bestimmten Funktionscluster zugeordnete Konfigurationsdaten handelt.
Gemäß einer weiteren Ausführungsform ist vorgesehen, dass das Verfahren wenigstens einen Schritt zum Vorbereiten der Konfigurationsdaten für ein Übertragen, insbesondere Installieren, auf das Zielsystem umfasst. In diesem Schritt werden die Inhalte der Konfigurationsdaten für das Übertragen vorbereitet. Für die Konfigurations-Struktur umfasst dieser Schritt beispielsweise eine Bereinigung von Attributen, die in der Zielumgebung nicht benötigt werden, wie beispielsweise Bemerkungen. Für Konfigurationsdaten wird dieser Schritt beispielsweise auf zusammengeführte Dateien angewendet. In beiden Fällen wird beispielsweise die innere Ordnung der zusammengeführten Dateien für die Verwendung auf dem Zielsystem optimiert.
Das offenbarte Verfahren für bereitgestellte XML-Daten der Adaptive AUTOSAR Software beschreibt, wie die in bereitgestellten XML-Daten gefiltert, strukturiert, ergänzt und abgesichert werden um nach der Installation auf der Zielumgebung zur Anwendung zu kommen.
Weitere Ausführungsformen betreffen ein Verfahren zum Konfigurieren eines Zielsystems, insbesondere eines Steuergeräts umfassend Schritte eines Verfahrens zum Erzeugen von Konfigurationsdaten für das Zielsystem gemäß den beschriebenen Ausführungsformen und einen Schritt zum Übertragen der Konfigurationsdaten auf das Zielsystem. Durch das Übertragen, insbesondere Installieren, auf dem Zielsystem, insbesondere Steuergerät, werden einsatzfähige Konfigurationsdaten, insbesondere in Form von Containern, auf der Zielumgebung zur Verfügung gestellt.
Weitere Ausführungsformen betreffen eine Vorrichtung zum Erzeugen von Konfigurationsdaten für ein Zielsystem, insbesondere ein Steuergerät und/oder zum Konfigurieren eines/des Zielsystems, wobei die Vorrichtung dazu ausgebildet ist, ein Verfahren zum Erzeugen von Konfigurationsdaten für das Zielsystem gemäß den beschriebenen Ausführungsformen und/oder ein Verfahren zum Konfigurieren des Zielsystems gemäß den beschriebenen Ausführungsformen auszuführen.
Weitere Ausführungsformen betreffen ein Bereitstellen einer Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Zielsystem, insbesondere ein Steuergerät gemäß einem Verfahren zum Erzeugen von Konfigurationsdaten für das Zielsystem gemäß den beschriebenen Ausführungsformen und/oder zum Konfigurieren eines Zielsystems gemäß einem Verfahren zum Konfigurieren des Zielsystems gemäß den beschriebenen Ausführungsformen, insbesondere auf einer Vorrichtung gemäß den beschriebenen Ausführungsformen. Die Konfigurationsumgebung erlaubt eine schlanke Infrastruktur um Konfigurationsdaten aus bereitgestellten XML-Daten zu extrahieren und gegebenenfalls anzureichern, um die Konfigurationsdaten in der Zielumgebung mit der, insbesondere im Automotive Bereich erforderlichen Absicherung gemäß automotive safety integrity level D, ASIL-D, bereitzustellen. Ein Software-Entwicklungsprojekt kann z. B. ein Prozessmodell verwenden, das auf dem von der Object Management Group (OMG) entwickelten SoftwareProcessEngineeringMetamodel (SPEM) basiert. SPEM basiert auf der Unified Modeling Language (UML), einer grafischen Sprache für die Modellierung diskreter Systeme.
Weitere Ausführungsformen betreffen einen Datenträger, umfassend Daten zum Bereitstellen einer Konfigurationsumgebung gemäß den beschriebenen Ausführungsformen.
Die beschriebenen Ausführungsformen können insbesondere im VRTE, Vehicle Runtime Environment, Kontext angewendet werden.
Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in den Figuren der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Ansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung bzw. Darstellung in der Beschreibung bzw. in der Zeichnung.
In der Zeichnung zeigt:

1 schematisch ein Flussdiagramm in einer schematischen Darstellung eines Verfahren gemäß bevorzugten Ausführungsformen;
2 schematisch ein Modell in einer schematischen Darstellung des Verfahren gemäß weiteren bevorzugten Ausführungsformen;
3a bis 3f beispielhafte Anwendungsfälle von Schritten des Verfahrens gemäß 1 und/oder beispielhafte Anwendungsfälle des Modells aus 2 in einer schematischen Darstellung;
4 schematisch ein Flussdiagramm in einer schematischen Darstellung eines weiteren Verfahrens gemäß weiteren bevorzugten Ausführungsformen, und
5 schematisch ein Blockdiagramm eines Systems in einer schematischen Darstellung gemäß weiteren bevorzugten Ausführungsformen.

Im Folgenden wird ein Verfahren 100 zum Erzeugen von Konfigurationsdaten für ein Zielsystem anhand der 1 und 2 erläutert.
Bei dem Zielsystem handelt es sich insbesondere um ein Steuergerät gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug.
Das Verfahren 100 umfasst einen Schritt 110 zum Bereitstellen von XML-Daten, insbesondere AUTOSAR-ARXML-Daten, wobei die XML-Daten gemäß dem AUTOSAR-Standard definierte Anforderungen erfüllen.
Das Verfahren 100 umfasst weiter einen Schritt 120 zum Erstellen einer Beschreibung einer Konfigurations-Struktur in Abhängigkeit des Zielsystems, insbesondere des Steuergeräts, insbesondere einer Steuergeräteumgebung. Der Schritt 120 umfasst beispielsweise Charakterisieren 120a einer Struktur, insbesondere einer Verschachtelungsstruktur, der Konfigurationsdaten, und/oder Charakterisieren 120b von Transformationsregeln zum Extrahieren von Konfigurationsdaten aus den XML-Daten und/oder Erzeugen 120c von Dokumentation und Entwicklungsressourcen zum Extrahieren der Daten und/oder Anwenden der Konfigurationsdaten.
Das Verfahren 100 umfasst weiter einen Schritt 130 zum Extrahieren von Konfigurationsdaten aus den XML-Daten in Abhängigkeit der Beschreibung der Konfigurations-Struktur. Der Schritt 130 umfasst beispielsweise Extrahieren 130a von Inhalten aus den XML-Daten, insbesondere pro Funktionscluster, basierend auf Transformationsregeln, und/oder Extrahieren 130b einer Plattformkonfiguration.
Das Verfahren 100 umfasst weiter einen Schritt 140 zum Bearbeiten der Konfigurationsdaten umfasst.
Gemäß einer Ausführungsform umfasst das Bearbeiten 140 der Konfigurationsdaten beispielsweise einen Schritt 140a zum Patchen der Konfigurationsdaten.
Gemäß einer Ausführungsform umfasst das Bearbeiten 140 der Konfigurationsdaten beispielsweise einen Schritt zum Erstellen 140b von Daten, insbesondere für eine Plattformkonfiguration und/oder für eine Funktionscluster-Konfiguration und/oder für eine Modellzusammenführung.
Gemäß einer Ausführungsform umfasst das Bearbeiten 140 der Konfigurationsdaten beispielsweise einen Schritt zum Anpassen 140c der Konfigurationsdaten an eine Version der Konfigurations-Struktur.
Das Verfahren 100 umfasst weiter einen Schritt 150 zum Hinzufügen 150 von Metadaten, insbesondere Metadaten-Attributen, zu den Konfigurationsdaten.
Das Verfahren 100 umfasst weiter einen Schritt 160 zum Vorbereiten der Konfigurationsdaten für ein Übertragen, insbesondere Installieren, auf das Zielsystem.
2 zeigt ein Modell 2000 gemäß weiteren bevorzugten Ausführungsformen. Das Modell ist als ein Prozessmodell, insbesondere als ein Software Process Engineering Metamodel, SPEM, engl. Metamodell für Entwicklungsprozesse der Softwaretechnik dargestellt. SPEM basiert auf der Unified Modeling Language (UML), einer grafischen Sprache für die Modellierung diskreter Systeme.
Das Modell umfasst mehrere Aufgaben, engl. Tasks, 2100, vgl. 2 „TaskDefinition“, denen beispielsweise die einzelnen Schritte des Verfahrens 100 zugeordnet werden können. Weiter umfasst das Modell 2000 mehrere Arbeitsergebnisse, engl. Workproducts 2200, vgl. 2 „WorkProduktDefinition“, die als Input oder Output den Aufgaben 2100 zugeordnet sind. Weiter umfasst das Modell 2000 mehrere Werkzeuge, engl. Tools, 2300, vgl. 2 „ToolDefinition“, die insbesondere zum Ausführen oder zum Unterstützen der Aufgaben 2100 diesen zugeordnet sind. Weiter sind einzelne Schritte, engl. Steps 2400 dargestellt. Die Verbindungen zwischen den einzelnen Elementen des Modells umfassen die folgenden mit dem jeweiligen Bezugszeichen versehenen Verbindungstypen:

2: „used tool“
4: „input“
6: „output“
8: „inoutput“
10: „extends“
12: „related work product“
14: „composition“.

Konkret umfasst das Modell 2000 eine Aufgabe 2110 zum Einrichten des Projektbereichs, engl. „Set-up project area". Die Aufgabe 2110 umfasst beispielsweise Vorbereiten der Arbeitsumgebung mit den benötigten Dateien, die beispielsweise von einem jeweiligen Konfigurationsmanagementsystem bereitgestellt werden. Insbesondere wird durch die Aufgabe 2110 der Schritt 110 zum Bereitstellen 110 der XML-Daten, insbesondere AUTOSAR-ARXML-Daten ausgeführt. Die Aufgabe 2110 verwendet insbesondere ein Werkzeug 2310 „CM Client“ zum Erzeugen des Arbeitsergebnisses 2220 „Project area“.
Die Arbeitsergebnisse 2200 der im Folgenden beschriebenen Aufgaben erweitern das Arbeitsergebnis 2220 „Project Area“.
Weiter ist gemäß der dargestellten Ausführungsform eine Aufgabe 2120 zum Erstellen oder Bearbeiten von AUTOSAR Inhalten, engl. AUTOSAR-Authoring vorgesehen. Dabei wird gemäß der dargestellten Ausführungsform beispielhaft auf den AUTOSAR Standard Release 19-11 Bezug genommen, vgl. das Element 2500 „Guidance“ in 2. Die Aufgabe 2120 umfasst beispielsweise das Editieren von AUTOSAR-Inhalten, insbesondere XML-Daten, insbesondere AUTOSAR-ARXML-Daten, vgl. Schritt 2420a „Editing“. Die AUTOSAR-Inhalte umfassen beispielsweise Design- und Manifest-Artefakte. Erweiterte Editierfunktionen können darüber hinaus das Einrichten von Software-Clustern und/oder Software-Paketen unterstützen, vgl. Schritt 2420b „Describe SW Cluster“. Für den Fall, dass der AUTOSAR-Inhalt variantenreichen AUTOSAR-Inhalt umfasst, kann vorgesehen sein, dass die Editierfunktionen weiter einen Schritt zum Behandeln von Varianzen, insbesondere Binden der Varianzen, umfasst, vgl. Schritt 2420c „Variant Handling“. Dies erfordert einen disjunkten Projektbereich für die Varianz gebundenen Daten. Die Aufgabe 2120 verwendet insbesondere ein Werkzeug 2320a „AUTOSAR Authoring Tool" und/oder ein Werkzeug 2320b „AUTOSAR Variation Resolver“ zum Erzeugen von Arbeitsergebnissen 2220a „invariant arxml“, 2220b „variant rich arxml“ und 2220c „variant bound arxml“.
Eine Aufgabe 2130 zum Erstellen der Beschreibung der Konfigurations-Struktur, engl. Structure Authoring, umfasst beispielsweise gemäß dem Schritt 120 des Verfahrens 100 das Erstellen der Beschreibung der Konfigurations-Struktur in Abhängigkeit des Zielsystems. Insbesondere ist vorgesehen, dass durch Ausführen der Aufgabe 2130 die folgenden Schritte ausgeführt werden können: Charakterisieren einer Struktur, insbesondere einer Verschachtelungsstruktur, der Konfigurationsdaten und/oder Charakterisieren von Transformationsregeln zum Extrahieren von Konfigurationsdaten aus den XML-Daten und/oder Erzeugen von Dokumentation und Entwicklungsressourcen zum Extrahieren der Daten und/oder Anwenden der Konfigurationsdaten. Die Struktur wird insbesondere in Bezug auf Knoten und/oder Attribute und/oder Referenzen und/oder Container charakterisiert. Die Aufgabe 2130 verwendet insbesondere das Werkzeug 2330 „Structure Authoring Tool“ zum Erzeugen des Arbeitsergebnisses 2230a „Structure“ und/oder des Arbeitsergebnisses 2230b „transformation description“.
Weitere Details der Aufgabe 2130 sind in 3a dargestellt.
Weiter ist eine Aufgabe 2140 zum Extrahieren von Konfigurationsdaten, engl. Extract Data, vorgesehen. Durch die Aufgabe 2140 wird insbesondere der Schritt 130 zum Extrahieren von Konfigurationsdaten aus den XML-Daten in Abhängigkeit der Beschreibung der Konfigurations-Struktur des Verfahrens 100 ausgeführt. Durch Ausführen der Aufgabe 2140 wird insbesondere Extrahieren von Inhalten aus den XML-Daten, insbesondere pro Funktionscluster, basierend auf Transformationsregeln, und/oder Extrahieren einer Plattformkonfiguration ausgeführt.
Die Aufgabe verwendet insbesondere das Werkzeug 2340 „Extract data from arxml and platform configuration“ zum Erzeugen des Arbeitsergebnisses 2240 „extracted data“.
Gemäß der dargestellten Ausführungsform werden die extrahierten Daten mit einem Metadaten-Attribut „extracted“ versehen, vgl. Arbeitsergebnis 2240 „extracted data“.
Zum Ausführen dieser Aufgabe 2140 ist es vorteilhaft, wenn die folgenden Vorbedingungen erfüllt sind:

- Der vom Extraktionswerkzeug 2340 verwendete Projektbereich beherbergt alle direkt oder indirekt im Umfang befindlichen XML-Daten und
- der AUTOSAR-Inhalt ist konsistent, d. h. alle zu extrahierenden Referenzen lösen sich auf.

Weitere Details der Aufgabe 2140 sind in 3b dargestellt.
Weiter ist eine Aufgabe 2150 zum Patchen der Konfigurationsdaten, engl. Patch Data, vorgesehen. Durch die Aufgabe 2150 wird insbesondere der Schritt 140a zum Patchen der Konfigurationsdaten des Verfahrens 100 ausgeführt. Durch Patchen werden die Konfigurationsdaten erweitert und/oder modifiziert. Auf diese Weise können beispielsweise, insbesondere neue, Funktionen getestet werden, die beispielsweise in den XML-Daten noch nicht vorgesehen ist.
Die Aufgabe 2150 verwendet insbesondere das Werkzeug 2350 „Data Authoring Tool“ zum Erzeugen des Arbeitsergebnisses 2250 „patched data“.
Gemäß der dargestellten Ausführungsform werden die gepatchten Daten mit einem Metadaten-Attribut „patched“ versehen, vgl. Arbeitsergebnis 2250 „patched data“.
Weiter ist eine Aufgabe 2160 zum Erstellen von Daten, engl. Data Authoring, vorgesehen. Durch die Aufgaben 2160 wird insbesondere der Schritt 140b zum Erstellen von Daten, insbesondere für eine Plattformkonfiguration und/oder für eine Funktionscluster-Konfiguration und/oder für eine Modellzusammenführung, des Verfahrens 100 ausgeführt. Unter der Datenerstellung für die Plattformkonfiguration wird gemäß der vorliegenden Offenbarung die Spezifizierung einer vorgesehenen Konfiguration für beteiligte Funktionscluster in einem gegebenen Umfang verstanden. Umfasst ist beispielsweise eine bestimmte Applikation, ein bestimmtes Funktionscluster oder eine Kombination von Applikationen und/oder Funktionsclustern. Dabei kann es sich um einen manuellen Editier-Anwendungsfall handeln. Unter der Datenerstellung für die Funktionscluster-Konfiguration wird gemäß der vorliegenden Offenbarung verstanden, dass Inhalte der Konfigurationsdaten einem bestimmten Funktionscluster zugeordnet werden. Davon umfasst sind vorzugsweise, aber nicht ausschließlich, auch Teile der Konfigurationsdaten, für die keine Transformationsregeln existieren und die daher nicht automatisch durch Extrahieren aus den XML-Daten generiert werden können. Unter Modellzusammenführung wird hier verstanden, dass Inhalte aus zwei oder mehr Dateien in ein gemeinsames Modell geladen und in einer einzigen Datei gespeichert werden. Die innere Ordnung dieser Datei wird für die Verwendung in der Zielumgebung optimiert. Die Dateien, die in zu einem Modell zusammengeführt werden, umfassen Daten, die entweder einer Plattformkonfiguration oder einem Funktionscluster zugeordnet sind.
Gemäß der dargestellten Ausführungsform werden die erstellten Daten mit einem Metadaten-Attribut „edited“ und/oder einen Metadaten-Attribut „dedicated“ versehen, vgl. Arbeitsergebnis 2260b „edited and dedicated data“.
Die Aufgabe 2160 verwendet gemäß der dargestellten Ausführungsform ebenfalls das Werkzeug 2350 „Data Authoring Tool“ zum Erzeugen des Arbeitsergebnisses 2260a „platform Configuration“ und/oder des Arbeitsergebnisses 2260b „edited and dedicated data“.
Weitere Details der Aufgabe 2160 sind in 3c dargestellt.
Weiter ist eine Aufgabe 2170 zum Anpassen der Konfigurationsdaten an eine Version der Konfigurations-Struktur, engl. Data Version Migration, vorgesehen. Durch die Aufgabe 2170 wird insbesondere der Schritt 140c des Verfahrens 100 zum Anpassen der Konfigurationsdaten an eine Version der Konfigurations-Struktur ausgeführt. In diesem Schritt werden beispielsweise Versionsänderungen in der Konfigurations-Struktur auf die Konfigurationsdaten angewendet. Anwendungsfälle sind beispielsweise ein Upgrade auf eine kompatible Version der Konfigurations-Struktur oder eine Downgrade auf eine frühere Version. Ein Upgrade betrifft insbesondere nur die Versionierungs-Metadaten und hat keine Auswirkung auf den eigentlichen Inhalt der Konfigurationsdaten. Bei einem Downgrade können gegebenenfalls Daten entfernt werden. Dies wird gegebenenfalls durch das Metadaten-Attribut angezeigt.
Die Aufgabe 2170 verwendet insbesondere das Werkzeug 2370 „Data Version Migrator“ zum Erzeugen des Arbeitsergebnisses 2260b „edited and dedicated data".
Weitere Details der Aufgabe 2170 sind in 3d dargestellt.
Weiter ist eine Aufgabe 2180 zum Vorbereiten der Konfigurationsdaten für ein Übertragen, engl. Prepare Content for Deployment, vorgesehen. Durch die Aufgabe 2180 wird insbesondere der Schritt 160 zum Vorbereiten der Konfigurationsdaten für ein Übertragen, insbesondere Installieren, auf das Zielsystem umfasst. In diesem Schritt werden die Inhalte der Konfigurationsdaten für das Übertragen vorbereitet. Für die Konfigurations-Struktur umfasst dieser Schritt beispielsweise eine Bereinigung von Attributen, die in der Zielumgebung nicht benötigt werden, wie beispielsweise Bemerkungen. Für Konfigurationsdaten wird dieser Schritt beispielsweise auf zusammengeführte Dateien angewendet. In beiden Fällen wird beispielsweise die innere Ordnung der zusammengeführten Dateien für die Verwendung auf dem Zielsystem optimiert. In manchen Fällen werden die Konfigurationsstruktur und/oder der Dateninhalt der Konfigurationsdaten nicht direkt bereitgestellt, sondern werden in eine Nutzlast, engl. payload, insbesondere von Transportcontainern, transformiert. Dabei kann es sich als vorteilhaft erweisen, wenn aus Sicherheitsgründen, insbesondere durch eventuell verschachtelte Transformatoren, Header zu einer transformierten Nutzlast hinzugefügt werden. Weiter sind beispielsweise die folgenden Aspekte relevant:

- Zusammenführen von Inhalten, insbesondere um eine Anzahl der bereitzustellenden Container zu reduzieren, insbesondere unter Verwendung eines Werkzeugs 2380a „Model merger“,
- Erhöhen der Performance, insbesondere durch Aufräumen, Bereinigen und/oder Komprimieren der Daten, insbesondere unter Verwendung eines Werkzeugs 2380b „Model clean-up“,
- Erhöhen/Gewährleisten der Safety, insbesondere durch eine Prüfsumme, z.B. eine zyklische Redundanzprüfung, engl. cyclic redundancy check, CRC, und/oder Erhöhen/Gewährleisten von Security, insbesondere durch Hinzufügen einer Signatur und/oder Anwendung einer Verschlüsselung, insbesondere unter Verwendung eines Werkzeugs 2380c „Safety-/Security Transformer“.

Gemäß der dargestellten Ausführungsform verwendet die Aufgabe 2180 insbesondere das Werkzeug 2380a „Model merger“ und/oder das Werkzeug 2380b „Model clean-up“ und/oder das Werkzeug 2380c „Safety-/Security Transformer“ zum Erzeugen des Arbeitsergebnisses 2280a „merged data“ und/oder des Arbeitsergebnisses 2280b „Deployable Structure“ und/oder des Arbeitsergebnisses 2280c „Deployable Data“.
Gemäß der dargestellten Ausführungsform werden gemergte Daten mit einem Metadaten-Attribut „merged“ versehen, vgl. Arbeitsergebnis 2280a „merged data“.
Weitere Details der Aufgabe 2180 sind in 3e dargestellt.
Die 3a bis 3f zeigen beispielhafte Anwendungsfälle von Schritten des erfindungsgemäßen Verfahrens 100 und/oder des Modells 2000 insbesondere im VRTE, Vehicle Runtime Environment,-Kontext. Die Anwendungsfälle werden am Beispiel eines VRTE Funktionsclusters XYZ, beispielsweise anhand des Funktionsclusters Kommunikationsmanagement, engl. Communication Management, Abk. COM, beschrieben. Das Funktionscluster Kommunikationsmanagement unterstützt die Kommunikation via Ethernet, via AUTOSAR SOME/IP Protokoll sowie OS spezifische interprozessuale Kommunikation.
Der untere Teil der Darstellung in den 3a bis 3e zeigt dabei den Teil des SPEM Modells, der sich auf die Methode bezieht, im Umfang des jeweiligen Anwendungsfalls, und der obere Teil der Darstellung zeigt den Teil des SPEM Modells, der sich auf den Prozess bezieht, im Umfang des jeweiligen Anwendungsfalls. Zu den bereits aus 2 bekannten Elementen sind in den 3a bis 3f weiter Elemente der Metaklassen TaskUse 3100, WorkProductUse 3200 und ToolDefinition 3300 dargestellt. Die Metaklassen dienen zur Modellierung von SPEM Methoden, in diesem Fall insbesondere im VRTE, Vehicle Runtime Environment,-Kontext. „Use“ bedeutet in diesem Zusammenhang die Anpassung eines Elements auf einen konkreten Anwendungsfall. EineToolDefinition 3300 beschreibt bestimmte Fähigkeiten eines Werkzeugs 2300, dass bei der Ausführung einer Aufgabe 2100 „TaskDefinition“ unterstützt.
Die in den 3a bis 3f verwendeten Verbindungstypen zwischen den einzelnen Elementen umfassen zu den bereits vorstehend im Zusammenhang mit 2 genannten Verbindungstypen weiter:

16: „content trace“,
18: „implements“,
20: „related AUTOSAR schema“, und
22: „flow“.

3a zeigt einen Anwendungsfall 310 zum Erstellen der Beschreibung der Konfigurations-Struktur, engl. Structure Authoring anhand der TaskUse 3130 „Structure Authoring for XYZ". Für das Funktionscluster XYZ wird in diesem Anwendungsfall eine Beschreibung der Konfigurations-Struktur in Abhängigkeit des Zielsystems und Transformationsregeln zum Extrahieren von Daten erstellt. Dies erfordert ein spezielles Werkzeug, in diesem Fall das Werkzeug 2330 „Structure Authoring Tool“, das sowohl den Inhalt des aktuell gültigen AUTOSAR-Schemas anbietet und die Definition der Beschreibung der Konfigurationsstruktur und der Transformationsregeln unterstützt. Die „ToolDefinition“ 3330 beschreibt das Werkzeug 2330. Der Zugriff auf das AUTOSAR Schema wird über den WorkProductUse 3225 „Applicable AUTOSAR schema“ und das zugehörige Guidance 2500 „AUTOSAR Standard Release 19-11, für den Anwendungsfall konkretisier‟t. Die Arbeitsergebnisse 2230a „Structure“ 2230b „transformation description“ sind jeweils mit den Elementen der Klasse WorkProductUse 3230a „Structure for XYZ“ und 3230b „transformation description for XYZ“ für den Anwendungsfall konkretisiert.
Weitere Details des Anwendungsfalls 310 sind unter Bezugnahme auf die Aufgabe 2130 des in 2 dargestellten Modells 2000 beschrieben.
3b zeigt einen Anwendungsfall 320 zum Extrahieren von Konfigurationsdaten, engl. Extract Data, anhand der TaskUse 3140 „Extract Data for XYZ“. Die hauptsächliche Datenquelle für diesen Anwendungsfall ist der invariante oder variante adaptive AUTOSAR Inhalt, vgl. 2220a „invariant arxml“ und 2220c „variant bound arxml“. Basierend auf den anwendbaren Transformationsregeln, vgl. 2230b „transformation description“, die insbesondere im vorhergehenden Anwendungsfall erstellt wurden, erzeugt das Werkzeug 2340 „Extract data from arxml and platform configuration“ dementsprechend extrahierte Daten. Gemäß der dargestellten Ausführungsform ist das Werkzeug 2340 „Extract data from arxml and platform configuration“ mit der ToolDefinition 3340 „Extract data from arxml and platform configuration“, und die Arbeitsergebnisse 2220a „invariant arxml“, 2220c „variant bound arxml“, 2230b „transformation description“ und 2240 „generated Data“ mit den jeweiligen dazugehörigen Elementen der Klasse WorkProductUse 3220a „invariant arxml for XYZ“, 3220c „variant bound arxml for XYZ“, 3230b „transformation description for XYZ“ und 3240 „generated Data for XYZ“ konkretisiert.
Weitere Details des Anwendungsfalls 320 sind unter Bezugnahme auf die Aufgabe 2140 des in 2 dargestellten Modells 2000 beschrieben.
3c zeigt einen Anwendungsfall 330 zum Erstellen von Daten, engl. Data Authoring, anhand der beiden TaskUse 3160 „Data Authoring for XYZ“ und 3150 „Patch Data for XYZ“. Das Erstellen von Daten erfolgt grundsätzlich soweit möglich durch das Werkzeug 2320a „AUTOSAR Authoring Tool“ außerhalb dieses Anwendungsfalls. Darüber hinaus ist es im Rahmen dieses Anwendungsfalls möglich, Daten, insbesondere für eine Plattformkonfiguration und/oder für eine Funktionscluster-Konfiguration und/oder für eine Modellzusammenführung, zu erstellen. Dies erfolgt gemäß der dargestellten Ausführungsform durch die Arbeitsergebnisse 2260a „platform Configuration“, 2260b „edited and dedicated data“, 2250 „patched data‟, 2240 „extracted data“ und 2230a „Structure“ mit den jeweiligen dazugehörigen Elementen der Klasse WorkProductUse 3260a „platform Configuration“, 3260b „edited and dedicated data for XYZ“, 3250 „patched data for XYZ“, 3240 „extracted data for XYZ“ und 3230a „Structure for XYZ“ anhand des Werkzeugs 2350 „Data Authoring Tool“, dessen Funktion durch die ToolDefinition 3350 „Data Authoring Tool“ beschrieben ist.
Weitere Details des Anwendungsfalls 330 sind unter Bezugnahme auf die Aufgabe 2160 des in 2 dargestellten Modells 2000 beschrieben.
3d zeigt einen Anwendungsfall 340 zum Anpassen der Konfigurationsdaten an eine Version der Konfigurations-Struktur, engl. Data Version Migration, anhand der TaskUse 3170 „Data Version Migration for XYZ“. Die Konfigurationsdaten sollten vorteilhafterweise mit der geltenden Version der Konfigurations-Struktur synchronisiert sein. Versionsänderungen werden implizit wirksam, wenn Daten neu extrahiert werden. Alternativ kann eine Anpassung, auch als Versionsmigration bezeichnet, der Konfigurationsdaten an die Version der Konfigurations-Struktur durch diesen Anwendungsfall erreicht werden. Dies erfolgt gemäß der dargestellten Ausführungsform durch die Arbeitsergebnisse 2230a „Structure“, 2240 „extracted data“, 2250 „patched data“ und 2260b „edited and dedicated data“ mit den jeweiligen dazugehörigen Elementen der Klasse WorkProductUse 3230a „Structure for XYZ“, 3240 „extracted data for XYZ“, 3250 „patched data for XYZ“ und 3260b „edited and dedicated data for XYZ“ anhand des Werkzeugs 2370 „Data Version Migrator“, dessen Funktion durch die ToolDefinition 3370 „Data Version Migrator“ beschrieben ist.
Weitere Details des Anwendungsfalls 340 sind unter Bezugnahme auf die Aufgabe 2170 des in 2 dargestellten Modells 2000 beschrieben.
3e zeigt einen Anwendungsfall 350 zum Vorbereiten der Konfigurationsdaten für ein Übertragen, engl. Prepare Content for Deployment, anhand der TaksUse 3180 „Prepare Content for Deployment“. In manchen Fällen werden die Konfigurationsstruktur und/oder der Dateninhalt der Konfigurationsdaten nicht direkt bereitgestellt, sondern werden in eine Nutzlast, engl. payload, insbesondere von Transportcontainern, transformiert. Dabei kann es sich als vorteilhaft erweisen, wenn aus Sicherheitsgründen, insbesondere durch eventuell verschachtelte Transformatoren, Header zu einer transformierten Nutzlast hinzugefügt werden. Weiter sind beispielsweise die folgenden Aspekte relevant:

- Zusammenführen von Inhalten, insbesondere um eine Anzahl der bereitzustellenden Container zu reduzieren, und/oder
- Erhöhen der Performance, insbesondere durch Aufräumen, Bereinigen und/oder Komprimieren der Daten, und/oder
- Erhöhen/Gewährleisten der Safety.

Der Anwendungsfall erzeugt oder modifiziert gemäß der dargestellten Ausführungsform die Arbeitsergebnisse 2230a „Structure“, 2240 „extracted Data“, 2250 „patched Data“, 2260b „edited and dedicated Data“, 2280a „merged Data“, 2280b „Deployable Structure“ und 2280c „Deployable Data“ mit den jeweiligen dazugehörigen Elementen der Klasse WorkProductUse 3230a „Structure for XYZ“, 3240 „extracted Data for XYZ“, 3250 „patched Data for XYZ“, 3260b „edited and dedicated Data for XYZ“, 3280a „merged Data for XYZ“, 3280b „Deployable Structure for XYZ" und 3280c „Deployable Data for XYZ“, insbesondere anhand der Werkzeuge 2380a „Model merger“, 2380b „Model clean-up“ und 2380c „Safety-/Security Transformer“, deren Funktion durch die ToolDefinition 3380 „Prepare Content for Deployment Tool“ beschrieben ist.
Weitere Details des Anwendungsfalls 340 sind unter Bezugnahme auf die Aufgabe 2180 des in 2 dargestellten Modells 2000 beschrieben.
3f zeigt beispielhaft das Übertragen 360, insbesondere Installieren, der Konfigurationsdaten auf das Zielsystem und Verwenden der Konfigurationsdaten auf dem Zielsystem, engl. Installation and Usage on Target. Der Installationsprozess sorgt dafür, dass einsatzfähige Container für die Infrastruktur und Clients auf dem Zielsystem zur Verfügung gestellt werden. Das Übertragen und Installieren wird konkret durch die Funktionscluster Update und Configuration Management vorgegeben. Das Verwenden auf dem Zielsystem wird durch das Zielsystem selbst vorgegeben.
Konkret bedeutet dies am Beispiel der 3f, dass zum Anwenden der Arbeitsergebnisse 2280b „Deployable Structure“ und 2280c „Deployable Data“ auf dem Zielsystem ein Installationsprozess stattfinden muss. Das Installationsverfahren ist hier nicht weiter definiert.
Die Konfigurationsdaten werden auf einem definierten Ort im Zielsystem 3500 „Content Repository“ abgelegt. Über den Content Provider 3600 werden Mechanismen bereitgestellt, wie die Konfigurationsdaten verwendet werden können. Clients auf dem Zielsystem greifen über definierte Anwendungsschnittstellen 3700 auf diese Daten zu.
4 zeigt ein Verfahren 400 zum Konfigurieren eines Zielsystems, insbesondere eines Steuergeräts. Das Verfahren 400 umfasst Schritte des Verfahrens 100 gemäß 1 zum Erzeugen von Konfigurationsdaten für das Zielsystem und einen Schritt 410 zum Übertragen der Konfigurationsdaten auf das Zielsystem.
5 zeigt ein System 500 umfassend eine Vorrichtung 510 zum Erzeugen von Konfigurationsdaten für ein Zielsystem 520 und/oder zum Konfigurieren des Zielsystems 520. Die Vorrichtung 500 ist vorteilhafterweise dazu ausgebildet, das Verfahren 100 gemäß 1 und/oder das Verfahren 400 gemäß 4 auszuführen.
Bei dem Zielsystem 520 handelt es sich insbesondere um ein Steuergerät gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug.
Auf der Vorrichtung 520 wird eine Konfigurationsumgebung 530 zum Erzeugen von Konfigurationsdaten für das Zielsystem 520 gemäß dem Verfahren 100 und/oder zum Konfigurieren des Zielsystems 520 gemäß dem Verfahren 400 bereitgestellt.

Claims

Verfahren (100) zum Erzeugen von Konfigurationsdaten für ein Zielsystem, insbesondere ein Steuergerät gemäß dem AUTOSAR-Standard, insbesondere ein Steuergerät für ein Kraftfahrzeug, umfassend die folgenden Schritte: Bereitstellen (110) von XML-Daten, insbesondere AUTOSAR-ARXML-Daten, wobei die XML-Daten gemäß dem AUTOSAR-Standard definierte Anforderungen erfüllen; Erstellen (120) einer Beschreibung einer Konfigurations-Struktur in Abhängigkeit des Zielsystems, insbesondere des Steuergeräts, insbesondere einer Steuergeräteumgebung, und Extrahieren (130) von Konfigurationsdaten aus den XML-Daten in Abhängigkeit der Beschreibung der Konfigurations-Struktur.
Verfahren (100) nach Anspruch 1, wobei das Erstellen (120) der Beschreibung der Konfigurations-Struktur umfasst: Charakterisieren (120a) einer Struktur, insbesondere einer Verschachtelungsstruktur, der Konfigurationsdaten, und/oder Charakterisieren (120b) von Transformationsregeln zum Extrahieren von Konfigurationsdaten aus den XML-Daten und/oder Erzeugen (120c) von Dokumentation und Entwicklungsressourcen zum Extrahieren der Daten und/oder Anwenden der Konfigurationsdaten.
Verfahren (100) nach wenigstens einem der Ansprüche 1 oder 2, wobei das Extrahieren (130) von Konfigurationsdaten aus den XML-Daten umfasst: Extrahieren (130a) von Inhalten aus den XML-Daten, insbesondere pro Funktionscluster, basierend auf Transformationsregeln, und/oder Extrahieren (130b) einer Plattformkonfiguration.
Verfahren (100) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Verfahren weiter wenigstens einen Schritt (140) zum Bearbeiten der Konfigurationsdaten umfasst.
Verfahren (100) nach Anspruch 4, wobei das Bearbeiten (140) der Konfigurationsdaten einen Schritt (140a) zum Patchen der Konfigurationsdaten umfasst.
Verfahren (100) nach wenigstens einem der Ansprüche 4 oder 5, wobei das Bearbeiten (140) der Konfigurationsdaten wenigstens einen Schritt zum Erstellen (140b) von Daten, insbesondere für eine Plattformkonfiguration und/oder für eine Funktionscluster-Konfiguration und/oder für eine Modellzusammenführung, umfasst.
Verfahren (100) nach wenigstens einem der Ansprüche 4 bis 6, wobei das Bearbeiten (140) der Konfigurationsdaten ein Anpassen (140c) der Konfigurationsdaten an eine Version der Konfigurations-Struktur umfasst.
Verfahren (100) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Verfahren wenigstens einen Schritt zum Hinzufügen (150) von Metadaten, insbesondere Metadaten-Attributen, zu den Konfigurationsdaten umfasst.
Verfahren (100) nach wenigstens einem der vorhergehenden Ansprüche, wobei das Verfahren (100) wenigstens einen Schritt zum Vorbereiten (160) der Konfigurationsdaten für ein Übertragen, insbesondere Installieren, auf das Zielsystem (520) umfasst.
Verfahren (400) zum Konfigurieren eines Zielsystems (520), insbesondere eines Steuergeräts, umfassend Schritte eines Verfahrens (100) gemäß einem der Ansprüche 1 bis 9 zum Erzeugen von Konfigurationsdaten für das Zielsystem und einen Schritt (420) zum Übertragen der Konfigurationsdaten auf das Zielsystem (520).
Vorrichtung (510) zum Erzeugen von Konfigurationsdaten für ein Zielsystem (520), insbesondere ein Steuergerät und/oder zum Konfigurieren eines Zielsystems (520), wobei die Vorrichtung (510) dazu ausgebildet ist, ein Verfahren (100) nach einem der Ansprüche 1 bis 9 und/oder ein Verfahren (400) nach Anspruch 10 auszuführen.
Bereitstellen einer Konfigurationsumgebung (530) zum Erzeugen von Konfigurationsdaten für ein Zielsystem (520), insbesondere ein Steuergerät, gemäß einem Verfahren (100) nach wenigstens einem der Ansprüche 1 bis 9 und/oder zum Konfigurieren eines Zielsystems (520) gemäß einem Verfahren (400) nach Anspruch 10, insbesondere auf einer Vorrichtung (510) nach Anspruch 11.
Datenträger, umfassend Daten zum Bereitstellen einer Konfigurationsumgebung (530) gemäß Anspruch 12.