DE102022211019A1

DE102022211019A1 - Verfahren zur Modellierung von Bypass-Funktionen und zum Testen von freigeschnittenen Steuergerätefunktionen in virtuellen Steuergeräten

Info

Publication number: DE102022211019A1
Application number: DE102022211019.6A
Authority: DE
Inventors: Bernd Illg; Thomas MUNZ; Johannes SCHERLE
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-10-18
Filing date: 2022-10-18
Publication date: 2024-04-18

Abstract

Steuergeräte sind im Stand der Technik für eine Vielzahl von Anwendungen bekannt. Ihr Scheduling wird in Rapid-Prototyping Ansätzen auf Hardwaresteuergeräte aufgespielt, um den Maschinencode an geänderte Umstände anzupassen. Das macht eine Anpassung des Schedulings umständlich, ressourcenintensiv und damit kostspielig. Es ist Aufgabe der Erfindung diese Probleme zu lösen und die Anpassung des Schedulings zu verbessern.Die vorliegende Erfindung betrifft ein Computer-implementiertes Verfahren (300) zum Erzeugen einer variablen Scheduling-Datenstruktur (30) für virtuelle Steuergeräte, umfassend die Schritte:- Bereitstellen einer statischen Ausgangs-Scheduling-Datenstruktur,- Bereitstellen eines vECU Builds (5),- Generieren der variablen Scheduling-Datenstruktur (30), wobei die variable Scheduling-Datenstruktur (30) automatisiert erstellt wird, ausgehend von der statischen Ausgangs-Scheduling-Datenstruktur, wobei statische und variable Scheduling-Datenstruktur (30) jeweils mindestens einen Prozess (32, 34) und mindestens ein internes Signal (60) aufweisen, die mit Meta-Informationen automatisiert in einer Datenstruktur generiert werden, die zu einer Laufzeit eines virtuellen Steuergeräts veränderbar sind, und wobei Informationen in Kombination mit der variablen Scheduling-Datenstruktur (30) genutzt werden, um interne Signale (60) vor und nach Aufruf des mindestens einen Prozesses oder mindestens eines Prozesses aus einer Vielzahl von Prozessen zu überschreiben. Darüber hinaus betrifft die vorliegende Erfindung ein Computer-implementiertes Verfahren (300) zum Verändern einer variablen Scheduling-Datenstruktur (30) für virtuelle Steuergeräte, ein Datenverarbeitungssystem, ein Computerprogramm, eine variable Scheduling-Datenstruktur und eine Nutzung mindestens eines der zuvor genannten.

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft im Allgemeinen das technische Gebiet der Systemsteuergeräte und im Speziellen computer-implementierte Verfahren zum Erzeugen variabler Scheduling-Datenstrukturen für virtuelle Steuergeräte, Computer-implementierte Verfahren zum Verändern variabler Scheduling-Datenstrukturen für virtuelle Steuergeräte, Datenverarbeitungssysteme, Computerprogramme, Scheduling-Datenstrukturen und Nutzungen derselben.
Hintergrund der Erfindung
Verschiedene Hersteller benutzen oft verschiedene Mikrocontroller zur Verwendung in ihren Endprodukten, um komplexe Systeme oder Teile davon zu steuern. Beispielhaft sei hier etwa auf Fahrzeuge verwiesen, die eine oft zentrale ECU (Englisch für „Electronic Control Unit“; in deutsch: elektronisches Steuergerät, elektronischer Mikrocontroller) besitzen, in der bestimmte Aufgaben geplant, verarbeitet und/oder durchgeführt werden, d.h. dass Steuerbefehle an mit der ECU verbundene, dieser untergeordnete Steuereinheiten ausgegeben werden, die die Steuereinheiten dazu veranlassen eine bestimmte Funktion auszuführen. Diese Steuereinheiten können Kontroll- und Stellelemente der unterschiedlichsten Art steuern, von Elementen der Raumklimatisierung, bis hin zur Lichtanlage des Fahrzeugs.
Für die Steuerung, insbesondere im Bereich der Automatisierung von Funktionen, also von Funktionen die einem Bediener des Systems, insbesondere einem Fahrer, entzogen sind, werden oft eine Reihe von Daten und Signalen in die ECU eingelesen, die von verschiedenen Sensoren übermittelt werden und in sogenannte Inports (Signaleingänge, Eingänge, Anschlüsse) der ECU eingelesen, also importiert werden.
Dabei stellt die ECU eine zentrale Recheneinheit dar, die als Mikrocontroller funktioniert. Derartige Mikrocontroller werden von Typen-spezifischem und damit für jeden Mikrocontroller unterschiedlichem Maschinencode gesteuert. Dabei kann der Maschinencode und der damit verbundene Programmablauf bei Mikrocontrollern desselben Typs auch dadurch abweichen, dass unterschiedliche Anforderungen erfüllt sein müssen, an die der Maschinencode und damit der Programmablauf angepasst sein muss. Diese Anforderungen sind dabei abhängig vom Hersteller, vom verwendeten Mikrocontroller selbst und von der entsprechenden zu erfüllenden Aufgabe des Mikrocontrollers.
Dabei erfordert es einen hohen Aufwand, die jeweiligen Mikrocontroller mit dem entsprechenden Maschinencode zu bespielen und zu testen. Dies wird bisher, in der Regel, über einen Rapid Prototyping Ansatz durchgeführt, bei dem die Mikrocontroller bereitgestellt werden, um diese anschließend mittels spezieller Softwaretools mit einer veränderten Software zu bespielen, wodurch deren Steuergerätesoftware (= „Maschinencode“) verändert wird, um diesen mit neuen Funktionen zu versehen. Es werden also durch eine Veränderung des Maschinencodes neue Funktionen in den Programmablauf eingebaut, um den Programmablauf zu ändern und an die zu erfüllenden Aufgaben anzupassen. Das Aufspielen dieses geänderten Maschinencodes auf die Hardware eines Mikrocontrollers bezeichnet man auch als „flashen“ („wird / wurde geflasht“). Dieser Ansatz ist aufwendig, insbesondere zeitaufwendig, damit teuer und letztendlich ineffizient und wird daher als nachteilig empfunden.
Es ist vor diesem Hintergrund die technische Aufgabe der vorliegenden Erfindung, die Vorgehensweise effizienter zu gestalten, dadurch Zeit zu sparen, um somit den Einsatz notwendiger Ressourcen zu reduzieren. Auch gilt es die Geschwindigkeit der Anpassung zu optimieren, um so die Wettbewerbsfähigkeit zu erhöhen. Somit sollen die Nachteile des Standes der Technik zumindest zum Teil überwunden werden.
Zusammenfassender Überblick
Ausführungsformen der vorliegenden Erfindung stellen ein computer-implementiertes Verfahren zum Erzeugen einer variablen Scheduling-Datenstruktur für virtuelle Steuergeräte gemäß Anspruch 1, ein Computer-implementiertes Verfahren zum Verändern einer variablen Scheduling-Datenstruktur für virtuelle Steuergeräte gemäß Anspruch 5, ein Datenverarbeitungssystem gemäß Anspruch 11, ein Computerprogramm gemäß Anspruch 12, eine Scheduling-Datenstruktur gemäß Anspruch 13 und Nutzungen all dieser gemäß Anspruch 14 bereit.
Die Aufgabe wird insbesondere gelöst durch ein computer-implementiertes Verfahren zum Erzeugen einer variablen Scheduling-Datenstruktur für virtuelle Steuergeräte, umfassend die Schritte eines Bereitstellen einer statischen Ausgangs-Scheduling-Datenstruktur, dem Bereitstellen einer vECU Build, und dem Generieren der variablen Scheduling-Datenstruktur, wobei die statische Ausgangs-Scheduling-Datenstruktur mindestens ein Element, vorzugsweise mindestens jeweils ein Element, aufweist von Tasks, Prozessen, Zeigern, Signalen und/oder Funktionen, wobei die vECU Build beim Generieren der variablen Scheduling-Datenstruktur mindestens eines dieser Elemente identifiziert und der variablen Scheduling-Datenstruktur als Meta-Information automatisiert zuordnet, wobei die Meta-Information ausgebildet ist derart, um zu einer Laufzeit eines virtuellen Steuergeräts verändert zu werden. Dadurch wird die Vorgehensweise effizienter gestaltet und somit Zeit und Ressourcen gespart.
Dadurch kann, insbesondere dem Benutzer, nach Kompilierung und Auslieferung des virtuellen Steuergerätes (auch als vECU zu bezeichnen) die Möglichkeit gegeben werden Funktionen im virtuellen Steuergerät mit selbst entwickelten Funktionen zu ersetzen („zu bypassen“). Zusätzlich oder alternativ kann, insbesondere dem Benutzer, nach Kompilierung und Auslieferung des virtuellen Steuergerätes die Möglichkeit gegeben werden Prozesse innerhalb des Steuergeräts zu deaktivieren, neue Prozesse in den Programmablauf einzubauen, die Sampletime eines Prozesses zu verändern und/oder die Ausführungsreihenfolge von Prozessen zu verändern. Auch oder alternativ kann, insbesondere dem Benutzer, die Möglichkeit gegeben werden interne Signale die zwischen verschiedenen Steuergerätefunktionen ausgetauscht werden zu überschreiben mit Werten, die außerhalb des virtuellen Steuergerätes berechnet werden. Zusätzlich oder alternativ kann, insbesondere dem Benutzer, die Möglichkeit gegeben werden interne Signale, die zwischen verschiedenen Steuergerätefunktionen ausgetauscht werden außerhalb des virtuellen Steuergerätes zu lesen und in anderen Funktionen zu nutzen. Dabei kann auch insbesondere nur ein Task, ein Prozess, ein Zeiger, ein Signal und/oder eine Funktion, sowie jede beliebige Kombination davon in der Ausgangs-Scheduling-Datenstruktur enthalten sein und/oder von der vECU Build identifiziert werden.
„Echte“ physische Steuergeräte und „echte“ physische Mikrocontroller werden wie oben beschrieben etwa als ECU ausgebildet und in Fahrzeugen, Flugzeugen, Landmaschinen und verfahrenstechnischen Großanlagen verbaut, um nur ein paar Beispiele aufzuführen. Diese Steuergeräte umfassen i.d.R. eine Recheneinheit (CPU), ein Speichermedium und Inports, sowie Outports, also Datenein- und -ausgänge.
Auf diesen echten Steuergeräten werden Signale verarbeitet und Steuersignale generiert und wieder ausgegeben, um etwaige Prozesse zu steuern. Bei diesen Prozessen ist zwischen den in den Steuergeräten ablaufenden Prozessen und den Prozessen, die bestimmte Funktionen in den oben erwähnten Geräten und Systemen ablaufen zu unterscheiden. Die Prozesse in den Steuergeräten fungieren dabei insbesondere als Grundlage für die Performance der jeweiligen Steuergeräte und damit auch als Grundlage für die entsprechende Steuerung der oben beschriebenen Systeme und Maschinen. Die Prozesse, die in der Steuereinheit bzw. den Steuergeräten ablaufen sind insbesondere mit einem Scheduling versehen, einem hardcodierten Ablaufplan. Dieser legt insbesondere fest wann und unter welchen Bedingungen ein Prozess initialisiert und ausgeführt wird. Dieses Scheduling ist hardcodiert, was bedeutet, dass der Maschinencode (Maschinensoftware) dieses Scheduling bei Auslieferung aufweist, im physischen Steuergerät. Damit muss insbesondere für eine Anpassung des Scheduling, etwa um Funktionen auszuschneiden („zu bypassen“), so dass sie im hardcodierten Scheduling nicht mehr aufgerufen werden, im Rahmen des zuvor beschriebenen Rapid - Prototyping Ansatzes, mittels spezieller Softwaretools, etwa Etas E-Hooks das HEX-File so modifiziert werden, dass Bypass-Funktionen nach der Kompilierung und Auslieferung der Steuergerätesoftware in den Programmablauf eingebaut werden können. Hierzu wird das physikalische (echte) Steuergerät mit einem modifizierten HEX-File geflasht, um die Bypassfunktionen einzupflegen.
Davon abzugrenzen sind die virtuellen Steuergeräte im Sinne dieser Erfindung. Es sollen also insbesondere keine „echten“ physischen Geräte bereitgestellt werden. Vielmehr wird erfindungsgemäß, insbesondere in der Sprache ANSI-C, ein virtuelles Steuergerät bereitgestellt. Dieses wird insbesondere in Form eines Maschinencodes bereitgestellt. Dabei wird gemäß dem oben ausgeführten Aspekt der Erfindung die Architektur des Scheduling, welches gemäß dem Stand der Technik in Form des hardcodierten Maschinencodes bereitgestellt wird, mittels einer vECU Build erzeugt und in einer Metadatenstruktur (gleichbedeutend mit Meta-Information) als Scheduling-Datenstruktur abgebildet. Diese Scheduling-Datenstruktur weist dabei insbesondere eine Reihe von Zeigern (Englisch „Pointer“) auf, die umsetzbar sind, weshalb die entstehende Scheduling-Datenstruktur eine variable Scheduling-Datenstruktur ist. Insbesondere kann diese Scheduling-Datenstruktur verändert werden, auch während die vECU in einer herstellerspezifischen Simulationsumgebung läuft.
Dabei kann das virtuelle Steuergerät auch als vECU bezeichnet werden, wobei insbesondere die vECU Build diese vECU, bzw. das virtuelle Steuergerät erzeugt. Bei dieser Erzeugung wird insbesondere die ursprüngliche Maschine auf das Vorliegen einer (statischen) Scheduling-Datenstruktur hin untersucht und somit das Scheduling der Steuergerätesoftware in ein neues Scheduling für das virtuelle Steuergerät übertragen, bzw. dieses erstellt. Dieses neue Scheduling beruht insbesondere auf Meta-Informationen, die während der Laufzeit der vECU veränderbar sind.
Darüber hinaus können Fragmente genutzt werden, die bei der Erstellung der originalen Steuergerätesoftware entstehen, genutzt werden. Diese Fragmente enthalten insbesondere Informationen darüber, welche Prozesse auf welche internen Signale lesend oder schreibend zugreifen. Diese Informationen werden in Kombination mit der veränderbaren Scheduling-Datenstruktur genutzt, um interne Signale (direkt / unmittelbar / ohne Zeitverzögerung) vor oder (direkt/ unmittelbar/ ohne Zeitverzögerung) nach Aufruf eines Prozesses zu überschreiben. Dadurch können interne Signale des virtuellen Steuergeräts modifiziert werden ohne dass ein reales Steuergreät benutzt werden muss oder das virtuelle Steuergerät neu gebaut werden muss.
Die herstellerspezifische Simulationsumgebung läuft dabei insbesondere auf einem x86-PC, weshalb der Maschinencode für diese Umgebung bevorzugt ausgebildet und übersetzt wird.
Dabei extrahiert die vECU Build die Scheduling-Datenstruktur der hardcodierten Scheduling-Datenstruktur zunächst. Die vECU Build ist somit eine Programmeinheit, die insbesondere automatisiert die entsprechenden hier beschriebenen Schritte durchführt. Die ursprüngliche Scheduling-Datenstruktur des hardcodierten Mikrocontrollers wird insbesondere als statische Ausgangs-Scheduling-Datenstruktur bezeichnet. Diese wird insbesondere mittels der vECU Build in die Metadatenstruktur überführt und bildet somit eine variable Scheduling-Datenstruktur, die dann der vECU (virtuelle ECU) zugrundegelegt werden kann. Diese variable Scheduling-Datenstruktur könnte man auch als veränderbare Scheduling-Datenstruktur bezeichnen. Diese kann dann gemäß einem weiteren Aspekt der Erfindung, wie an anderer Stelle im Detail beschrieben, ihrerseits wieder verändert werden, wodurch eine veränderbare / variable Scheduling-Datenstruktur der zweiten, dritten, vierten, ... n-ten Generation entstünde.
Der Kern des Maschinencodes (alternativ als Steuergerätecode oder Steuergerätesoftware bezeichnet), der die Microcontroller steuert, kann dabei unabhängig von der jeweiligen Simulationsumgebung des Herstellers unverändert bleiben. Es wird also insbesondere lediglich eine Änderung der Metadatenstruktur, weiter insbesondere nur eine Änderung der Pointer-/ Zeigersetzung erreicht und/oder durchgeführt. Dadurch ist also insbesondere ein „flashen“ nicht mehr notwendig. Dadurch kann ein feststehender Maschinencode bereitgestellt werden und eine entsprechende Scheduling-Datenstruktur vorbereitet und an die Kunden ausgeliefert werden, die dann, ohne in die Programm- und Codestruktur des Maschinencodes für einen physischen Mikrocontroller einzugreifen, das Scheduling anpassen können. Damit können die Prozesse die das Scheduling kontrollieren verändert werden. Da insbesondere das aufwändige „Flashen“ wegfällt, wird der positive Effekt der Ressourceneinsparung erreicht. Darüber hinaus ist eine standardisierte Auslieferung möglich, was auf Seite des Zulieferers die Effizienz steigert und dennoch die Kundenwünsche adressierbar macht. Auch können so neue Funktionen eingeführt, ausgeführt und/oder auch umgangen und/oder stillgelegt werden. All dies geschieht dabei insbesondere ohne dabei den SteuergeräteCode zu verändern. Weiter insbesondere muss ein physisches Steuergerät nicht mehr bereitgestellt werden, was weitere Kosten spart und ggf. auch den ökologischen Fußabdruck verbessert, da potentiell weniger Müll anfällt.
Prozesse im Sinne der Erfindung sind insbesondere das durch das Scheduling bereitgestellte Ablaufverhalten bestimmter Programmroutinen, die ein Einlesen und/oder Ausgeben von Dateninformationen umfassen können, insbesondere auch von Steuersignalen, die an (simulierte) Ausgabeports (Outports) bereitgestellt werden und/oder simulierte oder/oder echte Signale bzw. Signalwerte, die in der vECU verarbeitet werden sollen. Wie oben beschrieben ist es Teil der Erfindung, dass die Prozesse und/oder deren Schritte insbesondere nicht linear hardcodiert hintereinander gereiht sind, sondern vielmehr durch die jeweilige Datenstruktur als Metadatenstruktur vorgelegt sind, weshalb sich durch Einbau insbesondere von Kontrollpunkten, sog. Performancetags (das englische „Tag“ meint im Deutschen wörtlich „Fähnchen, Kennzeichnung, Plakette“, ist aber im Sinne einer digitalen Kennzeichnung oder digitalen Markierung zu verstehen), kontrollierbar ist, ob eine entsprechende Routine ausgeführt werden soll, ob einem Zeiger gefolgt werden soll und/oder ob ein entsprechendes Auslesen, Schreiben, Überschreiben und/oder Löschen von Daten, Werten, Signalwerten, Zeigern, etc. ausgeführt werden soll oder eben nicht. Beispielsweise können diese Performancetags als „aktiv“ oder „inaktiv“ gesetzt sein. Insbesondere werden interne Signale direkt vor und/oder nach Aufruf des mindestens einen Prozesses überschrieben und somit aktualisiert. Als interne Signale sind insbesondere Signale zu verstehen, die in der vECU generiert, verarbeitet und/oder gehalten werden, um ein echtes Steuergerät zu simulieren. Dabei ist eine Simulation eines Steuergeräts insbesondere derart, dass ein Initiieren des Betriebs, ein Betreiben und ein Abschalten, insbesondere in der virtuellen Simulationsumgebung die gleichen Werte, Zeitfolgen und/oder Abläufe, also ein identisches Prozessverhalten liefert, wie wenn entsprechende Tests mit dem physischen Pendant durchgeführt würden.
Das physische Pendant eines zu simulierenden Steuergeräts kann auch als Target Build bezeichnet werden, da es eine digitale Ausgangsstruktur darstellt, die insbesondere die Metadatenstruktur in Form der Ausgangs-Scheduling-Datenstruktur mindestens teilweise bestimmt. Dieses gilt es insbesondere durch die vECU Build entsprechend in eine Metadatenstruktur zu übersetzen. Dabei wird insbesondere das Scheduling als statisches Ausgangs-Scheduling-Datenstruktur identifiziert. Dieses wird insbesondere in die Metadatenstruktur, insbesondere automatisiert, übersetzt. Darüber hinaus kann die vECU Build auf weitere Fragmente des Target Build zugreifen, um weitere Informationen zu extrahieren. Dabei werden insbesondere die Fragmente, die bei der automatisierten Erstellung der variablen Scheduling-Datenstruktur entstehen verwendet, wobei diese Fragmente Informationen über mindestens einen Teil der Prozesse enthalten, wobei die Informationen insbesondere derart sind, dass sie es ermöglichen in der entstehenden Scheduling-Datenstruktur als Metadatenstruktur aufzugreifen auf welche internen Signale welche Prozesse schreibend oder lesend zugreifen können.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei bei der Bereitstellung oder Erzeugung der vECU eine konfigurierbare Anzahl an reservierten virtuellen Inports generiert wird. Dadurch wird die Effizient gesteigert, Ressourcen gespart, der ökologische Fußabdruck verbessert und die Kosten reduziert.
Durch den vECU Build, wie an anderer Stelle beschrieben, kann, insbesondere aus den weiteren Fragmenten des Target Build, die konfigurierbare Anzahl der virtuellen Inports generiert werden. Dabei ist Inport nicht zu verwechseln mit Import. Die Inports sind hier insbesondere virtuelle Ports und/oder simulierte Anschlüsse, über die Signale eingelesen werden können, die von der virtuellen ECU (vECU) verarbeitet werden können. Diese sollen entsprechend den Vorgaben des realen Gerätes nachgebildet werden, damit später ein Übertrag der entsprechenden Struktur, insbesondere der digitalen Programm und Metadatenstruktur, auf einen physischen Mikrocontroller stattfinden kann, nachdem die entsprechenden Tests und Modifikationen an der Metadatenstruktur für die gewünschte Anwendung durchgeführt sind.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei eine Konfigurationsdatei bei der Initialisierung der vECU eingelesen wird, wobei die Inports zu Signalen zugewiesen werden. Dadurch wird die Effizient gesteigert, Ressourcen gespart, der ökologische Fußabdruck verbessert und die Kosten reduziert.
Die Konfigurationsdatei kann dabei extern generiert worden sein, insbesondere unabhängig vom Target Build und/oder unabhängig von der vECU Build erzeugt worden sein und/oder sich aus der automatisierten Erstellung der Ausgangs-Scheduling-Datenstruktur, der variablen Scheduling-Datenstruktur und/oder der Veränderung der variablen Scheduling-Datenstruktur in Scheduling-Datenstrukturen höherer Generation ergeben.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei weitere Fragmente eines Target Builds vorgelegt werden, wobei das Target Build Merkmale eines echten Steuergeräts umfasst.
Hier wird aus Gründen der Kompaktheit und für die bessere Lesbarkeit auf die Ausführungen an anderer Stelle verwiesen, insbesondere bezüglich des echten Steuergeräts, des virtuellen Steuergeräts und in Bezug auf den oder die Mikrocontroller. Auch hier wird eine Handhabung und Planung der Mikrocontroller verbessert, Ressourcen gespart, die Kosten gesenkt und die Effizienz gesteigert.
Insbesondere sei auf die Definition der Fragmente verwiesen, die bei der automatisierten Erstellung der variablen Scheduling-Datenstruktur entstehen und verwendet werden können, wobei diese Fragmente Informationen über mindestens einen Teil der Prozesse enthalten können, auf welche internen Signale welche Prozesse schreibend oder lesend zugreifen können / sollen.
Die Aufgabe wird durch einen unabhängigen Aspekt insbesondere gelöst durch ein computer-implementiertes Verfahren zum Verändern einer variablen Scheduling-Datenstruktur für virtuelle Steuergeräte oder ein computer-implementiertes Verfahren zum Verändern der variablen Scheduling-Datenstruktur wie gemäß den zuvor beschriebenen Ausführungsformen dargestellt, umfassend die Schritte eines Bereitstellen einer statischen oder variablen Scheduling-Datenstruktur und dem Ändern der bereitgestellten statischen oder variablen Scheduling-Datenstruktur, wobei die statische oder variable Scheduling-Datenstruktur mindestens eines der Folgenden umfasst: Tasks, Prozesse, Zeiger, Signale und/oder Funktionen;
wobei mindestens eine der folgenden Modifikationen beim Ändern durchgeführt wird: ein Verschieben mindestens eines Prozessaufrufes in mindestens einen anderen Task, ein Kopieren mindestens eines Prozessaufrufes in mindestens einen anderen Task, ein Deaktivieren mindestens eines Prozessaufrufes, ein Ändern mindestens eines Zeigers auf eine Funktion und/oder Überschreiben mindestens eines Signals. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Als Task (Englisch für „Aufgabe“) wird dabei insbesondere die Gesamtheit eines Prozesssets verstanden, wobei ein Prozessset eine Zusammenstellung bestimmter Prozesse ist, die dafür benutzt werden können, um die durch den Task definierte, bestimmte Aufgabe zu erfüllen. Damit kann eine Aufgabe auch dadurch verändert werden, wodurch der Task modifiziert werden kann, beispielsweise indem andere Prozesse, andere Funktionen und/oder andere Signale in dem Task verarbeitet, gelesen, geschrieben, ausgeführt, überschrieben und/oder gelöscht werden.
Unter Zeiger (Funktionszeiger, Wertezeiger, Prozessezeiger; Englisch: „Pointer“) wird Erfindungsgemäß eine Programmroutine verstanden, die auf eine andere Sektion eines Speichermediums, einen anderen Abschnitt bei einer Programmroutine, einen anderen Wert auf einem Speichermedium oder in einem Arbeitsspeicher oder vergleichbar verweist.
Als Ändern eines Zeigers ist dabei insbesondere das „Umsetzen“ eines Zeigers zu verstehen, was dazu führt, dass der Zeiger nach der Änderungsoperation auf eine andere Sektion eines Speichermediums, einen anderen Abschnitt bei einer Programmroutine, einen anderen Wert auf einem Speichermedium oder in einem Arbeitsspeicher oder vergleichbar verweist, als vor der Änderungsoperation.
Unter Funktionen sind erfindungsgemäß insbesondere mathematische Funktionen, aber auch generell Rechenoperationen zu verstehen, wobei eine Rechenoperation eine Computer- oder vECU-Operation ist, die insbesondere auch einen Rechenoperationsschritt der in einem physischen Steuergerät stattfinden kann, nachbildet.
Insbesondere erlaubt das Erzeugen von variablen Scheduling-Datenstrukturen höherer Ordnung, dass in einem iterativen Ansatz die Auswirkungen der Änderungen an der Metadatenstruktur überprüft werden können. Dadurch kann auch während des Betriebs des virtuellen Steuergeräts Änderungen und Anpassungen vorgenommen werden, um so direkt die Auswirkungen zu überprüfen, die etwa durch ein Bypassen oder Ausschneiden von Funktionen erfolgt. Dabei muss also insbesondere nicht mehr jedesmal von der ursprünglich zugrunde gelegten Metadatenstruktur gestartet werden.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei während der Laufzeit mindestens eine der an anderer Stelle beschriebenen Modifikationen vorgenommen wird.
Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Unter Laufzeit ist dabei erfindungsgemäß insbesondere die Laufzeit eines virtuellen Steuergeräts und/oder einer Simulationsumgebung in der eine vECU läuft gemeint. Dabei ist generell unter einem „Laufen“ zu verstehen, dass die jeweilige Bezugseinheit, virtuelles Steuergerät und / oder Simulationsumgebung, aktiv ist und Rechenoperationen ausführt und / oder insbesondere eine Initialisierung eines virtuellen Steuergeräts, einen Betrieb eines virtuellen Steuergeräts oder ein Abschalten eines virtuellen Steuergeräts ausführt, wobei insbesondere das Verhalten eines realen, physischen Steuergeräts nachgeahmt und/oder simuliert wird.
Als Simulationsumgebung wird erfindungsgemäß insbesondere eine in sich (weitestgehend) geschlossene Rechenumgebung auf einem Rechensystem, insbesondere auf einem x86-PC verstanden, die es erlaubt Maschinencodes für Steuergeräte so zu betreiben und deren Routinen auszuführen, dass ein Testen des Steuergerätecodes / Maschinencodes und/oder der erfindungsgemäßen statischen und/oder variablen Scheduling-Datenstrukturen möglich ist.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei weitere Fragmente eines Target Builds vorgelegt werden, wobei die Target Builds Merkmale eines echten Steuergeräts umfassen. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Hier wird aus Gründen der Kompaktheit und für die bessere Lesbarkeit auf die vorigen Ausführungen, insbesondere zum Target Build und zum echten Steuergerät zurückverwiesen.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei die Prozessstrukturen mindestens eine Liste mit Signal-Modifikationen für den jeweiligen Prozess umfassen. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Prozessstrukturen sind dabei insbesondere die als Metadaten hinterlegte Struktur eines Prozesses, der sich insbesondere auch in einem Ablaufschema von einer Initiierung bis zu einem Abschluss darstellen lässt. Dabei kann die Prozessstruktur also sowohl auf den zeitlichen Verlauf eines Prozesses an sich, als auch auf seine programmtechnische strukturelle Organisation bezogen sein. In Bezug auf die hier beschriebenen Listen wird darauf hingewiesen, dass es sich in diesem Fall um eine zunächst programmtechnische strukturelle Organisation handelt. Allerdings kann durch die Veränderung der variablen Scheduling-Datenstruktur diese programmtechnisch strukturelle Organisation eine zeitliche Verlaufsänderung bewirken, wodurch diese beiden Bedeutungen nicht notwendigerweise strikt getrennt voneinander gedacht und/oder bearbeitet werden können, da es gerade die Aufgabe der Erfindung ist, das Scheduling über die Zeigerstrukturen und damit auch über die Signaländerungen und das Signalupdating (Signalaktualisierung) dynamisch und insbesondere auch flexibel zu halten. Dadurch kann es ermöglicht werden, dass die verschiedene Simulationsumgebungen von verschiedenen Herstellern genutzt werden können, ohne den Maschinencode des virtuellen Steuergeräts zu verändern, bzw. die entsprechenden Werte, beispielsweise an den Inports für die Simulation vorher festzulegen.
Erfindungsgemäß weisen die Listen insbesondere Signal-IDs auf, für die Signale, die überschrieben werden sollen, wobei insbesondere über eine Zeigertabelle auf die Signal-Definitionen des Signals zugegriffen werden kann. Dabei wird in Bezug auf die Definition des Zeigers auf andere Stellen verwiesen. Als Signal-ID (Signalidentifikation, Signal-Tag, Signalmarker) sind insbesondere derartige Merkmale und Zeichenkombinationen zu verstehen, die eine eindeutige Identifikation des zugehörigen Signals, insbesondere auf seinem Weg durch die vECU, sicherzustellen.
Als Signalmodifikation ist dabei insbesondere ein Update eines alten Signals durch ein neues Signal zu verstehen und des Weiteren ein Löschen eines Signals zu verstehen. Alternativ oder zusätzlich kann ein anderes, vergleichbares Modifizieren vorgesehen sein, wobei das Modifizieren das Ausführen von Operationsschritten darstellt, die in seinem allgemeinsten Verständnis eine Änderung des Signals bewirken.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei mindestens ein Signal ein internes Signal der vECU ist und wobei die vECU mindestens einen virtuellen Inport aufweist, wobei der mindestens eine virtuelle Inport mindestens einen Wert zur Verfügung stellt, für das Überschreiben des mindestens einen internen Signals. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Dabei ist ein Wert eines Signals insbesondere ein Zahlenwert der als Datenformat „double“ vorliegt. Darüber hinaus wird ein expliziter Cast erzeugt.
Ein Signal ist im Sinne der Erfindung ein internes Signal, wenn es mindestens zeitweise die vECU und/oder den virtuellen Mikrocontroller durchläuft, insbesondere von einem Inport zu einer Verrechnungseinheit, die die vECU ausführt und insbesondere eine Recheneinheit eines realen Steuergeräts nachahmt.
Nach einer Ausführungsform wird die Aufgabe insbesondere durch ein erfindungsgemäßes Verfahren gelöst, wobei die mindestens eine Signalmodifikation mittels der vorher bereitgestellten Datenstruktur vor und nach dem Ausführen eines Prozesses, der auf mindestens ein Signal zugreift, durchgeführt wird, wobei das mindestens eine Signal mit dem mindestens einen Wert des entsprechend zugewiesenen mindestens einen Inports überschrieben wird. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Insbesondere ist der Dateityp dabei immer „double“ und es wird insbesondere ein expliziter Cast ausgeführt. Diesbezüglich wird auf andere Ausführungen diesbezüglich für weitere Details verwiesen.
Die Aufgabe wird durch einen unabhängigen Aspekt insbesondere gelöst durch ein Datenverarbeitungssystem, umfassend Mittel zur Ausführung des Verfahrens nach einem der an anderer Stelle beschriebenen Ausführungsformen und Aspekte. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Als Datenverarbeitungssystem ist dabei insbesondere ein x86-PC zu verstehen, es kann aber auch alternativ ein handelsübliches Rechensystem Verwendung finden, sowie ein Großrechencenter, das in der Lage ist Hochdurchsatzrechnungen auszuführen und eine Vielzahl von Operationen pro Zeiteinheit oder insbesondere auch eine Vielzahl von Operationen parallel pro Zeiteinheit ausführen kann.
Aus Gründen der Kompaktheit und für die bessere Lesbarkeit wird auf die Ausführungen an anderer Stelle verwiesen. Dabei können Verfahrensmerkmale herangezogen werden, um ein System genauer zu beschreiben. Gleiches gilt für die Merkmale eines Computerprogramms, einer Datenstruktur und/oder einer Nutzung der aufgeführten Ausführungsformen und Aspekte. Die Erklärungen, Definitionen und Beschreibungen, die in Bezug auf die verschiedenen Aspekte und Ausführungsformen der Erfindung hier und an anderer Stelle gemacht werden, sind diesbezüglich nicht auf deren jeweilige Kategorie (System, Verfahren, Vorrichtung, Verwendung) beschränkt, sondern dienen vielmehr dazu bestimmte weitere Aspekte und/oder Ausführungsformen darzustellen, deren Merkmale als ganzes die Erfindung im Detail beschreiben.
Die Aufgabe wird durch einen unabhängigen Aspekt der Erfindung insbesondere gelöst durch ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren nach einem der an anderer Stelle beschriebenen Aspekte und Ausführungsformen auszuführen. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Ein Computerprogramm ist dabei insbesondere ein Programm, das auf einem an anderer Stelle definierten Datenverarbeitungssystem oder einem Rechensystem ausgeführt werden kann. Dabei wird das Computerprogramm insbesondere derart ausgebildet sein, um ein reales Steuergerät, digital nachzubilden und eine Ausführung, insbesondere von der Initiierung, über den Betrieb, bis zum Ausschalten derart zu simulieren, dass die erzeugten und ausgegebenen Daten den Daten entsprechen, die ein reales Steuergerät ausgeben würde, wenn es einen entsprechenden Input, insbesondere über die Inports bekäme und diese entsprechend durch die ECU laufen, wie sie entsprechend durch die vECU laufen.
Dabei können Befehle seitens eines Benutzers und/oder aber auch völlig automatisiert eingegeben, gelesen, aktualisiert, verarbeitet und/oder gelöscht werden.
Im Sinne der Erfindung ist ein Computer insbesondere nur eine spezielle Form eines Datenverarbeitungssystems. Diesbezüglich wird auf die Ausführungen an anderer Stelle verwiesen und auf Wiederholungen wird verzichtet.
Aus Gründen der Kompaktheit und für die bessere Lesbarkeit wird auf die Ausführungen an anderer Stelle verwiesen. Dabei können Verfahrensmerkmale herangezogen werden, um ein System genauer zu beschreiben. Gleiches gilt für die Merkmale eines Computerprogramms, einer Datenstruktur und/oder einer Nutzung der aufgeführten Ausführungsformen und Aspekte. Die Erklärungen, Definitionen und Beschreibungen, die in Bezug auf die verschiedenen Aspekte und Ausführungsformen der Erfindung hier und an anderer Stelle gemacht werden, sind diesbezüglich nicht auf deren jeweilige Kategorie (System, Verfahren, Vorrichtung, Verwendung) beschränkt, sondern dienen vielmehr dazu bestimmte weitere Aspekte und/oder Ausführungsformen darzustellen, deren Merkmale als ganzes die Erfindung im Detail beschreiben.
Die Aufgabe wird durch einen unabhängigen Aspekt der Erfindung insbesondere gelöst durch eine Scheduling-Datenstruktur nach einem erfindungsgemäßen Verfahren gemäß der an anderer Stelle beschriebenen Ausführungsformen und Aspekte oder wobei die Scheduling-Datenstruktur eine variable Scheduling-Datenstruktur ist, die mindestens eines der Folgenden umfasst: Tasks, Prozesse, Zeiger, Signale und / oder Funktionen; wobei bei der variablen Scheduling-Datenstruktur mindestens eine der folgenden Modifikationen gegenüber einer Ausgangs-Scheduling-Datenstruktur durchgeführt ist: eine Verschiebung mindestens eines Prozessaufrufes in mindestens einen anderen Task, eine Kopierung mindestens eines Prozessaufrufes in mindestens einen anderen Task, eine Deaktivierung mindestens eines Prozessaufrufes, eine Änderung mindestens eines Zeigers auf eine Funktion und /oder Überschreibung mindestens eines Signals. Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Aus Gründen der Kompaktheit und für die bessere Lesbarkeit wird auf die Ausführungen an anderer Stelle verwiesen. Dabei können Verfahrensmerkmale herangezogen werden, um ein System genauer zu beschreiben. Gleiches gilt für die Merkmale eines Computerprogramms, einer Datenstruktur und/oder einer Nutzung der aufgeführten Ausführungsformen und Aspekte. Die Erklärungen, Definitionen und Beschreibungen, die in Bezug auf die verschiedenen Aspekte und Ausführungsformen der Erfindung hier und an anderer Stelle gemacht werden, sind diesbezüglich nicht auf deren jeweilige Kategorie (System, Verfahren, Vorrichtung, Verwendung) beschränkt, sondern dienen vielmehr dazu bestimmte weitere Aspekte und/oder Ausführungsformen darzustellen, deren Merkmale als ganzes die Erfindung im Detail beschreiben.
Die Aufgabe wird durch einen unabhängigen Aspekt der Erfindung insbesondere gelöst durch eine Nutzung einer Scheduling-Datenstruktur nach einem an anderer Stelle beschriebenen Aspekt der Erfindung, durch eine Nutzung eines Computerprogramms nach einem an anderer Stelle beschriebenen Aspekts der Erfindung, durch eine Nutzung eines Datenverarbeitungssystems nach einem an anderer Stelle beschriebenen Aspekt der Erfindung oder eines Verfahrens nach einem der an anderer Stelle beschriebenen Ausführungsformen und Aspekte der Erfindung, wobei in einer Simulationsumgebung eines der Folgenden abläuft: ein Initiieren, ein Betreiben und/oder ein Abschalten eines virtuellen Steuergerätes.
Dies verbessert eine Handhabung und Planung der Mikrocontroller, spart Ressourcen, senkt die Kosten und steigert die Effizienz.
Aus Gründen der Kompaktheit und für die bessere Lesbarkeit wird auf die Ausführungen an anderer Stelle verwiesen. Dabei können Verfahrensmerkmale herangezogen werden, um ein System genauer zu beschreiben. Gleiches gilt für die Merkmale eines Computerprogramms, einer Datenstruktur und/oder einer Nutzung der aufgeführten Ausführungsformen und Aspekte. Die Erklärungen, Definitionen und Beschreibungen, die in Bezug auf die verschiedenen Aspekte und Ausführungsformen der Erfindung hier und an anderer Stelle gemacht werden, sind diesbezüglich nicht auf deren jeweilige Kategorie (System, Verfahren, Vorrichtung, Verwendung) beschränkt, sondern dienen vielmehr dazu bestimmte weitere Aspekte und/oder Ausführungsformen darzustellen, deren Merkmale als ganzes die Erfindung im Detail beschreiben.
Kurze Beschreibung der Zeichnungen
Nicht beschränkende und nicht erschöpfende Ausführungsformen der vorliegenden Offenbarung werden nachfolgend mit Bezugnahme auf die folgenden Figuren beschrieben.
Dabei zeigen die

