-
Die Erfindung betrifft ein Verfahren zur Fehleranalyse einer von einem eingebetteten System bereitgestellten Funktionalität auf einem Entwicklersystem nach der im Oberbegriff von Anspruch 1 näher definierten Art.
-
Bei einem eingebetteten System handelt es sich um eine elektronische Recheneinheit, welche in einem technischen Kontext eingebunden ist. Die Recheneinheit übernimmt dabei eine Überwachungs-, Steuerungs- und/oder Regelfunktion und/oder wird für eine Datenverarbeitung eingesetzt, beispielsweise das Kodieren und/oder Dekodieren von Daten. Eingebettete Systeme finden sich beispielsweise in Haushaltsgeräten oder auch Fahrzeugen.
-
Die Entwicklung von eingebetteten Systemen, insbesondere der auf einem eingebetteten System zur Bereitstellung einer Funktionalität verwendeten Software geht mit gewissen Hürden einher. So erfordert der Betrieb eingebetteter Systeme oftmals spezielle Hardware, wie beispielsweise Sensoren zum Erzeugen von Sensorsignalen und/oder über Steuerungssignale betätigte Aktoren. Für eine schnelle, effiziente und kostengünstige Entwicklung werden eingebettete Systeme oftmals nicht eins zu eins in der Entwicklungsphase nachgebaut, sondern einzelne hardware- und/oder softwareseitige Teile simuliert. Bei „Model in the Loop“ oder auch als „Software in the Loop“ bezeichnet, wird später von einem eingebetteten System verwendete Software auf einem externen Rechner wie einem PC getestet. Bei „Hardware in the Loop“ hingegen ist die zu testende Software auf der Zielhardware implementiert.
-
Zur Fehlerbeseitigung fehlerhafter oder noch nicht vollständig entwickelter Software werden typischerweise einzelne Codebausteine auf ihre korrekte Funktionalität hin iterativ untersucht. Ein solches Vorgehen ist für eingebettete Systeme aufgrund der von einem solchen eingebetteten System verwendeten begrenzten Ressourcen hinsichtlich Rechenleistung und Speichergröße schwierig. So weisen aktuelle Logging Mechanismen wie das sogenannte „Diagnostic, Log and Trace Protocol“ (DLT) einen vergleichsweise hohen Ressourcenverbrauch auf. Hierdurch kann das eingebettete System zur Bereitstellung einer üblichen Funktionalität einen längeren Zeitraum brauchen, was zu einer Komfortbeeinträchtigung einer das eingebettete System nutzenden Person führt oder auch eine Bereitstellung der Funktionalität verhindert, da die vom eingebetteten System bereitgestellte Funktionalität nicht schnell genug erbracht werden kann. Aus diesen Gründen wird bei eingebetteten Systemen die Ausgabe von Logaufnahmen häufig auf ein Minimum reduziert oder gänzlich eingestellt. Aufgetretene Fehler lassen sich dann nur schlecht oder gar nicht nachvollziehen.
-
Bei einer Entwicklung der von einem eingebetteten System verwendeten Software auf einer externen Recheneinheit besteht zudem bei der Verwendung von Maschinenlernalgorithmen das Problem, dass der auf der externen Recheneinheit ausgeführte Maschinenlernalgorithmus zu anderen Ergebnissen kommen kann, als der auf dem eingebetteten System verwendete Maschinenlernalgorithmus. Dies liegt daran, dass das Verhalten des auf dem eingebetteten System ausgeführten Maschinenlernalgorithmus von dem auf der externen Recheneinheit ausgeführten Maschinenlernalgorithmus, bspw. aufgrund eines unterschiedlichen Trainings, abweicht.
-
Aufgrund der von einem eingebetteten System üblicherweise aufgewiesenen vergleichsweise kleinen Speicher werden Logfiles oftmals auf einem zentralen Server gespeichert, was als Remote-Logging bezeichnet wird. Hierbei entsteht jedoch der Nachteil, dass zum Übertragen der Logfiles an den zentralen Server ein kontinuierlicher, meist vergleichsweise hoher Datenstrom erforderlich ist.
-
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein verbessertes Verfahren zur Fehleranalyse einer von einem eingebetteten System bereitgestellten Funktionalität auf einem Entwicklersystem anzugeben, mit dessen Hilfe ein zusätzlicher Ressourcenverbrauch vermieden werden und umfangreichere Analysemöglichkeiten ermöglicht werden.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren zur Fehleranalyse einer von einem eingebetteten System bereitgestellten Funktionalität auf einem Entwicklersystem mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Ansprüchen.
-
Bei einem Verfahren zur Fehleranalyse einer von einem eingebetteten System bereitgestellten Funktionalität auf einem Entwicklersystem der eingangs genannten Art entspricht das Entwicklersystem einer Nachbildung des eingebetteten Systems auf einer externen, vom eingebetteten System abweichenden Recheneinheit, wobei das eingebettete System zur Bereitstellung der Funktionalität Sensordaten mit Hilfe eines durch Programmcode ausgebildeten Algorithmus zur Bereitstellung von Steuerungsdaten verarbeitet. Erfindungsgemäß werden zumindest die folgenden Verfahrensschritte ausgeführt:
- • Ausleiten von Arbeitsdaten aus dem eingebetteten System, wobei die Arbeitsdaten Parameter zur Festlegung eines Verhaltens eines vom Algorithmus verwendeten oder ausgebildeten Maschinenlernmodells und einer Variantenkodierung zur Konfiguration eines vom Programmcode ausgebildeten Programms umfassen;
- • Ausleiten von Interfacedaten aus dem eingebetteten System, wobei die Interfacedaten Sensordaten und Steuerungsdaten umfassen;
- • Übertragen der Arbeitsdaten und der Interfacedaten an das Entwicklersystem;
- • Entpacken und Aufbereiten der Arbeitsdaten auf dem Entwicklersystem durch einen Software-Wrapper;
- • Konfigurieren eines dem auf dem eingebetteten System ausgeführten Programm entsprechenden Programms auf dem Entwicklersystem unter Verwendung der Variantencodierung und der Steuerungsdaten;
- • Initialisieren eines auf dem Entwicklersystem ausgeführten Maschinenlernmodells unter Verwendung der Parameter;
- • Starten des auf dem Entwicklersystem ausgeführten Programms an einem definierten Arbeitspunkt und fortlaufendes Einlesen relevanter Interfacedaten; und
- • Untersuchen und bei Bedarf Überarbeiten eines Verhaltens des Programms unter Einsatz von Entwickler-Werkzeugen.
-
Mit Hilfe des erfindungsgemäßen Verfahrens lässt sich ein Ressourcenmehrverbrauch auf dem eingebetteten System zum Nachvollziehen von Fehlern vermindern oder gar verhindern, da rechenaufwändige Operationen auf der externen Recheneinheit durchgeführt werden. Durch den Einsatz von Entwickler-Werkzeugen wie ein Debugger oder einer Breakpoint Analyse sowie den Einsatz unterschiedlichster Softwareentwicklungsprogrammen wird zudem eine verbesserte Analysemöglichkeit zur Fehleranalyse der vom eingebetteten System bereitgestellten Funktionalität geboten.
-
Die aus dem eingebetteten System ausgeleiteten Arbeitsdaten und Interfacedaten lassen sich auf vielfältige Art und Weise an die externe Recheneinheit versenden. Das Versenden der Arbeitsdaten und Interfacedaten kann beispielsweise kabelgebunden oder drahtlos erfolgen. Zur kabelgebundenen Übertragung an die externe Recheneinheit kann beispielsweise eine Ethernetverbindung verwendet werden. Eine drahtlose Datenübertragung kann beispielsweise über Mobilfunk, WiFi, Bluetooth oder dergleichen erfolgen. Die Arbeitsdaten und die Interfacedaten können somit von der externen Recheneinheit beispielsweise live, also während des Betriebs des eingebetteten Systems, gelesen werden.
-
Bevorzugt werden die Arbeitsdaten und die Interfacedaten während eines Betriebs des eingebetteten Systems fortlaufend auf einem Speicher des eingebetteten Systems und/oder einem externen Speicher gespeichert. Das Speichern der Arbeitsdaten und der Interfacedaten erlaubt auch eine Fehleranalyse zu einem späteren Zeitpunkt. Zur Übertragung der Arbeitsdaten und der Interfacedaten vom eingebetteten System an die externe Recheneinheit können dann die im Speicher des eingebetteten Systems abgespeicherten Arbeitsdaten und Interfacedaten auf ein tragbares Speichermedium wie beispielsweise eine SD-Karte oder einen USB Stick zwischengespeichert werden und von diesem Speichermedium von der externen Recheneinheit gelesen werden.
-
Das Ausleiten der Arbeitsdaten und der Interfacedaten lässt sich also als Abspeichern auf dem eingebetteten System und/oder Übertragen an die externe Recheneinheit und das dortige Abspeichern und/oder direkte Verarbeiten der Arbeitsdaten und Interfacedaten verstehen.
-
Mit Hilfe des Software-Wrappers wird eine Replay Funktionalität bereitgestellt. Somit lässt sich der Programmcode bzw. einzelne Programmcodeabschnitte auf der externen Recheneinheit mehrmals ausführen, was eine iterative Anpassung des Programmcodes zur Fehleranalyse und/oder Beseitigung ermöglicht.
-
Mit Hilfe der Arbeitsdaten ist eine originalgetreue Nachbildung des auf dem eingebetteten System ausgeführten Algorithmus bzw. Programms auf der externen Recheneinheit möglich. Unter Verwendung der Interfacedaten lässt sich somit das Verhalten des eingebetteten Systems auf dem Entwicklersystem analog, sprich eins zu eins nachvollziehen. Auf dem Entwicklersystem wird dann ein hohes Loglevel verwendet, wodurch umfangreiche Logs bzw. Crashdumps im Falle des Auftretens eines Fehlers erzeugt werden. Dies ermöglicht eine besonders umfangreiche Fehleranalyse.
-
Entsprechend einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens werden die Arbeitsdaten in Form von Arbeitsdatenblöcken periodisch mit einer festgelegten Periodendauer ausgeleitet und die Interfacedaten vollständig für alle vorhandenen, die Sensordaten erzeugenden Sensoren und die steuerungsdatenverarbeitenden Aktoren zumindest beim Ausleiten des ersten Arbeitsdatenblocks ausgeleitet und mit fortschreitender Periodendauer ebenfalls vollständig oder zumindest nach Änderung eines Werts zumindest einer Sensordatei und/oder einer Steuerungsdatei wenigstens die geänderte Sensordatei und/oder Steuerungsdatei ausgeleitet. Durch das fortlaufende Ausleiten der Arbeitsdaten und der Interfacedaten während des Betriebs des eingebetteten Systems lassen sich potentielle Fehler vollständig nachvollziehen. Dabei reicht es aus, die Arbeitsdaten und die Interfacedaten initial beim Starten des eingebetteten Systems, also bei Beginn der Betriebsdauer vollständig auszuleiten und dann je nach Bedarf, insbesondere wenn sich beispielsweise ein Parameter, ein Sensorwert oder ein Steuerungsbefehl ändert, auszuleiten. Während der Fehleranalyse auf dem Entwicklersystem ist hierdurch eine eindeutige Zuordnung der zu einem bestimmten Zeitpunkt ausgeleiteten Interfacedaten zu dem jeweiligen Zeitpunkt geltenden Arbeitsdaten möglich.
-
Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass ein vom ersten Arbeitsdatenblock abweichende Arbeitsdatenblock nur dann Parameter umfasst, wenn wenigstens ein Parameter verändert wurde, wobei nur geänderte Parameter in den vom ersten Arbeitsdatenblock abweichenden Arbeitsdatenblock integriert werden. Hierdurch lässt sich ein Speicherbedarf zum Abspeichern der Arbeitsdaten bzw. eine zum Übertragen der Arbeitsdaten an eine externe Recheneinheit erforderliche Bandbreite reduzieren.
-
Entsprechend einer weiteren vorteilhaften Ausgestaltung des Verfahrens entspricht die Periodendauer einem Wert zwischen 3 bis 5 Minuten. Die Periodendauer ist abhängig von einer Speichergröße des Speichers des eingebetteten Systems, sowie einer Größe eines im Fehlerfall erzeugten Crashdumps. Je größer der Speicher des eingebetteten Systems ausfällt, desto größere Crashdump Files lassen sich auch abspeichern. Somit kann eine längere Periodendauer gewählt werden, da mit zunehmender Zeit mehr Daten in den Crashdump geschrieben werden, und das Crashdump File somit anwächst. Dabei hat sich bei typischen von eingebetteten Systemen verwendeten Speichern eine Periodendauer von 3 bis 5 Minuten zu Ausbildung eines nicht zu großen Crashdump Files bewährt.
-
Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass die Arbeitsdaten nur dann ausgeleitet werden, wenn das Maschinenlernmodell in einer von einer Lernphase abweichenden Arbeitsphase läuft. Hierdurch wird vermieden, dass während einer Lernphase des Maschinenlernmodells Parameter zur Festlegung des Verhaltens des Maschinenlernmodells gespeichert werden. Hierdurch lässt sich das Auftreten einer Inkonsistenz zwischen einer aktuellen Aufnahme eines Verhaltens des eingebetteten Systems und dessen zeitversetzte Wiedergabe auf dem Entwicklersystem vermeiden. Alternativ ist auch eine zeitversetzte Speicherung der Interfacedaten denkbar.
-
Entsprechend einer weiteren vorteilhaften Ausgestaltung des Verfahrens werden die Interfacedaten vor dem Ausleiten gefiltert und/oder komprimiert. Durch das Komprimieren der Interfacedaten lässt sich ein zum Ausleiten bzw. Speichern der Interfacedaten erforderlicher Speicheraufwand bzw. eine zur Übertragung der Interfacedaten erforderliche Bandbreite reduzieren. Durch das Filtern der Interfacedaten wird gewährleistet, dass nur relevante Interfacedaten erfasst werden. Hierdurch lässt sich der zum Ausleiten erforderliche Ressourcenaufwand noch weiter reduzieren. Datensätze, die nicht verarbeitet werden, müssen auch nicht abgespeichert werden. Handelt es sich bei einem Sensor beispielsweise um eine Einrichtung zur Eingabe von Bedienhandlungen und wird diese nicht betätigt, so ist es auch nicht erforderlich, ein Sensorsignal dieses Sensors zu speichern.
-
Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass die Arbeitsdaten eine Variantenkodierung vollständig umfassen oder die Arbeitsdaten einen für eine bestimmte Variantenkodierung charakteristischen Primärschlüssel umfassen und das Entwicklersystem zum Einlesen der Variantenkodierung eine den Primärschlüssel zugeordnete Variantenkodierung aus einer Datenbank ausliest. Dabei kann die Datenbank vom Entwicklersystem umfasst sein oder das Entwicklersystem kann auf die Datenbank über ein Netzwerk, beispielsweise über das Internet, Zugriff haben. Durch Verwenden eines Primärschlüssels lässt sich eine Datenmenge zum Übertragen einer Variantenkodierung an das Entwicklersystem reduzieren. Dabei umfasst die Datenbank, bzw. referenziert ein entsprechender Primärschlüssel vorzugsweise eine besonders häufig eingesetzte Variantenkodierung. Eine solche, häufige Variantenkodierung kann beispielsweise eine offizielle Variantenkodierung sein. Eine weniger häufige bzw. seltene Variantenkodierung, beispielsweise eine inoffizielle Variantenkodierung, kann dann direkt in den Arbeitsdaten enthalten sein, was die Arbeitsdaten vergrößert, jedoch garantiert, dass eine tatsächlich vom eingebetteten System verwendete Variantenkodierung auch so eins zu eins auf dem Entwicklersystem verwendet wird. Beispielsweise lässt sich eine selten benutzte Variantenkodierung in den Arbeitsdaten durch Verifikation einer sogenannten Check-Summe bzw. Prüfsumme eingliedern.
-
Entsprechend einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens handelt es sich bei der vom eingebetteten System bereitgestellten Funktionalität um eine Gestenerkennung.
-
Bevorzugt wird die Gestenerkennung innerhalb eines Fahrzeugs durchgeführt, wodurch insbesondere über wenigstens ein an einem Lenkrad und/oder einer Mittelkonsole vorgesehenes Sensorelement eingegebene Bedienhandlungen erkannt werden. Mit Hilfe einer solchen Gestenerkennung wird eine besonders komfortable Steuerung von Fahrzeugfunktionen, beispielsweise das Bedienen eines Infotainmentsystems eines Fahrzeugs gewährleistet. Zudem wird eine besonders positive Nutzererfahrung generiert, da das Steuern von Fahrzeugfunktionen mit Hilfe von Gesten ungewöhnlich, und damit futuristisch ist. Bei dem Sensorelement kann es sich beispielsweise um ein berührempfindliches Feld, einen Lidarsensor, einen Radarsensor, eine Kamera oder dergleichen handeln.
-
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich auch aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben werden.
-
Dabei zeigen:
- 1 eine schematische Darstellung einer Entwicklerumgebung zur Durchführung eines erfindungsgemäßen Verfahrens;
- 2 eine Prinzipdarstellung einer fortlaufenden Speicherung von Arbeitsdaten und Interfacedaten; und
- 3 ein Ablaufdiagramm des erfindungsgemäßen Verfahrens.
-
1 zeigt ein eingebettetes System 1 und ein Entwicklersystem 2. Auf dem eingebetteten System 1 wird ein Programm 6 ausgeführt, welches Sensordaten 4.1 von Sensoren 9 empfängt und daraus unter Verwendung eines Algorithmus 5 Steuerungsdaten 4.2 zum Ansprechen von Aktoren 10 berechnet. Der Algorithmus 5 verwendet oder wird ausgebildet von einem Maschinenlernmodell. Das Empfangen der Sensordaten 4.1 von den Sensoren 9 und das Versenden der Steuerungsdaten 4.2 an die Aktoren 10 erfolgt vom Programm 6 über ein Interface 12. Das Programm 6 hat Zugriff auf einen Radom Access Memory (RAM) 13, auf dem Parameter 3.1 und eine Variantenkodierung 3.2 gespeichert sind. Die Parameter 3.1 dienen zur Festlegung eines Verhaltens des vom Algorithmus 5 verwendeten oder ausgebildeten Maschinenlernmodells. Die Variantenkodierung 3.2 dient zur Konfiguration des Programms 6.
-
Zur effizienteren und komfortableren sowie umfassenderen Fehleranalyse einer vom eingebetteten System 1 bereitgestellten Funktionalität und einer Entwicklung des Programms 6 werden die Parameter 3.1 und die Variantenkodierung 3.2, zusammengefasst als Arbeitsdaten 3, sowie die Sensordaten 4.1 und die Steuerungsdaten 4.2, zusammengefasst als Interfacedaten 4, an das Entwicklersystem 2 übertragen. Das Übertragen der Arbeitsdaten 3 und der Interfacedaten 4 vom eingebetteten System 1 an das Entwicklersystem 2 erfolgt beispielsweise kabelgebunden, drahtlos oder durch Auslesen eines tragbaren Speichermediums. Die Arbeitsdaten 3 und die Interfacedaten 4 können zusammengefasst als eine Datei oder auch unterteilt in eine Vielzahl Dateien übertragen werden.
-
Das Entwicklersystem 2 verfügt über einen Software-Wrapper 7, der die Arbeitsdaten 3 und die Interfacedaten 4 entsprechend eines erwünschten zu betrachtenden Arbeitspunkts des auf dem eingebetteten Systems 1 ausgeführten Programms 6, an ein eben diesem Programm 6 entsprechendes, auf dem Entwicklersystem 2 ausgeführtes Programm 6 übergibt. Zur Nachbildung des auf dem Entwicklersystem 2 ausgeführten Programms 6 entsprechend dem auf dem eingebetteten System 1 ausgeführten Programms 6, wird das auf dem Entwicklersystem 2 ausgeführte Programm 6 mit Hilfe der Variantenkodierung 3.2 und der Steuerungsdaten 4.2 konfiguriert. Das auf dem Entwicklersystem 2 ausgeführte Programm 6 verfügt ebenfalls über einen RAM 13, ein Interface 12 sowie einen Algorithmus 5. Um das Verhalten des auf dem Entwicklersystem 2 ausgeführten Algorithmus 5 an das Verhalten des auf dem eingebetteten System 1 ausgeführten Algorithmus 5 anzupassen, wird der auf dem Entwicklersystem 2 ausgeführte Algorithmus 5 mit Hilfe der Parameter 3.1 initialisiert.
-
Dabei werden aus den Arbeitsdaten 3 und den Interfacedaten 4 vom Software-Wrapper 7 dem zu betrachtenden Arbeitspunkt entsprechende Parameter 3.1, Variantenkodierungen 3.2, Sensordaten 4.1 und/oder Steuerungsdaten 4.2 an das Programm 6 übergeben. Hierdurch wird eine Replay Funktionalität bereitgestellt, zu der sich eine beliebige Situation bzw. ein Verhalten des eingebetteten Systems 1 zu einem beliebigen Zeitpunkt, an dem das eingebettete System 1 betrieben wurden, nachstellen lässt.
-
Dabei ist ein sogenanntes Log Level des auf dem Entwicklersystem 2 ausgeführten Programms 6 vergleichsweise hoch, so dass umfassende Logs bzw. Crashdump Files erzeugbar sind. Diese werden dann mit Hilfe von Entwickler-Werkzeugen 8, beispielsweise einem Logger 8.1, einem Debugger 8.2, einem Logicanalyzer 8.3 oder dergleichen ausgewertet bzw. bearbeitet.
-
Dies erlaubt es ein Verhalten des Programms 6 in verschiedenen Situationen zu untersuchen und bei Bedarf anzupassen, so dass möglichst wenige Fehler während eines Betriebs des Programms 6 zum Bereitstellen der Funktionalität des eingebetteten Systems 1 auftreten.
-
Zur Reduktion einer Datenmenge kann die Variantenkodierung 3.2 in den Arbeitsdaten 3 auch indirekt durch Kodierung mit Hilfe eines Primärschlüssels gespeichert werden. Dabei weist der Primärschlüssel eine gegenüber der direkten Variantenkodierung 3.2 geringeren Speicherbedarf auf. Das Entwicklersystem 2 greift auf eine interne oder externe Datenbank 11 zu, in welcher eine einem entsprechenden Primärschlüssel zugeordnete Variantenkodierung 3.2 abgespeichert ist.
-
2 zeigt ein Ausleitverhalten des eingebetteten Systems 1 über eine Betriebsdauer t des eingebetteten Systems 1 zum Ausleiten der Arbeitsdaten 3 und der Interfacedaten 4.
-
Dabei meint Ausleiten das Abspeichern und/oder Übertragen der Arbeitsdaten 3 und der Interfacedaten 4 in einen Speicher bzw. an das Entwicklersystem 2.
-
Die Betriebsdauer t startet zu einem Startzeitpunkt t0. Zum Startzeitpunkt t0 werden die vollständigen Arbeitsdaten 3 in Form eines ersten Arbeitsdatenblocks 3.3.0 ausgeleitete. Zum Startzeitpunkt to, bzw. nach Ausleiten des ersten Arbeitsdatenblocks 3.3.0 werden außerdem die Interfacedaten 4 für alle Sensoren 9 und Aktoren 10 ausgeleitet. Dabei können wie in 2 dargestellt, die Interfacedaten 4 zu einem unterschiedlichen Zeitpunkt wie die Arbeitsdaten 3 ausgeleitet werden. Generell ist es jedoch auch möglich, dass die Arbeitsdaten 3 und die Interfacedaten 4 gleichzeitig ausgeleitet werden.
-
Mit fortschreitender Zeit werden die Interfacedaten 4 fortlaufend ausgeleitet. Dabei können auch nur dann Sensordaten 4.1 und/oder Steuerungsdaten 4.2 ausgeleitet werden, wenn ein entsprechender Sensor 9 einen sich ändernden Wert misst oder an einen Aktor 10 ein geändertes Steuerungssignal übermittelt wird. Die Arbeitsdaten 3 werden periodisch mit einer Periodendauer Δt ausgeleitet. Dabei wird das Ausleiten der Arbeitsdaten 3 solange verzögert, bis der Algorithmus 5 oder das ausgebildete Maschinenlernmodell in keiner Lernphase mehr ist, oder sich die Interfacedaten 4 eindeutig zur Lernphase zuordnen lassen. Damit ist ein Verkürzen oder Verlängern der Periodendauer Δt möglich. Zum Nachstellen einer auf dem eingebetteten System 1 erfolgten Situation auf dem Entwicklersystem 2 ist es dabei erforderlich, dass eine eindeutige Zuordnung zwischen den in Arbeitsdatenblöcken 3.3 gespeicherten bzw. ausgeleiteten Arbeitsdaten 3 und entsprechenden Interfacedaten 4 möglich ist.
-
Um eine solche Situation darzustellen, ist eine Mindestzeitaufnahme 14 erforderlich, welche mit einem Vorlauf 15 aufgezeichnet wurde. Eine entsprechende Mindestzeitaufnahme 14 umfasst mindestens initiale Arbeitsdaten i3, initiale Steuerungsdaten i4.2, sowie Sensordaten 4.1 zumindest bei einem sich änderndem Sensorwert.
-
Handelt es sich bei der betrachteten Mindestzeitaufnahme 14 nicht um den ersten Arbeitsdatenblock 3.3.0, sondern um einen beliebigen, auf diesen folgenden Arbeitsdatenblock 3.3, so können die initialen Arbeitsdaten i3 und die initialen Steuerungsdaten i4.2 auch aus einer Historie ausgehend von den im ersten Arbeitsdatenblock 3.3.0 enthaltenen Arbeitsdaten 3 und dazu passenden Steuerungsdaten 4.2 und sich ändernden Größen über die Betriebsdauer t nachgebildet werden.
-
3 verdeutlicht einen Ablauf des erfindungsgemäßen Verfahrens.
-
In einem Verfahrensschritt 301 werden die Arbeitsdaten 3 aus dem eingebetteten System 1 ausgeleitet. Im Verfahrensschritt 302 werden die Interfacedaten 4 ausgeleitet.
-
Im Verfahrensschritt 303 werden die Interfacedaten 4 gefiltert und/oder komprimiert.
-
Im Verfahrensschritt 304 werden die Arbeitsdaten 3 und die Interfacedaten 4 vom eingebetteten System 1 an das Entwicklersystem 2 übertragen.
-
Im Verfahrensschritt 305 werden die Arbeitsdaten 3 mit Hilfe eines Software-Wrappers 7 entpackt und aufbereitet.
-
Im Verfahrensschritt 306 wird ein dem auf dem eingebetteten System 1 ausgeführten Programm 6 entsprechendes Programm 6 auf dem Entwicklersystem 2 mit Hilfe der Variantenkodierung 3.2 und der Steuerungsdaten 4.2 konfiguriert.
-
Im Verfahrensschritt 307 wird ein die Funktionalität des eingebetteten Systems 1 nachbildender Algorithmus 5 auf dem Entwicklersystem 2 mit Hilfe der Parameter 3.1 initialisiert. Hierdurch wird sichergestellt, dass das Verhalten des auf dem Entwicklersystem 2 ausgeführten Algorithmus 5 dem Verhalten des auf dem eingebetteten Systems 1 ausgeführten Algorithmus 5 entspricht.
-
Im Verfahrensschritt 308 wird das Programm 6 auf dem Entwicklersystem 2 ausgeführt. Dabei werden in zeitlicher Abfolge korrekt hintereinander ausgeleitete Interfacedaten 4 vom Programm 6 eingelesen.
-
Im Verfahrensschritt 309 wird das Programm 6 bzw. einzelne Programmcodebausteine des Programms 6 untersucht und/oder überarbeitet, indem die Programmausführung des Programms 6 iterativ, also mehrmals, erfolgt.
