DE102019213738A1 - Software-Komponenten für eine Software-Architektur - Google Patents

Software-Komponenten für eine Software-Architektur Download PDF

Info

Publication number
DE102019213738A1
DE102019213738A1 DE102019213738.5A DE102019213738A DE102019213738A1 DE 102019213738 A1 DE102019213738 A1 DE 102019213738A1 DE 102019213738 A DE102019213738 A DE 102019213738A DE 102019213738 A1 DE102019213738 A1 DE 102019213738A1
Authority
DE
Germany
Prior art keywords
software
software component
modules
component
runtime environment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019213738.5A
Other languages
English (en)
Inventor
Benny Bruhnke
Tobias Schwalm
Daniel König
Madan Kadambi
Toni Günther
Tran Tuan Nguyen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Priority to DE102019213738.5A priority Critical patent/DE102019213738A1/de
Priority to PCT/EP2020/074409 priority patent/WO2021047970A1/de
Publication of DE102019213738A1 publication Critical patent/DE102019213738A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code

Abstract

Die vorliegende Erfindung betrifft eine Software-Komponente (SW-C) für eine Software-Architektur sowie ein Verfahren, ein Computerprogramm mit Instruktionen und eine Vorrichtung zum Bereitstellen einer solchen Software-Komponente (SW-C). Die Erfindung betrifft zudem ein Steuergerät, in dem eine erfindungsgemäße Software-Komponente (SW-C) eingesetzt wird, sowie ein Kraftfahrzeug mit einem solchen Steuergerät. Die Software-Komponente (SW-C) für die Software-Architektur weist zwei oder mehr Software-Module (Mi) auf. Zudem weist die Software-Komponente (SW-C) eine Laufzeitumgebung (µRTE) für eine Kommunikation zwischen den zwei oder mehr Software-Modulen (Mi) auf.