1: einen schematischen Ablauf eines virtuellen Steuergeräts in zwei Simulationsumgebungen verschiedener Hersteller;
2: eine schematische Darstellung eines Computer-implementierten Verfahrens zur Erzeugung einer variablen Scheduling-Datenstruktur;
3: eine schematische Darstellung einer variablen Scheduling-Datenstruktur;
4: eine schematische Darstellung einer variablen Scheduling-Datenstruktur mit einer dynamisch gelinkten Plugin-DLL;
5: eine schematisch Darstellung einer Modifikation von internen Signalen der vECU - Datenstrukturen;
6: eine schematische Darstellung eines Ablaufs der Modifikation von internen Signalen der vECU - Datenstruktur.

Beschreibung bevorzugter Ausführungsbeispiele
1 zeigt beispielhaft und schematisch die Funktionsweise eines virtuellen Steuergeräts in der Simulationsumgebung 100 eines ersten Herstellers, sowie in der Simulationsumgebung 200 eines zweiten Herstellers. Diese beiden Simulationsumgebungen unterscheiden sich. Allerdings ist die Funktionsweise des virtuellen Steuergeräts identisch dahingehend, dass der gleiche Ausgangsmaschinencode verwendet werden kann. Dadurch ist es möglich, dass in beiden Simulationsumgebungen ein Initialisieren I, ein Betreiben B und ein Abschalten A des virtuellen Steuergeräts möglich ist. Dazu muss der Maschinencode nicht verändert werden. Vielmehr ist es möglich, ohne eine Veränderung des Maschinencodes Änderungen an der Prozessreihenfolge und der Durchführung des Programms durchzuführen, da lediglich eine Metadatenstruktur geändert werden muss. Damit kann eine Anpassung der virtuellen Steuergeräte simuliert werden, die an den jeweiligen Bedarf und die jeweilige Aufgabe (= Task) angepasst sind.
In 2 wird schematisch veranschaulicht, wie dies bewerkstelligt wird, ohne dabei den Maschinencode zu verändern. Zunächst wird der Maschinencode ausgehend von einem Target Build auf vorgegebene statische Target Schedules untersucht, die als zunächst vorgegebene statische Scheduling-Datenstruktur 10 fungieren. Ausgehend von dem Scheduling der Steuergerätesoftware (= Maschinencode) wird bei der Generierung des virtuellen Steuergeräts automatisiert ein neues Scheduling für das virtuelle Steuergerät erstellt. Die Steuergerätesoftware gibt zunächst eine statische Scheduling-Datenstruktur 10 vor, die Prozessablaufstrukturen umfasst. Zusätzlich werden Informationen aus weiteren Fragmenten 20 eines Target Builds extrahiert. Dieser Target Build ist die Steuergerätesoftware selbst und/oder der Maschinencode des Mikrocontrollers, der virtuell vorgelegt werden soll. Diese Fragmente entstehen bei der automatisierten Erstellung der originalen Steuergerätesoftware und sie enthalten Informationen darüber, welche Prozesse auf welches interne Signal 60 lesend oder schreibend zugreifen können. Dieses Lesen und Schreiben ist in Bezug auf die 5 und 6 im Detail beschrieben. Die Informationen dienen dazu, um zusammen mit der veränderbaren Scheduling-Datenstruktur, interne Signale 60 direkt vor oder nach Aufruf eines Prozesses zu überschreiben. Dazu wird die statische Scheduling-Datenstruktur 10 und die Fragemente 20 durch ein vECU-Build 5 verarbeitet. Bei der vECU-Build handelt es sich um ein Programm, dass die oben aufgeführten Daten, Informationen und Codequellen derart analysieren kann, dass es diese in eine Metadatenstruktur überführt, die als variable Scheduling-Datenstruktur 30 bezeichnet ist. Dazu werden verschiedene Tasks 31, 33 angelegt, die verschiedene Prozesse 32', 32", 32'", 34', 34'', 34''' aufweisen, die allerdings nicht mehr hardcodiert hintereinander ablaufen müssen, sondern durch die Metadatenstruktur mit entsprechenden Zeigern 38, 45 63, 64 versehen sind, wodurch eine Veränderung des Ablaufs und der Prozessreihenfolge, sowie der eingelesenen Daten variiert werden kann und wodurch auch Prozesse, Funktionen und Signale, sowie deren Werte ausgelesen und geschrieben werden können, kopiert und gelöscht werden können oder neue Werte eingeschrieben werden können.
In der 2 ist exemplarisch eine erste Aufgabe (= Task 31) dargestellt. Diese setzt sich zusammen aus einem Prozessaufruf 32, und weiteren Prozessaufrufen für insgesamt eine Anzahl von i Prozessen. Hier wird schematisch dargestellt, wie ein erster Prozessaufruf 32' stattfindet, wodurch auf einen Zeiger 35 auf eine Prozesstruktur zugegriffen wird. Dadurch wird wiederum auf eine entsprechende Prozessstruktur 37 zugegriffen, soweit ein Aufrufaktivitätstag 36 den Aktivitätsstatus für den Aufruf des Prozesses auf „aktiv“ angibt. In diesem Fall wird auf die entsprechende Prozessstruktur 37 zugegriffen. Diese umfasst hier wiederum einen Funktionszeiger 38, einen Prozessnamen 39, eine Liste 40 mit Signalmodifikationen, sowie ein Prozessaktivitätstag 41 mit Angabe über den Aktivitätsstatus für die Ausführung des Prozesses. Dieser kann also auch noch nach Zugriff auf die Prozessstruktur unterbrochen werden, weil der Tag etwa nicht auf „aktiv“, sonder auf „inaktiv“ steht. Damit gibt es verschiedene Kontrollpunkte, an denen ein Abbruch des Prozesses erfolgen kann oder an denen eine Initiierung des Prozesses erst gar nicht stattfindet. Entsprechendes gilt auch für ein zweites Task Array 33, mit zweitem Prozessset 34 und einer Gesamtanzahl von j Prozessen. Dieses wird im gezeigten Ausführungsbeispiel aber nicht angesprochen und es wird auch nicht darauf zugegriffen. Damit werden die darin eingeschriebenen Prozesse also zunächst umgangen („gebypasst“).
Wie in der 3 gezeigt ist die variable Scheduling-Datenstruktur deshalb als variabel zu bezeichnen, weil zunächst keine hardcodierte Aneinanderreihung von Prozessen vorgegeben ist, wodurch zu bestimmten Zeitpunkten oder auch über einen bestimmten Zeitraum vorschrieben wäre, wann und wie die Prozesse abzulaufen haben. Vielmehr kann ein i-ter Prozessaufruf in ein anderes Task-Array verschoben werden oder wie hier gezeigt, kopiert 42 werden, wobei ein Prozessaufruf im Zieltaskarray 33 ersetzt wird. Alternativ oder zusätzlich kann auch ein Einfügen, ein Löschen, ein Überschreiben oder ähnliche Operationen erfolgen. Dadurch lässt sich die Taskzusammenstellung individuell anpassen. Zusätzlich sind Kontrollpunkte eingerichtet, wobei an den jeweiligen Kontrollpunkten, wie etwa dem Aufrufaktivitätstag 36 mit Aktivitätsstatus für den Aufruf des Prozesses und/oder dem Prozessaktivitätstag 41 mit Aktivitätsstatus für Ausführung des Prozesses und/oder der Abfrage 72 zum Aktivitätsstatus der Signalmodifikation m (siehe 6). Diese können alle oder einzeln oder in jeder Kombination vorliegen. Dadurch kann ein flexibler, also variabler Prozessablauf ermöglicht werden, wodurch sich eine variable Scheduling-Datenstruktur ergibt. Wenn etwa der Aufrufaktivitätstag 36 den Aktivitätsstatus für den Aufruf des Prozesses auf inaktiv setzt, dann kommt es zum Stop 44 des Prozessaufrufs. Wenn der Prozess indes aufgerufen wird, dann führt der Zeiger 35 zur Prozessstruktur 37 des aufgerufenen Prozesses. Diese umfasst mindestens einen Funktionszeiger 38, der auf eine auszuführenden Funktion zeigt. Dadurch wird ein Funktionsaufruf 43 ausgeführt. Der Name 39 des Prozesses ist in der Prozessstruktur enthalten. Die Prozessstruktur umfasst des Weiteren eine Liste 40 mit Signalmodifikationen, die die Signale 60 enthält die modifiziert werden, vor oder nach dem der Prozess ausgeführt worden ist, wie an anderer Stelle ausgeführt. In der Prozessstruktur ist auch ein Prozessaktivitätstag 41mit dem Aktivitätsstatus für die Ausführung des Prozesses vorgesehen, wodurch auch noch an dieser Stelle die Ausführung des Prozesses unterbrochen werden kann, wenn der Prozessaktivitätstag 41 auf inaktiv gesetzt ist. Wenn der Prozessaktivitätstag 41 indes auf „aktiv“ gesetzt ist, dann wird der Prozess ausgeführt. Dadurch wird über den Funktionszeiger 38 mindestens eine Funktion aufgerufen, die Bestandteil des Prozesses ist. Auch wenn hier nicht explizit aufgeführt, so kann ein Prozess auch mehr als eine Funktion und/oder auch mehr als ein Signal 60 aufweisen.
4 zeigt eine der 3 entsprechende variable Scheduling-Datenstruktur 30. Allerdings wird entgegen der 3 nicht auf eine Prozessstruktur 37 mittels eines Zeigers 35 zugegriffen, sondern auf eine dynamisch gelinkte Bibliothek (Plugin-DLL für Plugin Dynamic Link Library), also auf eine Datenbank, die eine Bypassfunktion aufweist, wodurch die in der 3 dargestellte Funktion nicht mehr Teil des Prozesses bildet. Diese Funktion wurde entsprechend aus der Prozessstruktur ausgeschnitten und steht bei diesem virtuellen Mikrocontroller nicht mehr zur Verfügung, bis der Zeiger 35 wieder „umgesetzt“ wird. Bypassfunktionen nutzen Programmierschnittstellen, sogenannte APIs zum Lesen und Schreiben von internen Signalen der vECU. Dadurch kann während des Betreibens B des virtuellen Mikrocontrollers in einer Simulationsumgebung 100 eines ersten Herstellers der virtuelle Mikrocontroller an diese angepasst werden. Dabei muss kein physischer Mikrocontroller bereitgestellt werden und dieser muss auch nicht mit anderem Maschinencode aufgeflasht werden. Für den Fall, dass ein entsprechender virtueller Mikrocontroller an einen zweiten Hersteller „ausgeliefert“ wird, also entsprechend übermittelt wird, der eine zweite Simulationsumgebung 200 benutzt, so kann dieser virtuelle Mikrocontroller an diese zweite Simulationsumgebung 200 angepasst werden, auch während eines Betreibens B des virtuellen Mikrocontrollers. Eine Anpassung kann auch erfolgen, ohne den Maschinencode entsprechend zu bearbeiten, wie an anderer Stelle ausgeführt.
In 5 wird die Modifikation von internen Signalen 60 der vECU in den Datenstrukturen einer variablen Scheduling-Datenstruktur 30 dargestellt. Dies geschieht durch Veranschaulichung der Metadatenstruktur 600, die dieser variablen Scheduling-Datenstruktur 30 zugrunde liegt. Die Darstellung geht aus von den Prozessstrukturen 37, wie sie an anderer Stelle beschrieben sind. Die an anderer Stelle beschriebenen Bestandteile, Verfahrensabläufe, Datenströme und Informationsströme aus den 1 bis 4 bleiben dabei entsprechend gültig und können auf die 5 übertragen werden, bzw. dem dort dargestellten entsprechend hinzugefügt werden. Dies wird hier auf Grund der entsprechenden Kürze und Prägnanz der Anmeldung nicht erneut veranschaulicht, sondern für das Verständnis des Fachmanns wird entsprechend auf die Ausführungen an anderer Stelle verwiesen. Die Prozessstrukturen 37 umfassen eine Liste 40 mit Signalmodifikationen für den jeweiligen Prozess, auf den sie sich beziehen, bzw. den sie spezifizieren. In dieser Liste 40 sind die Signal-IDs (Signalidentifikationen, Signalidentifikationsnummern, Signalidentifikationstags) 47 der Signale 60 hinterlegt, die überschrieben werden sollen. Dabei kann über eine Zeigertabelle, die Signalmodifikationszeiger 45 enthält, auf die entsprechende Liste mit den Signalmodifikationen zugegriffen werden. Dabei ist zunächst ein Signalmodifikationsaktivitätstag 46 als Kontrollpunkt hinterlegt, an dem überprüft wird, ob die Signalmodifikation erfolgen soll. Ist dieser Signalmodifikationsaktivitätstag 46 auf „inaktiv“ gesetzt erfolgt keine Signalmodifikation 71 für das entsprechende Signal 60. Sitzt der Signalmodifikationsaktivitätstag 46 auf „aktiv“, kann eine Signaländerung durchgeführt werden. Diese wird auch durchgeführt, wenn eine entsprechende Signaländerung in Form von Metadaten hinterlegt ist, wie im Folgenden beschrieben. Dazu wird, wie schon beschrieben, die Signal-ID 47', 47'', 47''' des entsprechenden Signals 60 aus der Signalmodifikation 71 gelesen, der ein entsprechender Signaldefinitionszeiger 60', 60'', 60''' zugeordnet ist, der wiederum auf eine Signaldefinition 70 verweist. Diese Signaldefinition 70 umfasst einen Signalnamen 61, einen Datentyp 62, einen Signalzeiger 63, einen Zeiger 64 auf eine Liste mit Prozessen und schließlich eine Anzahl 65 der Prozesse die auf das Signal zugreifen. Die Art des Zugriffs, also ob lesend oder schreibend auf die Daten zugegriffen wird, ist in der Signalmodifikation 71 selbst hinterlegt, als Signalrichtung 48. Auch ist in der Signalmodifikation 71 die Port-ID 49 (Portidentifikation, Portidentifikationstag, Portidentifikationsnummer) hinterlegt, also die ID (Identifikationsnummer, Identifikationstag, Identfikationsname) des Ports an dem der entsprechende Wert für die Signalmodifikation anliegt. Somit können durch das virtuelle Steuergerät, bzw. den virtuellen Mikrocontroller sogenannte Inports nachgebildet werden, über die Signale 60 mit einem bestimmten Wert eingehen. Das Feature der Signalmodifikation bietet somit die Möglichkeit interne Signale 60 der vECU mit Werten zu überschreiben, die an virtuellen Inports der vECU zur Verfügung gestellt werden. Bei der Erzeugung, bzw. beim Zusammensetzen (man kann auch von einem Bauen sprechen, wobei kein physisches Zusammenbauen in Form eines körperlich-materiellen Erschaffens eines körperlichen Gegenstands gemeint ist) der vECU durch den vECU Build 5 wurde eine konfigurierbare Anzahl an reservierten virtuellen Inports generiert. Mit einer Konfigurationsdatei, die bei der Initialisierung der vECU eingelesen wird, können die Inports zu Signalen 60 zugewiesen werden. Die Signalmodifikation 71 wird dann mittels der vorgestellten Datenstruktur vor und nach dem Ausführen eines Prozesses, der auf das Signal zugreift, durchgeführt. Das bedeutet, dass das entsprechende Signal mit dem Wert, der am entsprechenden Inport anliegt, überschrieben wird. Der Datentyp 62, der hier Verwendung findet ist double. Beim Überschreiben des Signals 60 wird ein expliziter Cast durchgeführt.
6 zeigt schematisch den Verfahrensablauf 700, der zu einer Modifikation der internen Signale 60 der vECU führt, wie sie in der Metadatenstruktur 600 der 5 dargestellt sind. Dazu wird zunächst der Prozess initialisiert in einer Prozessinitialisierung 80. Dabei wird die Anzahl 81 der Signalmodifikationen ausgelesen, die für diesen Prozess vorgesehen ist. Dieser Anzahl 81 wird als Parameter, etwa als Zählparameter m, verwendet, für die folgenden Entscheidungsbäume, wie sie in der 6 dargestellt sind. Dabei wird für m = 0, also wenn keine Signale 60 geändert werden sollen, der Prozess direkt ausgeführt in einer Prozessausführung 84. Ist m > 0, so wird ein Zählschritt durchgeführt, der mit m = 1 beginnt. Dazu erfolgt für m = 1 eine Abfrage 82 bezüglich des Aktivitätsstatus der Signalmodifikation m, wie sie in der 5 in der Metadatenstruktur 600 als Signalmodifikationsaktivitätstag 46 hinterlegt ist. Ist dieser Signalmodifikationsaktivitätstag 46 aktiv, kommt es zur Verwendung der Signalinformationen und zur Signalüberschreibung. Diese erfolgt unter Verwendung des Datentyp, des Signalzeigers und des Wertes des zugewiesenen Inports, wie in 5 gezeigt und hier an anderer Stelle dargestellt. Anschließend kommt es zur Prozessausführung 84. Es kann auch zu einer weiteren Schleifendurchführung kommen, bei der die anderen Signalwerte für m > 1 entsprechend verarbeitet werden und die Signalwerte entsprechend für diese Zählparameterwerte von m zur Verwendung 83 und Überschreibung der ursprünglichen Signalwerte benutzt werden.
Ist für den Zählparameterwert von m = 1 der Signalmodifikationsaktivitätstag 46 auf inaktiv gesetzt, so wird der Zählparameterwert m gemäß der Formel m = m + 1 um eins erhöht und die Schleife wird erneut durchlaufen. Dieser Prozess läuft solange ab, bis alle Zählparameterwerte von m durchlaufen sind. Somit kann der Prozess in der Prozessausführung 84 mit einem aktualisierten oder entsprechend den Vorgaben an den (virtuellen) Inports vorgegebenen Set von Signalwerten durchlaufen werden.
Alle diese Merkmale ermöglichen ein variables Scheduling zur Modellierung von Bypassfunktionen und das Testen von freigeschnittenen Steuergerätefunktionen in virtuellen Steuergeräten.
Bezugszeichenliste

