-
Die vorliegende Erfindung betrifft ein Verfahren zum Zuordnen einer Gruppe von Softwarekomponenten zu einer Steuergerätearchitektur sowie eine entsprechende Steuergerätearchitektur, eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Elektronische Steuergeräte werden im Automobilbereich und in anderen Bereichen der Technik, z.B. der Anlagensteuerung, für eine Vielzahl von Funktionen eingesetzt, die einer Steuerung oder Regelung beliebiger Art bedürfen. Üblicherweise sind beispielsweise in einem Fahrzeug mehrere Steuergeräte mit unterschiedlichen Aufgaben vorhanden, die miteinander vernetzt sind. Dabei können sowohl die Steuergerätearchitektur im Fahrzeug, d.h. Anzahl und Struktur der vernetzten Steuergeräte, als auch die Softwarefunktionen in den Steuergeräten auf unterschiedliche Weise umgesetzt werden. Beispielsweise kann in einem einfachen Fahrzeug eine dezentrale Steuergerätearchitektur, die auf Basisfunktionen limitiert ist, vorgesehen sein, oder in einem höherklassigen Fahrzeug eine Architektur mit zentralen Steuergeräten und vielen erweiterten Funktionalitäten. Dabei sind die Hardwareressourcen in Steuergeräten schon aus Kostengründen häufig knapp bemessen. Grundsätzlich ist daher wünschenswert, die gewünschten Funktionalitäten im Gesamtsystem möglichst effizient auf die vorhandenen Steuergeräte zu verteilen.
-
Häufig wird für die Software von Steuergeräten aller Art auf den AUTOSAR (AU-Tomotive Open System ARchitecture)-Standard zurückgegriffen. Dabei wird eine Schicht-Architektur verwendet, in der die Anwendungssoftware von der Hardware des Steuergeräts über die sogenannte Basissoftware und eine Laufzeitumgebung abstrahiert wird. Durch diesen generischen Ansatz kann Basissoftware auch auf ähnlichen Microcontroller-Familien weiterverwendet werden, so dass Steuergeräte mit ähnlicher Konfiguration dieselbe Basissoftware nutzen können. Für die Anwendungssoftware stellt sich dagegen häufig das Problem, dass diese zwar theoretisch durch die Abstraktion der Schichten auch auf anderen Steuergeräten eingesetzt werden könnte, praktisch jedoch viele Funktionen spezifische Hardwareschnittstellen eines Steuergeräts verwenden, die über die komplexen Treiber (Complex Device Drivers) angesprochen werden. Daher wird üblicherweise für jedes Steuergerät eigene Software entwickelt, so dass die Softwarefunktionen häufig auch nur mit der spezifischen Hardware lauffähig sind und nicht auf andere Steuergeräte verschoben werden können. Falls doch eine Verschiebung vorgesehen ist, muss oftmals die Anwendungssoftware ebenso wie die zugehörigen komplexen Treiber neu entwickelt oder stark modifiziert werden, um in einer neuen Umgebung funktionsfähig zu sein.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Zuordnen einer Gruppe von Softwarekomponenten zu einer Steuergerätearchitektur sowie eine entsprechende Steuergerätearchitektur, eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
Insbesondere wird ein Verfahren zum Verteilen einer Gruppe von Softwarekomponenten auf eine Steuergerätearchitektur mit mehreren miteinander verbundenen Steuergeräten vorgeschlagen, wobei eine ausführbare Softwarefunktionalität durch eine Abfolgekette für die Gruppe von Softwarekomponenten definiert ist. Dabei umfasst das Verfahren zunächst ein Erfassen einer Klassifizierung für jede Softwarekomponente aus der Gruppe von Softwarekomponenten, wobei die Klassifizierung mindestens ein oder mehrere hardwarenahe Klassen umfasst, welche Softwarekomponenten zugeordnet sind, deren Funktionen mit Hardwareschnittstellen mindestens eines spezifischen Steuergeräts verknüpft sind, und wobei die Klassifizierung mindestens ein oder mehrere hardwareferne Klassen umfasst, welche Softwarekomponenten zugeordnet sind, deren Funktionen nicht mit Hardwareelementen eines spezifischen Steuergeräts verknüpft sind. Außerdem werden Eigenschaften der Steuergerätearchitektur erfasst, wobei die erfassten Eigenschaften mindestens eine Anzahl der Steuergeräte und für jedes Steuergerät die verfügbaren Ressourcen umfassen. Die Anzahl der Softwarekomponenten in der Gruppe, die Klassifizierungen für jede Softwarekomponente, die Abfolgekette für die Softwarekomponenten und die Eigenschaften der Steuerarchitektur werden dann als Eingabewerte eines Optimierungsalgorithmus eingegeben. Außerdem werden zusätzliche Randbedingungen für die Softwarekomponenten und/oder die Steuergerätearchitektur in den Optimierungsalgorithmus eingegeben.
-
Als Ausgabewert des Optimierungsalgorithmus wird dann mindestens eine eindeutige Zuordnung jeder Softwarekomponente aus der Gruppe von Softwarekomponenten zu den mehreren Steuergeräten ermittelt, wobei die Zuordnung auf einen vorgegebenen Parameter für die Ausführung der ausführbaren Softwarefunktionalität optimiert ist, und wobei die Zuordnung durch den Optimierungsalgorithmus in Abhängigkeit von der Klassifizierung jeder der Softwarekomponenten erfolgt.
-
Durch die verwendete Klassifizierung der einzelnen Softwarekomponenten können hardwarenahe Komponenten besser von den hardwarefernen Komponenten getrennt werden. Dadurch können auch die impliziten Abhängigkeiten der Softwarekomponenten innerhalb der ausführbaren Softwarekette besser aufgeschlüsselt werden, wodurch eine einfachere und bessere Verteilung auf mehrere Steuergeräte möglich wird.
-
Auch der Anpassungsaufwand bei der Verschiebung von Software von einem Steuergerät auf ein anderes wird dadurch stark reduziert.
Die Berücksichtigung der Randbedingungen in dem Optimierungsverfahren sorgt dafür, dass bei den Ergebnissen, d.h. der optimierten Zuordnung von Softwarekomponenten, nur Funktionalitäten entstehen, die tatsächlich realisierbar sind.
-
Der vorgegebene Parameter, auf den die Zuordnung optimiert ist, kann insbesondere eine Latenz für die Ausführung der ausführbaren Softwarefunktionalität und/oder eine gleichmäßige Ausnutzung der Ressourcen der Steuergeräte umfassen.
-
Als zusätzliche Randbedingungen für jede der Softwarekomponenten bei der Optimierung können beispielsweise eine oder mehrere der folgenden genutzt werden: die Prozessorlast einer Softwarekomponente, der Speicherverbrauch einer Softwarekomponente, eine erforderliche Kommunikationsbandbreite zwischen zwei Softwarekomponenten, eine erforderliche Nachrichtenhäufigkeit für die Kommunikation zwischen zwei Softwarekomponenten, eine Abhängigkeit zwischen zwei oder mehreren der Softwarekomponenten, eine Latenzzeit für eine Softwarekomponente, ein verwendetes Kommunikationsprotokoll, eine durch eine Softwarekomponente verwendete Hardware- oder Softwareschnittstelle.
-
Ebenso können die Eigenschaften der Steuergerätearchitektur und/oder die zusätzlichen Randbedingungen für die Steuergerätearchitektur, die in der Optimierung verwendet werden, mindestens eines der folgenden umfassen: eine durch ein Steuergerät zur Verfügung gestellte Rechenleistung, eine verfügbare Speichergröße, ein verwendetes Kommunikationsprotokoll, einen verwendeten Nachrichtentyp, eine verfügbare Kommunikationsbandbreite zwischen jeweils zwei Steuergeräten, eine Angabe zu in einem Steuergerät verbauten Endstufen, eine Angabe zu zusätzlichen spezifischen Hardwareschnittstellen in einem Steuergerät, die verfügbaren Ein- und Ausgänge eines Steuergeräts, eine Sicherheitseinstufung.
-
Das vorgestellte Verfahren kann beispielsweise in einer Steuergerätearchitektur verwendet werden, die gemäß dem AUTOSAR-Standard implementiert ist. Insbesondere können dann die hardwarenahen Klassen den ‚Complex Device Drivers‘ der AUTOSAR-Schichtstruktur zugeordnet sein, und die hardwarefernen Klassen können der Anwendungssoftware der AUTOSAR-Schichtstruktur zugeordnet sind. Durch die zusätzliche Klassifizierung und definierte Schnittstellen zwischen den einzelnen Klassen wird damit ermöglicht, die Softwarekomponenten der Anwendungssoftware getrennt von den Softwarekomponenten der ‚Complex Device Drivers‘ auf verschiedenen Steuergeräten auszuführen, die sonst in AUTOSAR als monolithischer steuergerätespezifischer Block existieren.
-
Für diese Verfeinerung der Klassifizierung können die ein oder mehreren hardwarenahen Klassen in möglichen Ausführungsformen ausgewählt sein aus: einer ersten Klasse für Softwarekomponenten, die eine Ansteuerung von Hardware-Eingängen und -Ausgängen ausführen; und einer zweiten Klasse für Softwarekomponenten, die eine Abstraktion der Hardwareansteuerung ausführen.
-
Außerdem können bei der Klassifizierung die ein oder mehreren hardwarefernen Klassen ausgewählt sein aus: einer dritten Klasse für Softwarekomponenten, die mindestens eines aus Steuerung, Regelung oder Signalverarbeitung ausführen; einer vierten Klasse für Softwarekomponenten, die übergeordnete Zustandssteuerungen ausführen; und einer fünften Klasse für Softwarekomponenten, die Vorhersagewerte bilden und/oder Modellierungen von Parametern vornehmen. Diese Unterteilung der hardwarefernen und hardwarenahen Softwareanteile ermöglicht eine bessere Separierung der Funktionalitäten (Separation of Concerns) und damit eine gezieltere Zuordnung zu anderen Steuergeräten im System, abhängig von ihrer Klassifizierung und von weiteren Randbedingungen.
-
Als Optimierungsalgorithmus kann insbesondere ein evolutionärer Algorithmus verwendet werden; ebenso sind aber auch andere bekannte Optimierungsalgorithmen einsetzbar.
-
Eine erfindungsgemäße Steuergerätearchitektur ist gemäß einem oben beschriebenen Verfahren eingerichtet. Eine erfindungsgemäße Recheneinheit, z.B. ein Steuergerät eines Kraftfahrzeugs, ein für die Softwareentwicklung geeigneter Rechner oder eine Gruppe von verbundenen Recheneinheiten, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht. Schließlich ist ein maschinenlesbares Speichermedium vorgesehen mit einem darauf gespeicherten Computerprogramm wie oben beschrieben. Geeignete Speichermedien bzw. Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich. Ein solcher Download kann dabei drahtgebunden bzw. kabelgebunden oder drahtlos (z.B. über ein WLAN-Netz, eine 3G-, 4G-, 5G- oder 6G-Verbindung, etc.) erfolgen.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Kurze Beschreibung der Zeichnungen
-
- 1 zeigt schematisch die Software-Architektur gemäß dem AUTOSAR-Standard im Stand der Technik,
- 2 zeigt an einem Beispiel die Zuordnung von Softwarekomponenten auf mehrere Steuergeräte, und
- 3 zeigt mögliche Verfahrensschritte gemäß beispielhaften Ausführungsformen.
-
Ausführungsform(en) der Erfindung
-
1 zeigt schematisch die übliche Schichtarchitektur für Software gemäß dem AUTOSAR-Standard im Stand der Technik, wie sie unter anderem für elektronische Steuergeräte (Electronic Control Units, ECU) im Automobilbereich eingesetzt werden kann. Dabei ist eine geschichtete Abstraktion der Software vorgesehen, wobei eine Basissoftware (BSVη mit verschiedenen Abstraktionsmodulen 120, 130, 140, 150 verwendet wird, die Funktionalitäten zwischen einer Anwendungsschicht 170 und der Verarbeitungseinheit bzw. dem Microcontroller 110 des Steuergeräts vermitteln. Zwischen den Modulen der Basissoftware und der Anwendungsschicht 170 befindet sich die Laufzeitumgebung 160 (Runtime Environment, RTE), die den Datenaustausch zwischen diesen beiden Schichten umsetzt.
-
Die Basissoftware hat einen generischen Ansatz, um flexibel auf ähnlichen Microcontroller-Familien verwendet werden zu können. Daher sind im AUTOSAR-Standard verschiedene Module der Basissoftware im Detail definiert. Eine Microcontroller-Abstraktions-Schicht 130 (MCAL, Microcontroller Abstraction Layer) umfasst interne Treiber für den Zugriff auf Speicher, Kommunikation und Input/Output (I/O) des Microcontrollers. Eine darunterliegende Steuergeräte-Abstraktionsschicht 120 (ECU Abstraction Layer, ECUAL) umfasst Schnittstellen für alle Funktionen des Steuergeräts wie Kommunikation, Speicherzugriffe und Input/Output bzw. Pinbelegungen, unabhängig davon, ob diese durch externe Peripheriegeräte oder durch den Microcontroller bereitgestellt werden. Die Dienste-Schicht 140 (Services Layer) als oberste Schicht der Basissoftware umfasst Hintergrunddienste wie Kommunikationsdienste, Systemdienste, Speichermanagement und Diagnostik.
-
Üblicherweise verwendet Anwendungssoftware eine Vielzahl von Funktionalitäten, die spezifische Hardware-Schnittstellen eines bestimmten Steuergeräts benötigen. Diese Hardware-Schnittstellen können unter anderem über die komplexen Treiber (Complex Device Drivers) 150 implementiert werden, die sich parallel zur übrigen Basissoftware von der Hardware bis zur Laufzeitumgebung (RTE) erstrecken und ebenfalls über standardisierte AUTOSAR-Schnittstellen in die übrige Architektur eingebunden sind. Über die ‚Complex Device Drivers‘ können auch Funktionen außerhalb der restlichen Basissoftware modelliert werden, z.B. Schnittstellen, die nicht direkt durch den AUTOSAR-Standard unterstützt werden. Außerdem können die komplexen Treiber verwendet werden, um z.B. zeitkritische Funktionen umzusetzen, da auf diese Weise ein direkterer und damit schnellerer Zugriff auf die Hardware möglich ist, wie etwa auf Sensoren und Aktoren.
-
Weitere Details des AUTOSAR-Standards sind im Fach bekannt und können unter www.autosar.org abgerufen werden. Die nachfolgend beschriebenen Schritte und Verfahren können insbesondere zusammen mit dem AUTOSAR-Standard angewendet werden, sind jedoch nicht auf diesen beschränkt und können grundsätzlich auch in anderen Softwareplattformen eingesetzt werden, in denen eine Verteilung der Software auf mehrere Verarbeitungseinheiten erwünscht ist, wobei hardwarespezifische Schnittstellen und Abhängigkeiten berücksichtigt werden müssen.
-
Um in einem System mit mehreren Verarbeitungseinheiten, z.B. mehreren getrennten Steuergeräten, die jeweils unterschiedliche Hardwareressourcen bereitstellen und verschiedene Funktionen implementieren, Softwareanteile vorübergehend oder dauerhaft zwischen Steuergeräten zu verschieben, wird vorgeschlagen, eine Softwarefunktionalität in mehrere Softwarekomponenten aufzuteilen und in neu definierte Klassen zu klassifizieren. Dabei können die Klassen für die Klassifizierung so gewählt werden, dass dabei die jeweiligen Einzelfunktionen und Abhängigkeiten möglichst voneinander getrennt werden (Separation of Concerns, Trennung der Zuständigkeiten) mit dem Ziel, eine optimale Verteilung auf mehrere Steuergeräte zu ermöglichen. Dabei kann zunächst zwischen hardwarenahen Klassen und hardwarefernen Klassen unterschieden werden. Die Klassen können so gewählt werden, dass in einer AUTOSAR-Architektur die hardwarenahen Klassen der Funktionalität entsprechen, die in den komplexen Treibern bzw. ‚Complex Device Drivers‘ umgesetzt wird, während die hardwarefernen Klassen der Anwendungssoftware entsprechen.
-
Diese Klassifizierung kann auch noch weiter verfeinert werden, um die Verteilbarkeit zu verbessern. Bevorzugt wird dabei eine funktionsspezifische Klassifizierung gewählt.
-
Eine mögliche Einteilung der Klassen, in welche die Softwarekomponenten klassifiziert werden können, kann wie folgt aufgebaut sein:
- Hardwarenahe Klassen (Complex Device Drivers):
- a) Hardware-Signalverarbeitung als eine erste Klasse, z.B. Register-Ansteuerung für Sensoren und Aktoren oder andere Peripheriegeräte; diese Klasse kann insbesondere Softwareteile umfassen, die ausschließlich für ein bestimmtes Steuergerät entwickelt wurden, z.B. die Hardware-Treiber für einen spezifischen Temperaturfühler.
- b) Abstraktion der Hardwaresignale als eine zweite Klasse, d.h. Kapselung (Encapsulation) für die angeschlossenen Sensoren/Aktoren; hier können beispielsweise Softwareteile eingeordnet sein, die auch auf anderer, aber ähnlicher Hardware lauffähig sind, aber dennoch eine Anpassung z.B. bei Änderung eines Messprinzips erforderlich machen, wie etwa eine veränderte Kalibration der angeschlossenen Hardware.
- Hardwareferne Klassen (Anwendungssoftware):
- c) Regelung, Steuerung, allgemeine Signalverarbeitung als eine dritte Klasse; wie etwa Teile, die regelungstechnische Aufgaben übernehmen, z.B. eine PID-Drehzahlregelung oder eine Vorsteuerung zur Temperatursteuerung eines Heizelement, ein Filter einer Trafoprimärspannung, ein Rauschfilter einer Innenraum Fahrzeugkamera, oder eine Steuerung einer Fensterhebemotors.
- d) Übergeordnete Zustandssteuerung als eine vierte Klasse; hierunter fallen beispielsweise Softwareelemente, die zustandsbasierte Modelle oder eine Kommandierung von Subsystemen beinhaltet, z.B. eine Zustandsmaschine für die Fahrmodi eines Inverters; Software für Bremse und Inverter zur Koordinierung zwischen einer Rekuperationsfunktion und einer Reibbremse; eine Zustandssteuerung einer Drosselklappe; eine Fehlerdiagnose z:B. für Temperaturen, Spannungen, Signalverluste, und
- e) Vorhersagen- und Modellberechnungen als eine fünfte Klasse, wie etwa Softwaremodelle zur Schätzung nicht gemessener Größen oder zur Vorhersage zukünftiger Systemzustände beinhaltet, z.B. ein Temperaturmodell des Kühlmittelflusses durch mehrere Batteriezellen, welches die Temperatur jeder Zelle modelliert, während nur ein Teil der Zellen gemessen wird. Andere Beispiele sind Software zur Schätzung der Raddrehzahl auf Basis der Drehzahl einer elektrischen Maschine, des angelegten Moments und des resultierenden Moments, Software zur Vorhersage des maximalen Moments in den folgenden Sekunden auf Basis des aktuellen Zustands des Antriebsstrangs, oder Beobachter-Software zur Berechnung des Fahrzeugschwimmwinkels
-
Eine Softwarefunktionalität kann dann in mehreren Einzelkomponenten entsprechend dieser Klassen gezielt entwickelt und optimiert werden. Dabei sollen alle Schnittstellen zwischen diesen Klassen explizit bekannt und definiert sein, so dass ein Datenaustausch auch über mehrere Steuergeräte hinweg möglich wird. Damit können die hardwarenahen Teile getrennt von den hardwarefernen Teilen auf verschiedenen Steuergeräten eingesetzt werden. Zu diesem Zweck kann außerdem die Echtzeitfähigkeit analysiert werden. Da Signale bei einer verteilten Zuordnung der Softwarekomponenten über die Grenzen der Steuergeräte hinweg, statt nur intern innerhalb eines Steuergerätes kommunizieren, werden sich in der Regel die Latenzen bzw. Signalverzögerungen der Schnittstellen erhöhen.
-
Die so entwickelten Softwarekomponenten können damit jeweils einer Klasse zugeteilt werden, insbesondere einer der oben genannten Klassen a) bis e). Auf dieser Grundlage kann dann eine optimale Verteilung der Softwarekomponenten auf mehrere Steuergeräte ermittelt werden. Für diese Optimierungsaufgabe können verschiedene Parameter bzw. Randbedingungen berücksichtigt werden, die für eine fehlerfreie und effiziente Ausführung als verteilte Funktionalität relevant sind.
-
Die optimale Verteilung der Softwarekomponenten, die zusammen eine Funktionalität bilden, kann mit einem beliebigen geeigneten Optimierungsalgorithmus vorgenommen werden, zum Beispiel mittels eines Evolutionären Algorithmus. Als Eingangsgrößen für eine solche Optimierung können insbesondere die Softwarekomponenten zusammen mit einer Angabe der Klasse, in die sie klassifiziert sind, sowie eine Steuergerätearchitektur verwendet werden. Die Steuergerätearchitektur kann dabei unter anderem durch die Anzahl der vorhandenen Steuergeräte und die vorhandenen freien Ressourcen für jedes der Steuergeräte wie Rechenleistung, Kommunikationsbandbreite oder Speicher definiert werden. Für die Kommunikationsbandbreite können dabei für jede einzelne Verbindung, z.B. zwischen einem ersten und einem zweiten sowie einem ersten und einem dritten Steuergerät, unterschiedliche Parameter und Bandbreiten angegeben werden.
-
Auch die von den Steuergeräten unterstützten Protokolle und Nachrichtentypen können als Parameter definiert sein.
-
Als zusätzliche Randbedingungen für einen Optimierungsalgorithmus können beispielsweise der Speicherverbrauch einer Softwarekomponente, die Prozessorlast einer Komponente, die bereits durch andere Funktionalitäten bedingte Auslastung von Ressourcen der Steuergeräte, der Kommunikationsbedarf zwischen Steuergeräten (z.B. Datenmenge, Bandbreite, Nachrichtenhäufigkeit), eine Sicherheitseinstufung, eine Anzahl von digitalen und/oder analogen Hardware-Ein- und Ausgängen, die Anzahl und Auslegung vorhandener Leistungsendstufen eines Steuergeräts, benötigte Kommunikationsprotokolle und Nachrichten (z.B. CAN-Frame-Anforderungen) definiert werden. Dabei können diese und weitere Randbedingungen beliebig gewählt werden, insbesondere können alle oder nur ein Teil der Randbedingungen zur Optimierung genutzt werden, oder es können zusätzlich oder alternativ andere Randbedingungen gewählt werden, die für die Auslastung der Steuergeräte und die Funktionsfähigkeit der Softwareanwendungen relevant sind.
-
Als Optimierungsparameter, d.h. als Ziel der Optimierung, können insbesondere die Reaktionszeiten bzw. Latenzen für eine aus mehreren Softwarekomponenten gebildete Funktionalität und/oder eine gleichmäßige Ausnutzung der vorhandenen Hardware-Ressourcen betrachtet werden. Dabei kann eine vollständige ausführbare Software-Funktionalität eine definierte Abfolge oder Kette von mehreren Softwarekomponenten umfassen, wobei auch Komponenten mehrfach innerhalb der Kette genutzt werden können, z.B. bestimmte Berechnungs- oder Regelungsschritte. Ebenso muss die Software-Funktionalität keine lineare Kette von Softwarekomponenten umfassen, sondern kann dabei parallele Abfolgen, mehrfache Abhängigkeiten und anderes auf die übliche Weise umfassen. Als Reaktionszeit bzw. Latenz einer Software-Funktionalität kann dann die Reaktionszeit von Beginn der Ausführung bis zum Endergebnis (z.B. Ansteuerung eines Aktors) betrachtet werden.
-
Als Beispiel soll im Folgenden im Zusammenhang mit 2 eine Funktionalität beschrieben werden, die eine Kühlmittelpumpe regelt und dazu den Kühlbedarf an verschiedenen Teilen eines Antriebs mit einem Elektromotor berücksichtigt. Diese Funktion bzw. Anwendung kann in verschiedene Softwarekomponenten aufgeteilt werden, um die zuvor beschriebene Klassifizierung zu ermöglichen. Die endgültige Softwarefunktionalität umfasst dann eine bestimmte Abfolge von Verarbeitungsschritten über diese verschiedenen Komponenten hinweg. Dabei sollen in diesem Beispiel drei miteinander vernetzte Steuergeräte zur Verfügung stehen, die unterschiedliche Eigenschaften aufweisen und z.B. gemäß dem AUTOSAR-Standard implementiert sein können. Wie bereits beschrieben werden nun Funktionen, die ansonsten der Anwendungsschicht (ASVη und den komplexen Treibern (CCD) zugeordnet werden, weiter in Klassen eingeteilt, um eine optimierte Zuweisung der Softwarekomponenten an die Steuergeräte zu ermöglichen.
-
Zunächst können drei Softwarekomponenten a1, a2, a3 vorgesehen sein, die Signale von der Hardware einlesen (z.B. von Temperatursensoren, Drehzahlmessern oder anderen Eingangssignalen) und den Kühlbedarf des Elektromotors und eines vorgegebenen Getriebes bestimmen. Da hier direkte Signale, z.B. Sensorsignale verarbeitet werden müssen, können diese Komponenten der ersten Klasse a) von Softwarekomponenten zugeordnet werden, welche die unmittelbare Signalverarbeitung von und zu Sensoren bzw. Aktuatoren umfasst. Zwei weitere Softwarekomponenten b1, b2 können dafür vorgesehen sein, den durch die ersten Softwarekomponenten a1, a2 und a3 bestimmten Kühlbedarf von den konkreten Bauteilen (Motor, Getriebe etc.) zu abstrahieren, so dass ein abstrahierter Kühlbedarf eines Elektromotors und eines Getriebes von den Softwarekomponenten b1, b2 bestimmt und weiterverwendet werden kann. Diese Komponenten können entsprechend der zweiten Klasse b) (Encapsulation) zugeordnet werden. Diese beiden Klassen entsprechen Funktionen, die im ‚Complex Device Driver‘ der AUTOSAR-Architektur verarbeitet werden.
-
Weiter können zwei Softwarekomponenten c1, c2 als Regler vorgesehen sein, um eine Kühlmittelpumpe und ein Durchlassventil anzusteuern bzw. zu regeln, wobei die Ansteuerung auf den Kühlbedarfen beruht, die von den Komponenten b1, b2 bestimmt wurde. Diese beiden Softwarekomponenten c1, c2 sind entsprechend als Teile einer Regelung oder Steuerung der dritten Klasse c) zugeordnet.
-
Als Ausgangssignal der Regler c1, c2 werden also Signale erhalten, die sich wiederum auf den abstrahierten Kühlbedarf beziehen und als Eingangssignale für zwei weitere Komponenten b3, b4 dienen. Diese Komponenten b3 und b4 vermitteln die Ausgangssignale von der abstrahierten Ebene zu der konkreten Ausführung aus tatsächlich vorhandenem Elektromotor und Getriebe, so dass diese Softwarekomponenten wie schon die Komponenten b1 und b2 der zweiten Klasse zugeordnet werden können. Die Ausgangssignale wiederum werden durch die Komponenten a4 und a5 in konkrete Ansteuerungssignale für Aktoren umgesetzt, nämlich als aktorische Ansteuerungssignale für die Kühlmittelpumpe und das Durchlassventil. Damit werden die Softwarekomponenten a4 und a5 wieder der ersten Klasse zugeordnet, die direkte Eingangs- und Ausgangssignale für die Hardware umfasst.
-
Darüber hinaus ist ein übergeordnetes konfigurierbares Temperaturmodell in einer Softwarekomponente e1 vorgesehen, welches abschätzen kann, bei welcher Temperatur (oder auch sonstigen Eingangswerten) welcher Kühlmittelfluss benötigt wird, um die gewünschte Kühlleistung zu erbringen. Als Modellierungskomponente wird diese Softwarekomponente damit der fünften Klasse zugeordnet. Dieses Modell fließt in die Regelungen der Komponenten c1 und c2 ein und könnte beispielsweise einen Sollwert für den Kühlmittelfluss angeben.
-
Außerdem dient eine Softwarekomponente d1 dazu, den Gesamtzustand des Systems zu beeinflussen, z.B. Teile des Systems ein- oder auszuschalten, wenn der Elektromotor nicht betrieben wird. Dieses zusätzliche Steuerelement erhält im vorliegenden Beispiel Eingangswerte von der Komponente b2, die abstrahierte Messwerte des Elektromotors weitergibt, und von den beiden Reglern c1 und c2. Die Ausgangswerte dieser Steuerung können beispielsweise der Softwarekomponente b3 zugeführt werden, welche über die Komponenten a4 und a5 die Kühlmittelpumpe ansteuert. Diese Komponente d1 wird damit als übergeordnete Steuerungskomponente der vierten Klasse d) zugeordnet.
-
Die vorhandenen Steuergeräte können gleiche, ähnliche und/oder unterschiedliche Eigenschaften aufweisen. In diesem Beispiel soll ein erstes Steuergerät vorhanden sein, welches Leistungsendstufen für die Ansteuerung der Kühlmittelpumpen verbaut hat. Außerdem sollen die hardwarenahen Softwarekomponenten, also die Komponenten der ersten und zweiten Klasse, für dieses erste Steuergerät entwickelt sein, da sie auf die speziellen Hardwareschnittstellen für die Ansteuerung und die erhaltenen Signale zugreifen müssen. Ein zweites Steuergerät ist in diesem Beispiel zunächst zur Regelung des Elektromotors vorgesehen, während ein drittes Steuergerät als zentrales Steuergerät vorhanden ist. Dabei kann das zweite Steuergerät, das den Elektromotor regelt, z.B. eine kurze Latenz aufweisen, aber nur über wenig Kommunikationsbandbreite für den Datenverkehr zum ersten Steuergerät verfügen. Dagegen kann das dritte, zentrale Steuergerät beispielsweise mit hoher Rechenleistung und hoher Kommunikationsbandbreite ausgestattet sein, aber durch die breite Zuständigkeit für viele weitere Funktionalitäten eine schlechtere Latenz aufweisen. Außerdem kann als Randbedingung für die Kühlmittelregelung vorgegeben sein, dass beispielsweise nach einer neuen Temperaturanforderung bis zur Aktivierung der Kühlmittelpumpe maximal 120 ms vergehen sollen.
-
Durch die beschriebenen Eingangs- und Ausgangswerte und Abhängigkeiten zwischen den einzelnen Komponenten ist also eine Kette von Komponenten für die aufzuteilende Funktionalität vorgegeben. Aufgrund der Zuordnung zu den verschiedenen Klassen können die einzelnen Softwarekomponenten dann auf die verfügbaren Steuergeräte verteilt werden. Dazu kann ein geeignetes Optimierungsverfahren wie ein evolutionärer Algorithmus verwendet werden, für welchen die Softwarekomponenten und ihre definierenden Parameter, ihre jeweilige Zuordnung zu den Klassen sowie die Steuergeräte und deren definierende Parameter als Eingangswerte definiert werden können. Als Randbedingungen können zusätzliche Regeln festgelegt werden, wie etwa die Kommunikationsbandbreite, die gewünschte Latenz oder die Kopplung einzelner Softwarekomponenten an eine spezifische Hardware bzw. an ein spezifisches Steuergerät, z.B. aufgrund vorhandener Endstufen am Steuergerät.
-
Falls hardwarespezifische Softwarekomponenten vorliegen, können diese auch zunächst dem Steuergerät zugeordnet werden, für das sie spezifisch entwickelt wurden. Im vorliegenden Beispiel können also die fünf Softwarekomponenten a1, a2, a3, a4 und a5, welche die Hardwaresignale auslesen und die Aktuatoren ansteuern und damit der ersten Klasse von Softwarekomponenten zugeordnet wurden, ebenso dem ersten Steuergerät S1 zugewiesen werden wie die vier Softwarekomponenten b1, b2, b3 und b4, welche die Abstrahierung zwischen der Anwendungssoftware und der Signalebene vornehmen und damit der zweiten Klasse von Softwarekomponenten zugeordnet wurden. Beide Klassen sind im vorliegenden Beispiel spezifisch für das erste Steuergerät und können daher nicht auf einem anderen Steuergerät eingesetzt werden, da dort z.B. die Leistungsendstufen für die Ansteuerung durch die Softwarekomponenten a4 und a5 und die entsprechenden Eingangssignale für die Softwarekomponenten a1 bis a3 fehlen.
-
Die noch verbleibenden Softwarekomponenten der dritten, vierten und fünften Klasse können dann wie schon beschrieben durch einen Optimierungsalgorithmus abhängig von den vorhandenen Ressourcen und weiteren Randbedingungen auf alle Steuergeräte verteilt werden. Es ist aber auch möglich, dass direkt die gesamte Verteilung über einen entsprechenden Optimierungsalgorithmus vorgenommen wird und die feste Zuordnung zu einem Steuergerät als Randbedingung genutzt wird.
-
In diesem Beispiel wird als Ergebnis der Optimierung eine Zuordnung der Softwarekomponenten wie in 2 gezeigt angenommen. Durch die hardwarespezifischen Merkmale der Softwarekomponenten der ersten und zweiten Klasse, a1 bis a5 und b1 bis b4, werden diese Komponenten dem ersten Steuergerät S1 zugeordnet. Die Regler und die Zustandsteuerung (Softwarekomponenten c1, c2, d1), d.h. die Softwarekomponenten der dritten und vierten Klasse, werden hier dem zweiten Steuergerät S2 zugeordnet, um die Vorteile eines zentralen Steuergeräts zu nutzen. Eine zeitliche Abhängigkeit zwischen den Steuergeräten kann hier ebenfalls berücksichtigt werden. Die Softwarekomponente e1 der fünften Klasse kann als unkritisches Teil der Softwarekette (keine oder nur geringe zeitkritischen Anforderungen) dem dritten Steuergerät S3 mit hoher Rechenleistung zugeordnet werden, um beispielsweise sehr rechenintensive Modelle zu berechnen.
-
Es ist auch denkbar, dass durch ein Optimierungsverfahren mehrere mögliche Zuordnungen von Softwarekomponenten zu Steuergeräten gefunden werden. Grundsätzlich ist eine Vielzahl von verschiedenen Zuordnungen der Softwarekomponenten zu Steuergeräten möglich. In diesem Fall können beispielsweise alle möglichen Zuordnungen als Ergebnis ausgegeben werden, so dass der Entwickler bzw. Hersteller die endgültige Verteilung festlegen kann. Ebenso ist es auch möglich, dass auf einen einzelnen Wert (z.B. gleichmäßige Ausnutzung der Steuergeräte oder Latenzzeit) optimiert wird, und das beste Ergebnis ausgegeben wird. Alternativ oder zusätzlich können für verschiedene Werte, auf die optimiert werden soll, auch Prioritäten angegeben sein. Falls eine dynamische Zuordnung von Softwarekomponenten bzw. eine Veränderung der Zuordnung möglich ist, z.B. bei Hinzufügen eines weiteren Steuergeräts ins System, kann auch dafür eine neue optimale Zuordnung gefunden werden bzw. die ursprüngliche Zuordnung so optimiert werden, dass eine Veränderung der Steuergerätearchitektur leichter möglich wird.
-
In 3 sind beispielhafte Verfahrensschritte zur Optimierung der Verteilung von Softwarekomponenten auf mehrere Steuergeräte in einem Flussdiagramm dargestellt.
-
Dabei werden zunächst in Schritt 300 die Softwarekomponenten für eine vorgegebene Softwarefunktionalität entwickelt und jeder Softwarekomponente genau eine der vorgegebenen Klassen zugeteilt.
-
In Schritt 310 können für diese Softwarekomponenten erforderliche Latenzen ermittelt werden, und in Schritt 320 können Randbedingungen für die Softwarekomponenten wie der voraussichtliche Speicherverbrauch, eine Prozessorlast, benötigte Kommunikationsprotokolle, erforderliche Bandbreite, Abhängigkeiten zwischen den Softwarekomponenten, benötigte Schnittstellen und Hardwarezugriffe und weitere ermittelt bzw. festgelegt werden. Solche Randbedingungen können zuvor beispielsweise durch Messungen, Testläufe, Schätzungen und Optimierungsalgorithmen gewonnen werden. Beispielsweise kann eine maximale Prozessorlast (z.B. 80% Auslastung eines Rechenkerns) oder eine maximale Bandbreitenauslastung (z.B. maximal 50% Auslastung eines CAN-Netzwerks) vorgegeben sein. Randbedingungen für den Speicherverbrauch können aus Messungen oder statischen Softwareanalysen der erstellten Software gebildet werden. Schnittstellen und Anwendungen können in der Anwendung selbst vorgegeben sein und z.B. als Modell vorliegen, das automatisch extrahiert wird und zur Bildung der Randbedingungen verwendet wird. Konkrete zu erwartende Prozessorlasten auf einem Zielsystem, auf welches die Software bisher nicht portiert wurde, können beispielsweise aus einer Messung in einem bekannten System und einer Extrapolation durch Vergleich der Hardware ermittelt werden. Grundsätzlich können Randbedingungen auch zunächst manuell geschätzt werden. Alle Daten für Randbedingungen können beispielsweise durch einen Optimierungsalgorithmus bewertet werden.
-
In Schritt 330 können Rahmenparameter der Steuergerätearchitektur festgelegt bzw. ermittelt werden, die unter anderem die Anzahl von vorhandenen Steuergeräten, die frei zur Verfügung stehende Rechenleistung, die Architektur bzw. Verknüpfung der Steuergeräte, die Art und Bandbreite der vorhandenen Kommunikationsverbindungen, die verwendeten oder unterstützten Protokolle und Nachrichten, die vorhandenen analogen und digitalen Ein- und Ausgänge, die vorhandenen Leistungsendstufen und weitere Parameter umfassen können.
-
Es versteht sich, dass die hier als Abfolge gezeigten Schritte zur Erfassung der Parameter der Softwarekomponenten auch in einer anderen Reihenfolge, unabhängig von einander zu verschiedenen Zeiten oder parallel durchgeführt werden können.
-
Die so definierten Softwarekomponenten bzw. ihre Parameter können in Schritt 340 als Eingangsgrößen und/oder Randbedingungen für einen Optimierungsalgorithmus eingegeben bzw. ausgelesen werden, z.B. aus einer gespeicherten Datei oder einer Benutzereingabe. Ebenso können in Schritt 350 die erfassten Merkmale der Steuergerätearchitektur in den Optimierungsalgorithmus eingegeben werden. In Schritt 360 können ein oder mehrere Parameter, auf die optimiert werden soll, definiert werden, z.B. eine vorgegebene Latenz für die Ausführungskette der Gesamtfunktionalität oder eine gleichmäßige Ausnutzung der Ressourcen.
-
Der Optimierungsalgorithmus wird dann in Schritt 370 ausgeführt und das Ergebnis in Schritt 380 auf ein Abbruchkriterium hin überprüft. Falls das Abbruchkriterium nicht erfüllt ist, wird der Optimierungsalgorithmus erneut durchlaufen. Das Abbruchkriterium kann beispielsweise die Ausgabe einer plausiblen Zuordnung der Softwarekomponenten auf die Steuergeräte umfassen, die alle Randbedingungen erfüllt. Als Ergebnis werden durch den Optimierungsalgorithmus in Schritt 390 ein oder mehrere mögliche optimierte Zuordnungskonfigurationen für die Softwarekomponenten auf die Steuergeräte ausgegeben, wobei jede Softwarekomponente genau einem Steuergerät zugeordnet sein soll. Optional können auch mehrere Zuordnungskonfigurationen einem Nutzer zur Auswahl angegeben werden oder mit Gütekriterien bewertet werden. Falls mit dieser Optimierung kein gültiges Ergebnis gefunden wird, d.h. zum Beispiel keine Zuordnung alle Randbedingungen erfüllen kann, kann das Verfahren ab Schritt 320 oder wahlweise einem späteren Schritt wiederholt werden. In diesem Fall können beispielsweise Randbedingungen verändert und angepasst werden, um zu einem gültigen Zuordnungsergebnis zu kommen.
-
Es versteht sich, dass die hier genannten Merkmale und Eigenschaften der Steuergeräte ebenso wie alle Zahlenwerte nur beispielhaft genannt sind und dass in anderen Fällen Steuergeräte mit anderen Eigenschaften, andere Ansteuerungszeiten, oder mehr oder weniger zur Verfügung stehende Steuergeräte vorliegen können. Auch die hier beschriebene Funktion zur Kühlmittelregelung dient nur zur Veranschaulichung des Prinzips der Aufteilung von Softwarekomponenten einer Anwendung in mehrere Klassen, um diese bei der Zuweisung an Steuergeräte zu berücksichtigen, und kann ebenso auf beliebige andere Steuerungs- und Regelungsfunktionen mit entsprechenden Aktoren, Sensoren, Reglern und Berechnungsschritten übertragen werden.