Description

  • Die vorliegende Erfindung betrifft eine Software-Komponente für eine Software-Architektur sowie ein Verfahren, ein Computerprogramm mit Instruktionen und eine Vorrichtung zum Bereitstellen einer solchen Software-Komponente. Die Erfindung betrifft zudem ein Steuergerät, in dem eine erfindungsgemäße Software-Komponente eingesetzt wird, sowie ein Kraftfahrzeug mit einem solchen Steuergerät.
  • Die Entwicklungspartnerschaft AUTOSAR (AUTomotive Open System ARchitecture; www.autosar.org) ist eine weltweite Entwicklungspartnerschaft von Fahrzeugherstellern, Zulieferern, Dienstleistern und Unternehmen aus der Elektronik-, Halbleiter- und Softwareindustrie für die Automobilbranche. Ziel dieser Partnerschaft ist die Entwicklung und Etablierung eines offenen Industriestandards für die Automotive E/E-Architektur. AUTOSAR stellt Spezifikationen zur Verfügung, die unter anderem grundlegende Softwaremodule beschreiben und Anwendungsschnittstellen definieren.
  • Der AUTOSAR Classic Standard erlaubt die Integration von AUTOSAR-Software-Komponenten in die Gesamtsoftware beim Hardwarelieferanten als Blackboxes. Diese werden meist von einem durch den Fahrzeughersteller beauftragten Gewerk als Blackbox an den Hardwarelieferanten ausgeliefert. Der Lieferant integriert die Gesamtsoftware und liefert diese aus. Dadurch ist es dem Fahrzeughersteller möglich, selbst entwickelte Softwareanteile beim Bauteillieferanten mit einzubringen, ohne dass diesem der Code und somit das Knowhow offengelegt werden muss. Die Schnittstellen sind standardisiert. Somit ist auch eine Portabilität zwischen verschiedenen Steuergeräten und Lieferanten gewährleistet.
  • In diesem Zusammenhang beschreibt CN 109117121 A eine Implementierungsmethode für eine AUTOSAR-Softwarearchitektur. Eine Datenverwaltungsdatei wird durch ein Original-Datenprotokoll und ein Original-Simulationsmodul erzeugt. In der Datenverwaltungsdatei wird eine Datenabgleichserkennung durchgeführt. Aus der Datenverwaltungsdatei wird eine Konfigurationsschemadatei der AUTOSAR-Software erzeugt. Die Konfigurationsschemadatei wird dann in ein RTE-Konfigurationstool für eine Systemkonfiguration der AUTOSAR-Software importiert, um eine erste Systemkonfigurationsdatei zu erhalten. Gleichzeitig wird das Anwendungsarchitekturmodell der AUTOSAR-Software gemäß der Konfigurationsschemadatei generiert.
  • Zudem beschreibt KR 2014-0066531 A1 eine Komponentenarchitektur, die auf einer AUTOSAR-Softwarearchitektur basiert. Die Architektur beinhaltet eine Vielzahl von Anwendungskomponenten, eine erste Komponente, die eine Vielzahl von Runnables beinhaltet, die mit den Anwendungskomponenten verknüpft sind, und einen Hub-Runnable, der zum Datenaustausch mit den Runnables geeignet ist.
  • Durch den steigenden Anteil der Software im Fahrzeug nimmt die Anzahl der Software-Komponenten in den Bauteilen beständig zu. Durch die größere Anzahl der Software-Komponenten steigen die Kosten zur Integration dieser Software-Komponenten, da der Lieferant einen höheren Aufwand hat. Zudem nimmt die Fehleranfälligkeit zu, da deutlich mehr Schnittstellen zu bedienen sind. Da diese Schnittstellen über die vom Lieferanten bereitgestellte Software geroutet werden müssen, ist auch mit höheren Kosten zur Fehlerbehebung zu rechnen. Außerdem kommt es zu längeren Lieferzyklen, da der Lieferant bei der Fehlerbehebung beteiligt ist. Durch den ständig wachsenden Anteil der Software im Fahrzeug sind darüber hinaus immer mehr Lieferanten und Gewerke beteiligt, die Software-Komponenten liefern möchten oder sollen. Jede Software-Komponente hat dabei eine eigene Schnittstellenbeschreibung, z.B. in speziellen AUTOSAR-Formaten, die einzeln mit dem Lieferanten ausgetauscht, gepflegt und integriert werden müssen.
  • Es ist eine Aufgabe der Erfindung, Lösungen bereitzustellen, die eine Vereinfachung der Integration von Software-Komponenten in eine Software-Architektur ermöglichen.
  • Diese Aufgabe wird durch eine Software-Komponente mit den Merkmalen des Anspruchs 1, durch ein Verfahren mit den Merkmalen des Anspruchs 7, durch ein Computerprogramm mit Instruktionen gemäß Anspruch 8 und durch eine Vorrichtung mit den Merkmalen des Anspruchs 9 gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
  • Gemäß einem ersten Aspekt der Erfindung weist eine Software-Komponente für eine Software-Architektur zwei oder mehr Software-Module sowie eine Laufzeitumgebung für eine Kommunikation zwischen den zwei oder mehr Software-Modulen auf.
  • Gemäß einem weiteren Aspekt der Erfindung umfasst ein Verfahren zum Bereitstellen einer Software-Komponente für eine Software-Architektur die Schritte:
    • - Auswählen von zwei oder mehr Software-Modulen;
    • - Generieren einer Laufzeitumgebung für eine Kommunikation zwischen den zwei oder mehr Software-Modulen; und
    • - Integrieren der zwei oder mehr Software-Module und der Laufzeitumgebung in eine Software-Kom ponente.
  • Gemäß einem weiteren Aspekt der Erfindung enthält ein Computerprogramm Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der folgenden Schritte zum Bereitstellen einer Software-Komponente für eine Software-Architektur veranlassen:
    • - Auswählen von zwei oder mehr Software-Modulen;
    • - Generieren einer Laufzeitumgebung für eine Kommunikation zwischen den zwei oder mehr Software-Modulen; und
    • - Integrieren der zwei oder mehr Software-Module und der Laufzeitumgebung in eine Software-Kom ponente.
  • Der Begriff Computer ist dabei breit zu verstehen. Insbesondere umfasst er auch Workstations, verteilte Systeme und andere prozessorbasierte Datenverarbeitungsvorrichtungen.
  • Das Computerprogramm kann beispielsweise für einen elektronischen Abruf bereitgestellt werden oder auf einem computerlesbaren Speichermedium gespeichert sein.
  • Gemäß einem weiteren Aspekt der Erfindung weist eine Vorrichtung zum Bereitstellen einer Software-Komponente für eine Software-Architektur auf:
    • - eine Auswahleinheit zum Auswählen von zwei oder mehr Software-Modulen;
    • - einen Generator zum Generieren einer Laufzeitumgebung für eine Kommunikation zwischen den zwei oder mehr Software-Modulen; und
    • - eine Integrationseinheit zum Integrieren der zwei oder mehr Software-Module und der Laufzeitumgebung in eine Software-Komponente.
  • Bei der erfindungsgemäßen Lösung wird durch den Fahrzeughersteller eine Laufzeitumgebung innerhalb der Software-Komponente selbst generiert. Diese ermöglicht es, die Software-Module in der Software-Komponente miteinander zu verbinden, ohne dass der Hardwarelieferant davon Kenntnis hat. Durch das Zusammenfassen mehrerer Software-Module in einer Software-Komponente wird eine Möglichkeit geschaffen, die Anzahl der Software-Komponenten zu reduzieren. Auf diese Weise müssen nur wenige Software-Komponenten an den Bauteil-Integrator bzw. Hardwarelieferanten ausgeliefert werden. Dies reduziert sowohl die Kosten der Integration beim Hardwarelieferanten als auch die Fehleranfälligkeit. Bei der erfindungsgemäßen Lösung können Software-Module von verschiedenen Lieferanten oder Gewerken in einer Software-Komponente zusammengefasst werden. Das Bereitstellen der Software-Komponente erfolgt insbesondere im Rahmen der Integration für eine Software-Architektur.
  • Gemäß einem Aspekt der Erfindung erfolgt eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente direkt durch die zwei oder mehr Software-Module. Bei diesem Ansatz wird die Laufzeitumgebung innerhalb der Software-Komponente nur für die Kommunikation zwischen den Software-Modulen verwendet. Die Kommunikation nach außen wird durch die Software-Module direkt vorgenommen. Dies hat den Vorteil, dass die Laufzeitumgebung verhältnismäßig klein ausfallen kann, da nicht alle Möglichkeiten einer vollständigen Laufzeitumgebung für die Software-Architektur umgesetzt werden müssen. Dies führt zu einer Erhöhung der Performanz.
  • Gemäß einem Aspekt der Erfindung erfolgt eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente indirekt über die Laufzeitumgebung. Bei diesem Ansatz wird die Laufzeitumgebung innerhalb der Software-Komponente sowohl für die Kommunikation zwischen den Software-Modulen als auch für die externe Kommunikation der Software-Module verwendet. Die Kommunikation der Software-Module nach außen erfolgt somit über die Laufzeitumgebung. Dies hat den Vorteil, dass eine Filterung der Informationen möglich ist, die zwischen der Laufzeitumgebung der Software-Komponente und der Laufzeitumgebung der Software-Architektur ausgetauscht werden. Beispielsweise kann die Laufzeitumgebung der Software-Komponente einen Informationsumfang von 100% haben und somit alle Informationen der Software-Module beinhalten. Aber nur 50% der Informationen werden der Laufzeitumgebung der Software-Architektur offengelegt. Somit wird eine flexible Gestaltung ermöglicht.
  • Gemäß einem Aspekt der Erfindung handelt es sich bei der Software-Architektur um eine AUTOSAR-Software-Architektur. In diesem Fall weist die Laufzeitumgebung der Software-Komponente vorzugsweise standardisierte AUTOSAR-Schnittstellen auf. Da der AUTOSAR-Standard ein etablierter Standard im Automobilbereich ist, wird auf diese Weise eine umfassende Nutzung der erfindungsgemäßen Lösung ermöglicht.
  • Gemäß einem Aspekt der Erfindung weisen die zwei oder mehr Software-Module standardisierte AUTOSAR-Schnittstellen auf. Dies hat den Vorteil, dass alle Software-Module gegen standardisierte AUTOSAR-Schnittstellen entwickelt werden können. Zudem resultiert aus diesem Ansatz eine einfachere Portierbarkeit der Software-Module in andere Software-Komponenten oder als eigenständige Software-Komponente, da die Schnittstellen identisch bleiben. Auf diese Weise ist eine Wiederverwendung von Modulen deutlich effizienter möglich. Darüber hinaus kann der Software-Einsatz auf einer Zielhardware früher angefangen werden, da die Software-Module mit weniger Aufwand von einem Steuergerät Host zum einem anderen getauscht werden können. Ein weiterer Vorteil besteht darin, dass die Wartbarkeit des Quellcodes erleichtert wird und die Fehlersuche vereinfacht wird, da die Schnittstellen der Module einheitlich sind und kein Code händisch gepflegt werden muss.
  • Da nur die Schnittstellen der AUTOSAR-Software-Komponenten nach außen standardisiert sind, können die Software-Module, die in einer Software-Komponente zusammengefasst sind, intern aber auch über beliebige andere Schnittstellen und Mechanismen miteinander kommunizieren. Der AUTOSAR-Standard hört in seiner Beschreibung und Definition bei der Software-Komponente als kleinste zu betrachtende Einheit auf. Die im AUTOSAR-Standard beschriebenen Mechanismen zur internen Kommunikation innerhalb einer Software-Komponente unterliegen keinen strengen formalen Regeln zur Beschreibung von Schnittstellen unter Verwendung von Signalen. Allerdings ist der Umfang der einsetzbaren Kommunikationsmöglichkeiten eingeschränkt.
  • Der vorliegend beschriebene Ansatz ermöglicht erstmals gleichermaßen eine formale Beschreibung der Kommunikationsschnittstellen innerhalb der Software-Komponente als auch zwischen Software-Komponenten unter Verwendung von AUTOSAR Standard-Mechanismen. Dies ermöglicht einen homogenisierten Beantragungsprozess für Softwareschnittstellenänderungen unabhängig von der finalen Softwarearchitekturentscheidung.
  • Besonders vorteilhaft wird zumindest eine erfindungsgemäße Software-Komponente in einem Steuergerät für ein Kraftfahrzeug verwendet. Vorzugsweise wird ein solches Steuergerät in einem Kraftfahrzeug genutzt, beispielsweise in einem autonomen oder teilautonomen Kraftfahrzeug. Es kann dort insbesondere für automatische Fahrfunktionen genutzt werden, für die Software-Komponenten von einer Vielzahl von Lieferanten erforderlich sind. Darüber hinaus kann die erfindungsgemäße Lösung in allen Produkten genutzt werden, in denen Software von mehr als einem Lieferanten oder Gewerk integriert wird. Die erfindungsgemäße Lösung kann aber auch dann genutzt werden, wenn nur ein Gewerk beteiligt ist, um von vornherein eine portable Lösung vorzuhalten.
  • Weitere Merkmale der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung und den angehängten Ansprüchen in Verbindung mit den Figuren ersichtlich.
    • 1 zeigt schematisch ein Verfahren zum Bereitstellen einer Software-Komponente für eine Software-Architektur;
    • 2 zeigt eine erste Ausführungsform einer Vorrichtung zum Bereitstellen einer Software-Komponente für eine Software-Architektur;
    • 3 zeigt eine zweite Ausführungsform einer Vorrichtung zum Bereitstellen einer Software-Komponente für eine Software-Architektur;
    • 4 veranschaulicht den Aufbau einer AUTOSAR-Software-Architektur;
    • 5 illustriert einen ersten Ansatz für eine Integration von zwei Software-Modulen in eine Software-Komponente;
    • 6 illustriert einen zweiten Ansatz für eine Integration von zwei Software-Modulen in eine Software-Komponente; und
    • 7 stellt schematisch ein Kraftfahrzeug dar, in dem ein erfindungsgemäßes Steuergerät verwendet wird.
  • Zum besseren Verständnis der Prinzipien der vorliegenden Erfindung werden nachfolgend Ausführungsformen der Erfindung anhand der Figuren detaillierter erläutert. Es versteht sich, dass sich die Erfindung nicht auf diese Ausführungsformen beschränkt und dass die beschriebenen Merkmale auch kombiniert oder modifiziert werden können, ohne den Schutzbereich der Erfindung zu verlassen, wie er in den angehängten Ansprüchen definiert ist.
  • 1 zeigt schematisch ein Verfahren zum Bereitstellen einer Software-Komponente für eine Software-Architektur. In einem ersten Schritt werden zwei oder mehr Software-Module ausgewählt 10. Zudem wird eine Laufzeitumgebung (auf Englisch runtime environment, Abkürzung RTE) für eine Kommunikation zwischen den zwei oder mehr Software-Modulen generiert 11. Die zwei oder mehr Software-Module und die Laufzeitumgebung werden dann in eine Software-Komponente integriert 12. Die Software-Komponente kann dabei so ausgestaltet sein, dass eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente direkt durch die zwei oder mehr Software-Module erfolgt. Alternativ kann die Software-Komponente so ausgestaltet sein, dass eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente indirekt über die Laufzeitumgebung erfolgt. Bei der Software-Architektur kann es sich beispielsweise um eine AUTOSAR-Software-Architektur handeln. In diesem Fall weist die Laufzeitumgebung der Software-Komponente standardisierte AUTOSAR-Schnittstellen auf. Vorzugsweise weisen dann auch die zwei oder mehr Software-Module standardisierte AUTOSAR-Schnittstellen auf.
  • 2 zeigt eine vereinfachte schematische Darstellung einer ersten Ausführungsform einer Vorrichtung 20 zum Bereitstellen einer Software-Komponente für eine Software-Architektur. Die Vorrichtung 20 hat einen Eingang 21 zum Empfangen von Informationen, z.B. von Software-Modulen. Eine Auswahleinheit 22 ermöglicht das Auswählen von zwei oder mehr Software-Modulen, z.B. auf Basis einer Nutzereingabe oder unter Verwendung von Konfigurationsdaten. Ein Generator 23 dient zum Generieren einer Laufzeitumgebung für eine Kommunikation zwischen den zwei oder mehr Software-Modulen. Eine Integrationseinheit 24 integriert die zwei oder mehr Software-Module und die Laufzeitumgebung in eine Software-Komponente. Die Software-Komponente kann dabei so ausgestaltet sein, dass eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente direkt durch die zwei oder mehr Software-Module erfolgt. Alternativ kann die Software-Komponente so ausgestaltet sein, dass eine Kommunikation der zwei oder mehr Software-Module nach außerhalb der Software-Komponente indirekt über die Laufzeitumgebung erfolgt. Die resultierende Software-Komponente kann über einen Ausgang 26 der Vorrichtung für die weitere Verwendung bereitgestellt werden. Bei der Software-Architektur kann es sich beispielsweise um eine AUTOSAR-Software-Architektur handeln. In diesem Fall weist die Laufzeitumgebung der Software-Komponente standardisierte AUTOSAR-Schnittstellen auf. Vorzugsweise weisen dann auch die zwei oder mehr Software-Module standardisierte AUTOSAR-Schnittstellen auf.
  • Die Auswahleinheit 22, der Generator 23 und die Integrationseinheit 24 können von einer Kontrolleinheit 25 gesteuert werden. Über eine Benutzerschnittstelle 28 können gegebenenfalls Einstellungen der Auswahleinheit 22, des Generators 23, der Integrationseinheit 24 oder der Kontrolleinheit 25 geändert werden. Die in der Vorrichtung 20 anfallenden Daten können bei Bedarf in einem Speicher 27 der Vorrichtung 20 abgelegt werden, beispielsweise für eine spätere Auswertung oder für eine Nutzung durch die Komponenten der Vorrichtung 20. Die Auswahleinheit 22, der Generator 23, die Integrationseinheit 24 sowie die Kontrolleinheit 25 können als dedizierte Hardware realisiert sein, beispielsweise als integrierte Schaltungen. Natürlich können sie aber auch teilweise oder vollständig kombiniert oder als Software implementiert werden, die auf einem geeigneten Prozessor läuft, beispielsweise auf einer GPU. Der Eingang 21 und der Ausgang 26 können als getrennte Schnittstellen oder als eine kombinierte bidirektionale Schnittstelle implementiert sein.
  • 3 zeigt eine vereinfachte schematische Darstellung einer zweiten Ausführungsform einer Vorrichtung 30 zum Bereitstellen einer Software-Komponente für eine Software-Architektur. Die Vorrichtung 30 weist einen Prozessor 32 und einen Speicher 31 auf. Beispielsweise handelt es sich bei der Vorrichtung 30 um einen Computer oder ein Steuergerät. Im Speicher 31 sind Instruktionen abgelegt, die die Vorrichtung 30 bei Ausführung durch den Prozessor 32 veranlassen, die Schritte gemäß einem der beschriebenen Verfahren auszuführen. Die im Speicher 31 abgelegten Instruktionen verkörpern somit ein durch den Prozessor 32 ausführbares Programm, welches das erfindungsgemäße Verfahren realisiert. Die Vorrichtung hat einen Eingang 33 zum Empfangen von Informationen. Vom Prozessor 32 generierte Daten werden über einen Ausgang 34 bereitgestellt. Darüber hinaus können sie im Speicher 31 abgelegt werden. Der Eingang 33 und der Ausgang 34 können zu einer bidirektionalen Schnittstelle zusammengefasst sein.
  • Der Prozessor 32 kann eine oder mehrere Prozessoreinheiten umfassen, beispielsweise Mikroprozessoren, digitale Signalprozessoren oder Kombinationen daraus.
  • Die Speicher 27, 31 der beschriebenen Ausführungsformen können volatile und/oder nichtvolatile Speicherbereiche aufweisen und unterschiedlichste Speichergeräte und Speichermedien umfassen, beispielsweise Festplatten, optische Speichermedien oder Halbleiterspeicher.
  • Nachfolgend sollen bevorzugte Ausführungsformen der Erfindung anhand von 4 bis 7 am Beispiel einer AUTOSAR-Software-Architektur erläutert werden. Selbstverständlich beschränkt sich die erfindungsgemäße Lösung nicht auf diese Software-Architektur.
  • 4 veranschaulicht den Aufbau einer AUTOSAR-Software-Architektur. Auf der höchsten Abstraktionsebene unterscheidet die AUTOSAR-Architektur zwischen drei Softwareschichten, d.h. einer Basissoftware („BSW“), einer Laufzeitumgebung und einer Anwendungsschicht, die auf einem Mikrocontroller, auf Prozessoren oder allgemein auf Recheneinheiten laufen. Die Basissoftware umfasst AUTOSAR BSW Services. Dabei handelt es sich um standardisierte Software-Module, die Dienste anbieten, die für den Betrieb des funktionalen Teils der oberen Software-Ebene erforderlich sind. Bei der Laufzeitumgebung AUTOSAR RTE handelt es sich um eine Middleware, die von der Netzwerktopologie für den Informationsaustausch zwischen den Anwendungen innerhalb eines Steuergeräts oder zwischen verschiedenen Steuergeräten sowie für den Informationsaustausch zwischen den Anwendungen und der Basissoftware abstrahiert. Die Anwendungsschicht umfasst schließlich Anwendungen bzw. Software-Komponenten AUTOSAR SW-C, die mit der Laufzeitumgebung interagieren.
  • Der aktuelle AUTOSAR Classic Standard erlaubt die Integration von AUTOSAR-Software-Komponenten SW-C in die Gesamtsoftware als Blackboxes. Die Software-Komponenten SW-C werden meist von einem durch den Fahrzeughersteller beauftragten Gewerk als Blackbox an den Hardwarelieferanten ausgeliefert. Der Hardwarelieferant integriert die Gesamtsoftware und liefert diese aus. Die Schnittstellen sind standardisiert. Somit ist auch eine Portabilität zwischen verschiedenen Steuergeräten und Lieferanten gewährleistet. Die in 4 dargestellten Software-Komponenten AUTOSAR SW-C werden somit, direkt oder indirekt, vom Fahrzeughersteller bereitgestellt, während der im gestrichelten Rechteck befindliche Teil in der Verantwortung des Hardwarelieferanten liegt.
  • 5 illustriert einen ersten Ansatz für eine Integration von zwei Software-Modulen Mi in eine Software-Komponente SW-C. Für die Integration wird eine Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C selbst generiert. Diese ermöglicht es, die Software-Module Mi in der Software-Komponente SW-C miteinander zu verbinden, ohne dass der Hardwarelieferant davon Kenntnis hat. Für die Kommunikation nach außen nutzt die Software-Komponente SW-C eine standardisierte AUTOSAR-Schnittstelle.
  • Die Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C wird ebenfalls mit standardisierten AUTOSAR-Schnittstellen generiert, sodass auch für die Software-Module Mi selbst nicht erkennbar ist, dass noch weitere Software-Module Mi in derselben Software-Komponente SW-C enthalten sind. Alle Schnittstellen der Software-Module Mi sind ebenfalls standardisierte AUTOSAR-Schnittstellen.
  • Bei diesem Ansatz wird die Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C nur für die Kommunikation zwischen den Software-Modulen Mi verwendet. Die Kommunikation nach außen wird durch die Software-Module Mi direkt vorgenommen.
  • 6 illustriert einen zweiten Ansatz für eine Integration von zwei Software-Modulen Mi in eine Software-Komponente SW-C. Für die Integration wird wie schon beim ersten Ansatz eine Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C selbst generiert, die es ermöglicht, die Software-Module Mi in der Software-Komponente SW-C miteinander zu verbinden. Für die Kommunikation nach außen nutzt die Software-Komponente SW-C wiederum eine standardisierte AUTOSAR-Schnittstelle.
  • Die Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C wird ebenfalls mit standardisierten AUTOSAR-Schnittstellen generiert. Alle Schnittstellen der Software-Module Mi sind ebenfalls standardisierte AUTOSAR-Schnittstellen.
  • Bei diesem Ansatz wird die Laufzeitumgebung µPTE innerhalb der Software-Komponente SW-C sowohl für die Kommunikation zwischen den Software-Modulen Mi als auch für die externe Kommunikation der Software-Module Mi verwendet. Die Kommunikation der Software-Module Mi nach außen erfolgt somit über die Laufzeitumgebung µPTE.
  • 7 stellt schematisch ein Kraftfahrzeug 40 dar, in dem ein erfindungsgemäßes Steuergerät 41 genutzt wird. Das Kraftfahrzeug 40 weist eine Sensorik 42 auf, mit der Informationen zur Umgebung des Kraftfahrzeugs 40 erfasst werden können. Beispielsweise kann die Sensorik 42 Ultraschallsensoren, einen Laserscanner, Radarsensoren, Lidarsensoren oder eine oder mehrere Kameras umfassen. Für einen autonomen oder teilautonomen Fahrbetrieb ist ein Steuerungssystem 43 verbaut. In 7 ist sowohl der Sensorik 42 als auch dem Steuerungssystem 43 jeweils ein Steuergerät 41 zugeordnet. Natürlich kann das Kraftfahrzeug 40 weitere Steuergeräte 41 aufweisen. Zumindest eines der Steuergeräte 41 verwendet eine oder mehrere erfindungsgemäße Software-Komponenten. Weitere Bestandteile des Kraftfahrzeugs 40 sind ein Navigationssystem 44 und eine Datenübertragungseinheit 45. Mittels der Datenübertragungseinheit 44 kann beispielsweise eine Verbindung zu einem Dienstanbieter aufgebaut werden. Zur Speicherung von Daten ist ein Speicher 46 vorhanden. Der Datenaustausch zwischen den verschiedenen Komponenten des Kraftfahrzeugs 40 erfolgt über ein Netzwerk 47.
  • Bezugszeichenliste
    • 10
    Auswählen von Software-Modulen
    11
    Generieren einer Laufzeitumgebung
    12
    Integrieren der Software-Module und der Laufzeitumgebung in eine Software-Komponente
    20
    Vorrichtung
    21
    Eingang
    22
    Auswahleinheit
    23
    Generator
    24
    Integrationseinheit
    25
    Kontrolleinheit
    26
    Ausgang
    27
    Speicher
    28
    Benutzerschnittstelle
    30
    Vorrichtung
    31
    Speicher
    32
    Prozessor
    33
    Eingang
    34
    Ausgang
    40
    Kraftfahrzeug
    41
    Steuergerät
    42
    Sensorik
    43
    Steuerungssystem
    44
    Navigationssystem
    45
    Datenübertragungseinheit
    46
    Speicher
    47
    Netzwerk
    BSW
    Basis-Software
    Mi
    Software-Modul
    µPTE
    (Mikro)Laufzeitumgebung [auf Englisch (micro)runtime environment]
    RTE
    Laufzeitumgebung [auf Englisch runtime environment]
    SW-C
    Software-Komponente [auf Englisch software component]
  • 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
    • CN 109117121 A [0004]
    • KR 20140066531 A1 [0005]