5: vECU-Build
10: Target Build mit statischer Scheduling-Datenstruktur
20: Fragmente eines Target Build
30: variable Scheduling-Datenstruktur
31: erstes Task Array
32: erstes Prozessset
32', 32'', 32''',...: Aufruf eines i-ten Prozesses aus dem ersten Prozessset
33: zweites Task Array
34: zweites Prozessset
34', 34'', 34''',...: Aufruf eines j-ten Prozesses aus dem zweiten Prozessset
35: Zeiger zu Prozessstruktur
36: Aufrufaktivitätstag mit Aktivitätsstatus für Aufruf des Prozesses
37: Prozessstruktur des aufgerufenen Prozesses
38: Funktionszeiger
39: Prozessname
40: Liste mit Signalmodifikationen
41: Prozessaktivitätstag mit Aktivitätsstatus für Ausführung des Prozesses
42: Kopieren eines Prozesses in ein anderes Task Array und Ersetzen eines Prozesses im anderen Task Array
43: Funktionsaufruf
44: Stop des Prozessaufrufs bei Aufrufaktivitätstag „inaktiv“
45: Signalmodifikationszeiger
45',45'',45''',...: Signalmodifikationszeiger 1, Signalmodifikationszeiger 2,
...: Signalmodifikationszeiger n
46: Signalmodifikationsaktivitätstag
47: Signal-ID
47', 47'', 47'''...: Signal-ID 1, Signal-ID 2, ... Signal-ID n
48: Signalrichtung (lesend, schreibend)
49: Port-ID des Ports an dem der Wert für die Signalmodifikation anliegt
50: Plugin-DLL mit Bypassfunktion
60: Signal
60', 60'', 60'''...: Signaldefinitionszeiger 1, Signaldefinitionszeiger 2, ..., Signaldefinitionszeiger m
61: Signalname
62: Signaldatentyp
63: Signalzeiger
64: Zeiger auf Liste mit Prozessen
65: Anzahl der Prozesse die auf das Signal zugreifen
70: Signaldefinition 1
71: Signalmodifikation 1
80: Prozessinitialisierung
81: Anzahl der Signalmodifikationen für i-ten Prozess
82: Abfrage Aktivitätsstatus Signalmodifikation m
83: Verwendung Signalinformationen (Datentyp, Signalpointer, Wert des zugewiesenen Inports) und Signalüberschreibung
84: Prozessausführung
100: Simulationsumgebung eines ersten Herstellers
200: Simulationsumgebung eines zweiten Herstellers
300: Computer-implementiertes Verfahren einer Umwandlung einer statischen Scheduling-Datenstruktur in eine variable Datenstruktur
400: Umsetzen der Zeigerstruktur und Zeigerstruktur in einem Computerimplementierten Verfahren
500: Umsetzen der Zeigerstruktur auf eine dynamische Bibliothek Plugin-DLL und Zeigerstruktur in einem Computer-implementierten Verfahren
600: Metadatenstruktur für die Änderung interner Signale der vECU
700: Computer-implementiertes Verfahren und dessen Ablauf zur Änderung interner Signale der vECU
I: Intialisieren
B: Betreiben
A: Abschalten