Claims (11)

  1. Software-Komponente (SW-C) für eine Software-Architektur, wobei die Software-Komponente (SW-C) zwei oder mehr Software-Module (Mi) sowie eine Laufzeitumgebung (µRTE) für eine Kommunikation zwischen den zwei oder mehr Software-Modulen (Mi) aufweist.
  2. Software-Komponente (SW-C) gemäß Anspruch 1, wobei eine Kommunikation der zwei oder mehr Software-Module (Mi) nach außerhalb der Software-Komponente (SW-C) direkt durch die zwei oder mehr Software-Module (Mi) erfolgt.
  3. Software-Komponente (SW-C) gemäß Anspruch 1, wobei eine Kommunikation der zwei oder mehr Software-Module (Mi) nach außerhalb der Software-Komponente (SW-C) indirekt über die Laufzeitumgebung (µRTE) erfolgt.
  4. Software-Komponente (SW-C) gemäß einem der vorherigen Ansprüche, wobei die Software-Architektur eine AUTOSAR-Software-Architektur ist.
  5. Software-Komponente (SW-C) gemäß Anspruch 4, wobei die Laufzeitumgebung (µRTE) der Software-Komponente (SW-C) standardisierte AUTOSAR-Schnittstellen aufweist.
  6. Software-Komponente (SW-C) gemäß Anspruch 4, wobei die zwei oder mehr Software-Module (Mi) standardisierte AUTOSAR-Schnittstellen aufweisen.
  7. Verfahren zum Bereitstellen einer Software-Komponente (SW-C) für eine Software-Architektur, mit den Schritten: - Auswählen (10) von zwei oder mehr Software-Modulen (Mi); - Generieren (11) einer Laufzeitumgebung (µRTE) für eine Kommunikation zwischen den zwei oder mehr Software-Modulen (Mi); und - Integrieren (12) der zwei oder mehr Software-Module (Mi) und der Laufzeitumgebung (µRTE) in eine Software-Komponente (SW-C).
  8. Computerprogramm mit Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der Schritte des Verfahrens gemäß Anspruch 7 veranlassen.
  9. Vorrichtung (20) zum Bereitstellen einer Software-Komponente (SW-C) für eine Software-Architektur, mit: - einer Auswahleinheit (22) zum Auswählen (10) von zwei oder mehr Software-Modulen (Mi); - ein Generator (23) zum Generieren (11) einer Laufzeitumgebung (µRTE) für eine Kommunikation zwischen den zwei oder mehr Software-Modulen (Mi); und - einer Integrationseinheit (24) zum Integrieren (12) der zwei oder mehr Software-Module (Mi) und der Laufzeitumgebung (µRTE) in eine Software-Komponente (SW-C).
  10. Steuergerät (41) für ein Kraftfahrzeug (40), wobei das Steuergerät (41) zumindest eine Software-Komponente (SW-C) gemäß einem der Ansprüche 1 bis 6 aufweist.
  11. Kraftfahrzeug (40) mit einem Steuergerät (41) gemäß Anspruch 10.
DE102019213738.5A 2019-09-10 2019-09-10 Software-Komponenten für eine Software-Architektur Pending DE102019213738A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102019213738.5A DE102019213738A1 (de) 2019-09-10 2019-09-10 Software-Komponenten für eine Software-Architektur
PCT/EP2020/074409 WO2021047970A1 (de) 2019-09-10 2020-09-02 Software-komponenten für eine software-architektur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019213738.5A DE102019213738A1 (de) 2019-09-10 2019-09-10 Software-Komponenten für eine Software-Architektur

Publications (1)

Publication Number Publication Date
DE102019213738A1 true DE102019213738A1 (de) 2021-03-11

Family

ID=72355971

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019213738.5A Pending DE102019213738A1 (de) 2019-09-10 2019-09-10 Software-Komponenten für eine Software-Architektur

Country Status (2)

Country Link
DE (1) DE102019213738A1 (de)
WO (1) WO2021047970A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022001113A1 (de) 2022-03-31 2023-10-05 Mercedes-Benz Group AG Fahrassistenzsystem, Fahrzeug mit einem Fahrassistenzsystem und Verfahren zur Herstellung eines Fahrzeugs

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140066531A (ko) 2012-11-23 2014-06-02 엘지전자 주식회사 AUTOSAR(AUTomotive Open System Architecture) 기반의 컴포넌트 구조
CN109117121B (zh) 2018-05-08 2022-05-27 宁波央腾汽车电子有限公司 一种autosar软件架构实现方法