Claims

Ein computer-implementiertes Verfahren (300) zum Erzeugen einer variablen Scheduling-Datenstruktur (30) für virtuelle Steuergeräte (vECUs), umfassend die Schritte: - Bereitstellen einer statischen Ausgangs-Scheduling-Datenstruktur, - Bereitstellen einer vECU Build (5), - Generieren der variablen Scheduling-Datenstruktur (30), wobei statische Ausgangs-Scheduling-Datenstruktur mindestens ein Element aufweist von - Tasks (31, 33) - Prozesse (32, 34) - Zeiger (38, 45, 63, 64) - Signale (60) - Funktionen, wobei die vECU Build beim Generieren der variablen Scheduling-Datenstruktur (30) mindestens eines dieser Elemente identifiziert und der variablen Scheduling-Datenstruktur als Meta-Information automatisiert zuordnet, wobei, die Meta-Information ausgebildet ist derart, um zu einer Laufzeit eines virtuellen Steuergeräts (vECU) verändert zu werden.
Das Verfahren (300) nach Anspruch 1, dadurch gekennzeichnet, dass bei der Bereitstellung oder Erzeugung der vECU eine konfigurierbare Anzahl an reservierten virtuellen Inports generiert wird.
Das Verfahren (300) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Konfigurationsdatei bei der Initialisierung der vECU eingelesen wird, wobei die Inports zu Signalen (60) zugewiesen werden.
Das Verfahren (300) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass weitere Fragmente eines Target Builds vorgelegt werden, wobei die Target Build Merkmale eines echten Steuergeräts umfasst.
Ein computer-implementiertes Verfahren (300) zum Verändern einer variablen Scheduling-Datenstruktur (30), insbesondere der variablen Scheduling-Datenstruktur (30) nach einem der vorhergehenden Ansprüche, umfassend die Schritte: - Bereitstellen der variablen Scheduling-Datenstruktur (30), - Ändern der bereitgestellten variablen Scheduling-Datenstruktur (30), wobei die variable Scheduling-Datenstruktur (30) mindestens eines der Folgenden umfasst: - Tasks (31, 33) - Prozesse (32, 34) - Zeiger (38, 45, 63, 64) - Signale (60) - Funktionen, wobei mindestens eine der folgenden Modifikationen beim Ändern durchgeführt wird: - Verschieben mindestens eines Prozessaufrufes in mindestens einen anderen Task (31, 33) - Kopieren (42) mindestens eines Prozessaufrufes in mindestens einen anderen Task (31, 33) - Deaktivieren mindestens eines Prozessaufrufes - Ändern mindestens eines Zeigers (38, 45, 63, 64) auf eine Funktion (Funktionszeiger) - Überschreiben mindestens eines Signals (60).
Das Verfahren (300) nach Anspruch 5, dadurch gekennzeichnet, dass während der Laufzeit mindestens eine der Modifikationen vorgenommen wird.
Das Verfahren (300) nach einem der vorhergehenden Ansprüche 5 bis 6, dadurch gekennzeichnet, dass weitere Fragmente (20) eines Target Builds vorgelegt werden, wobei die Target Builds Merkmale eines echten Steuergeräts umfassen.
Das Verfahren (300) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Prozessstrukturen mindestens eine Liste mit Signal-Modifikationen für den jeweiligen Prozess umfassen.
Das Verfahren (300) nach einem der vorhergehenden Ansprüche, wobei mindestens ein Signal ein internes Signal (60) der vECU ist und wobei die vECU mindestens einen virtuellen Inport aufweist, wobei der mindestens eine virtuelle Inport mindestens einen Wert zur Verfügung stellt, für das Überschreiben des mindestens einen internen Signals (60).
Das Verfahren (300) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine Signalmodifikation mittels der vorher bereitgestellten Datenstruktur vor und nach dem Ausführen eines Prozesses, der auf mindestens ein Signal zugreift, durchgeführt wird, wobei das mindestens eine Signal mit dem mindestens einen Wert des entsprechend zugewiesenen mindestens einen Inports überschrieben wird.
Ein Datenverarbeitungssystem, umfassend Mittel zur Ausführung des Verfahrens (300) nach irgendeinem der Ansprüche 1-10.
Ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren (300) nach irgendeinem der Ansprüche 1-10 auszuführen.
Eine Scheduling-Datenstruktur (30) nach einem der Verfahren (300) gemäß Anspruch 1 bis 10 oder wobei die Scheduling-Datenstruktur eine variable Scheduling-Datenstruktur (30) ist, die mindestens eines der Folgenden umfasst: - Tasks (31, 33) - Prozesse (32, 34) - Zeiger (38, 45, 63, 64) - Signale (60) - Funktionen, wobei bei der variablen Scheduling-Datenstruktur (30) mindestens eine der folgenden Modifikationen gegenüber einer Ausgangs-Scheduling-Datenstruktur durchgeführt ist: - Verschiebung mindestens eines Prozessaufrufes in mindestens einen anderen Task (31, 33) - Kopierung (42) mindestens eines Prozessaufrufes in mindestens einen anderen Task (31, 33) - Deaktivierung mindestens eines Prozessaufrufes - Änderung mindestens eines Zeigers (38, 45, 63, 64) auf eine Funktion (Funktionszeiger) - Überschreibung mindestens eines Signals (60).
Nutzung einer Scheduling-Datenstruktur nach Anspruch 13, eines Computerprogramms nach Anspruch 12, eines Datenverarbeitungssystems nach Anspruch 11 oder eines Verfahrens der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass in einer Simulationsumgebung (100, 200) eines der Folgenden abläuft: - Initiieren (I), - Betreiben (B), - Abschalten (A) eines virtuellen Steuergerätes.