Also Published As

Publication number Publication date
WO2021047970A1 (de) 2021-03-18

Similar Documents

Publication Publication Date Title
DE10026918A1 (de) Virtueller Netzwerkadapter
EP3667568A1 (de) Konfiguration eines steuerungssystems für ein zumindest teilautonomes kraftfahrzeug
DE10159931A1 (de) Verfahren zum Zugriff auf Informationen und/oder Dienste eines verteilten Automatisierungssystems
EP1268996A2 (de) Verfahren und vorrichtung zur modellierung eines mechatronischen systems in einem kraftfarhzeug
WO2021047970A1 (de) Software-komponenten für eine software-architektur
DE102020206155A1 (de) Vorrichtung zum Festlegen einer Steuerungsbefugnis für ein intelligentes Heim und Verfahren dafür
DE102019213061A1 (de) Klassifizierung von KI-Modulen
DE102012210482A1 (de) Verfahren und System zum Migrieren von Geschäftsprozessinstanzen
DE102019001100A1 (de) Verfahren zur Überwachung einer Funktionalität eines Fahrzeuginformationssystems eines Kraftfahrzeugs, sowie elektronische Recheneinrichtung, Computerprogramm und Datenträger
DE102014108126A1 (de) FDT Host als FDI UIP in generischem FDI Package
EP2561460B1 (de) Verfahren zum konfigurieren einer applikation für ein endgerät
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
EP4144003B1 (de) Verfahren zum erzeugen einer softwarekomponente für eine elektronische recheneinrichtung eines kraftfahrzeugs, computerprogrammprodukt, computerlesbares speichermedium sowie kraftfahrzeugexternes aktualisierungssystem
EP3805998A1 (de) Verarbeitung von sensordaten in einem kraftfahrzeug
EP1960854A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
DE102008022839A1 (de) Verfahren und Vorrichtung zur Korrektur von digital übertragenen Informationen
DE102019119354A1 (de) Firmware-aktualisierung von komponenten eines modularen knotens
DE112018002344T5 (de) Entwicklungsunterstützungsvorrichtung
EP1242852B1 (de) Vorrichtung und verfahren zur einbindung von automatisierungskomponenten
DE102016123332A1 (de) Virtuelle Inbetriebnahme und Simulation eines Gebäudeautomatisierungssystems
EP1380908A2 (de) System zur automatischen Konfiguration von Steuerungssoftware
DE10065286B4 (de) Verfahren zum Entwurf und/oder zum Betrieb kombinierbarer Komponenten (TYCS)
WO2022117305A1 (de) Verfahren zum hinterlegen von programmdaten in einer datenbank
WO2022117306A1 (de) Verfahren zum bereitstellen von programmdaten aus einer datenbank
DE102022000818A1 (de) Verfahren zur Zuweisung eines Fahrzeugs an einen Kunden, sowie Verwaltungssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0008360000

Ipc: G06F0009500000

R016 Response to examination communication