Titel

Steuergerät und Betriebsverfahren hierfür Stand der Technik

Die Erfindung betrifft ein Steuergerät, insbesondere für ein Kraftfahrzeug, mit einer Recheneinheit zur Ausführung von Software, einer der Recheneinheit zugeordneten Speichereinheit, einer in der Speichereinheit gespeicherten ersten Software zur zumindest zeitweisen Sammlung von Informationen über einen

Betrieb des Steuergeräts und/oder damit verbundener Komponenten, und mit einer Datenschnittstelle zum Austausch von Daten mit wenigstens einer externen Einheit. Die Erfindung betrifft ferner ein Verfahren zum Betreiben eines derartigen

Steuergeräts.

Die Erfindung betrifft weiter eine Vorrichtung zur Verarbeitung von Daten sowie ein Verfahren zum Betreiben einer derartigen Vorrichtung.

Steuergeräte der eingangs genannten Art sind bekannt und werden

beispielsweise in elektronischen bzw. mechatronischen Systemen von

Kraftfahrzeugen verwendet. Die gespeicherte erste Software dient dabei beispielsweise zur Ausführung von Diagnosefunktionen, um Fehler wie beispielsweise Komponentenfehler zu finden und zu klassifizieren. Herkömmliche

Diagnosefunktionen sind in der Erstellung und im Betrieb ressourcenaufwendig, andererseits jedoch unerlässlich um die genannten Fehler erkennen. Allerdings reichen die heute gängigen Diagnosefunktionen angesichts der stetig steigenden Mächtigkeit und Komplexität mechatronischer Systeme nicht in allen Fällen aus, zuverlässig die oben genannten Fehler entdecken. Insbesondere der wachsenden Anzahl von sogenannten root-cause-Fehlerbildern kann mit den bekannten Diagnosefunktionen nicht begegnet werden.

Besonders nachteilig ist zum einen die wachsende Anzahl von

Diagnosefunktionen, die zur umfassenden Fehlerdetektion bei den Zielsystemen für die eingangs genannten Steuergeräte erforderlich ist. Zum anderen ist auch die steigende Komplexität der erforderlichen Diagnosefunktionen selbst nachteilig, weil hierdurch ein stark ansteigender Aufwand für das Erstellen und testen der Diagnosefunktionen bedingt wird. Zudem häufen sich dadurch auch sogenannte sekundäre Fehler. So stellen insbesondere in modernen

Kraftfahrzeugen fälschlicherweise reagierende Diagnosefunktionen einen signifikanten Anteil der anschlagenden Diagnosen (Fehlapplikation) dar.

Offenbarung der Erfindung

Demgemäß ist es Aufgabe der vorliegenden Erfindung, ein Steuergerät und ein Betriebsverfahren der eingangs genannten Art dahingehend zu verbessern, dass eine gesteigerte Flexibilität und gleichzeitig eine verbesserte Zuverlässigkeit bei der Erkennung von Fehlern erreicht wird.

Diese Aufgabe wird bei dem Steuergerät der eingangs genannten Art

erfindungsgemäß dadurch gelöst, dass das Steuergerät dazu ausgebildet ist, wenigstens eine zweite Software, die von der ersten Software verschieden ist, über die Datenschnittstelle von der externen Einheit zu laden und mittels der Recheneinheit auszuführen. Dadurch ist vorteilhaft die Möglichkeit gegeben, beispielsweise bedarfsweise das Steuergerät mit einer gegenüber der ersten Software spezialisierteren Software zu versorgen, die beispielsweise eine spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts und/oder damit verbundener Komponenten ermöglicht. Besonders vorteilhaft kann durch das erfindungsgemäße Laden dieser zweiten Software im

Bedarfsfalle die Ausstattung von Steuergeräten, beispielsweise bei deren Herstellung, bereits mit einer gegebenenfalls vergleichsweise umfangreichen zweiten Software entfallen, sodass entsprechende Ressourcen (Speicher, Rechenzeit) in dem Steuergerät nur dann für die Vorhaltung bzw. Ausführung der zweiten Software belegt werden, wenn diese tatsächlich benötigt wird. Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die erste Software bei der Ausführung durch die Recheneinheit eine Diagnose wenigstens einer Funktion des Steuergeräts selbst und/oder eine Diagnose wenigstens einer weiteren mit dem Steuergerät verbundenen Komponente ermöglicht, wodurch ein erstes Diagnoseergebnis erhalten wird. Mithin kann es sich bei der ersten Software um eine Software handeln, welche ein oder mehrere

Diagnosefunktionen ausführt. Beispielsweise kann die erste Software einen vorgebbaren Satz von minimal-Diagnosefunktionen enthalten, welche zum Beispiel erforderlich sind, um System-Auswirkungen von möglichen Fehlern zu erkennen. Mit dieser ersten Software kann das erfindungsgemäße Steuergerät beispielsweise zum Zeitpunkt seiner Produktion versehen werden, beispielsweise durch einen an sich bekannten Programmiervorgang.

Generell können die vorstehend genannten Informationen über den Betrieb des Steuergeräts bzw. die Informationen über den Betrieb von mit dem Steuergerät verbundenen Komponenten alle durch das Steuergerät erfassbaren Größen des Steuergeräts oder der genannten Komponenten oder beliebige Kombinationen hieraus umfassen, insbesondere auch Sensor-Messwerte, Daten von mit dem Steuergerät assoziierten Kommunikationsschnittstellen, und dergleichen.

Beispielsweise kann das Steuergerät bei manchen Ausführungsformen die Informationen über den Betrieb von mit dem Steuergerät verbundenen

Komponenten über eine entsprechende Kommunikationsschnittstelle (CAN-Bus, LIN-Bus, FlexRay-Bus, andere Kommunikationsschnittstellentypen) erhalten, über die das Steuergerät mit den betreffenden Komponenten verbunden ist. Beispielsweise können solche Informationen auch Teile von mittels des

Steuergeräts empfangenen CAN-Botschaften enthalten und dergleichen.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät dazu ausgebildet ist, mittels der ersten Software gesammelte Informationen, insbesondere das mittels der ersten Software erhaltene erste Diagnoseergebnis, an die wenigstens eine externe Einheit zu senden. Dadurch kann die Auswertung des Diagnoseergebnisses vorteilhaft außerhalb des Steuergeräts erfolgen und beispielsweise mittels einer leistungsfähigen

Vorrichtung zur Datenverarbeitung ausgeführt werden, beispielsweise durch ein zentrales Serversystem, ein verteiltes Rechnersystem (cloud), oder dergleichen. Insbesondere können die Diagnoseergebnisse bei manchen Ausführungsformen auch vorteilhaft einem System zur Verfügung gestellt werden, welches ein sogenanntes virtuelles Fahrzeug repräsentiert, also eine digitale Repräsentation einer Mehrheit oder Gesamtheit von in einem tatsächlich vorhandenen Fahrzeug angeordneten Steuergeräten bzw. deren Betriebsparameter.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software dazu ausgebildet ist, eine gegenüber der ersten Software spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts und/oder damit verbundener Komponenten auszuführen. Damit kann die Diagnosefunktionalität über die von der ersten Software gegebenen Möglichkeiten sinnvoll erweitert werden, insbesondere individuell angepasst an gegebenenfalls vorhandene Fehlerbilder bzw. Probleme, was durch die Auswertung der Informationen über den Betrieb des Steuergeräts bzw. der betreffenden Komponenten ermöglicht ist.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software eine oder mehrere, insbesondere direkt durch die Recheneinheit ausführbare, Diagnosefunktionen umfasst, die in Abhängigkeit des ersten Diagnoseergebnisses erhalten bzw. programmiert worden sind. Dadurch kann die Recheneinheit direkt die beispielsweise spezifischeren Diagnosefunktionen der zweiten Software nutzen. Besonders bevorzugt wird die zweite Software der Recheneinheit direkt in Form eines ausführbaren Computerprogramms zur Verfügung gestellt, welches beispielsweise zumindest zeitweise in dem

Steuergerät zwischengespeichert werden kann, insbesondere in einem Flash- Speicher oder auch einem Arbeitsspeicher des Steuergeräts, wo es zur

Ausführung durch die Recheneinheit zur Verfügung steht.

Bei einer weiteren bevorzugten Ausführungsform kann der Schritt des Ladens der zweiten Software und/oder der Schritt des Ausführens der zweiten Software während des Betriebs des Steuergeräts bzw. der Recheneinheit erfolgen.

Insbesondere kann vorgesehen sein, dass die Recheneinheit zur Ausführung der erfindungsgemäßen Schritte des Ladens und Ausführens vorteilhaft nicht in einen speziellen Programmierzustand versetzt werden muss, wie er

beispielsweise bei Firmware-Upgrades erforderlich ist, die eine komplette Neuprogrammierung des gesamten Speichers des Steuergeräts erfordern.

Dadurch kann die zweite Software bedarfsweise dynamisch in dem Steuergerät zum Einsatz kommen und zur Erkennung bzw. Klassifizierung von Fehlern beitragen.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät dazu ausgebildet ist, die zweite Software in Abhängigkeit von wenigstens einem Ereignis zu laden, wobei das wenigstens eine Ereignis von der zumindest zeitweisen Sammlung von Informationen abhängt und/oder von wenigstens einer externen Anfrage an das Steuergerät. Mit anderen Worten kann bei manchen Ausführungsformen vorgesehen sein, dass in Abhängigkeit der Sammlung von Informationen durch die erste Software das Laden der zweiten

Software ausgelöst wird. Bei anderen Ausführungsformen kann alternativ oder ergänzend vorgesehen sein, dass das Laden der zweiten Software durch die externe Anfrage an das Steuergerät ausgelöst wird. Dies kann beispielsweise dann zweckmäßig sein, wenn sich geänderte Betriebsbedingungen für das Steuergerät ergeben, die gegebenenfalls eine Veränderung der Ausführung der ersten Software bzw. eine Ergänzung durch die zweite Software erforderlich machen.

Einer weiteren vorteilhaften Ausführungsform zufolge ist also vorgesehen, dass externe Ereignisse das Laden bzw. Nachladen der zweiten Software wie beispielsweise einer zusätzlichen Diagnosefunktion anstoßen bzw. auslösen. Mögliche Ereignisse sind beispielsweise: neu auftretende Fehler anderer gleichartiger oder verschiedenartiger Steuergeräte, insbesondere eine neu auftretende Security-Problematik, die Verbringung des Steuergeräts bzw. eines das Steuergerät enthaltenden Zielsystems (zum Beispiel Kraftfahrzeug) in einen regional anderen Markt mit gegebenenfalls anderen gesetzlich geforderten Diagnosefunktionen, ein geänderter gesellschaftlich geforderter Stand der Technik insbesondere bezüglich der Funktionalität der ersten und/oder zweiten Software, ein externer Anlass zur Untersuchung eines Abnutzungsbildes bzw. Korrosionsbildes bzw. sonstiger Zustände des Steuergeräts bzw. hiermit verbundener Komponenten, beispielsweise veranlasst durch Maßnahmen zur Qualitätssicherung, eine, insbesondere gesellschaftlich gewünschte,

Veränderung, insbesondere Einengung, von Toleranzen in Diagnosefunktionen (beispielsweise Abgas, Objekterkennung), das Testen von Bauteilhypothesen im Feld für Entwicklungs- bzw. Weiterentwicklungsprozesse betreffend das Steuergerät, eine Validierung von Funktionen im Feld mit Bestimmung einer sogenannten„threshold consumption".

Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung ist ein

Verfahren gemäß Patentanspruch 7 angegeben.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft eine Vorrichtung zur Verarbeitung von Daten gemäß Patentanspruch 8. Die Vorrichtung ist dazu ausgebildet, von einem Steuergerät, insbesondere von einem

erfindungsgemäßen Steuergerät, Informationen über einen Betrieb des

Steuergeräts und/oder damit verbundener Komponenten zu empfangen und in Abhängigkeit von diesen Informationen eine spezifische Diagnosesoftware für das Steuergerät zu erstellen und an das Steuergerät zu übertragen. Die erfindungsgemäße Vorrichtung ermöglicht vorteilhaft die effiziente Ausstattung von Steuergeräten, beispielsweise erfindungsgemäßen Steuergeräten, insbesondere für Kraftfahrzeuge, mit einer spezifischen Diagnosefunktionalität im Rahmen der vorstehend bereits beschriebenen erfindungsgemäßen zweiten Software.

Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die Vorrichtung dazu ausgebildet ist, die Informationen über den Betrieb des Steuergeräts auszuwerten, um wenigstens ein Fehlerbild hieraus abzuleiten, die spezifische Diagnosesoftware auf das wenigstens eine Fehlerbild hin zu optimieren. Diese spezifische Diagnosesoftware kann dann als die vorstehend bereits

beschriebene zweite Software an das erfindungsgemäße Steuergerät gesendet bzw. von dem Steuergerät geladen und sodann bei Bedarf ausgeführt werden.

Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung ist ein

Betriebsverfahren für eine Vorrichtung gemäß Patentanspruch 10 angegeben.

Nachfolgend werden beispielhafte Ausführungsformen der Erfindung unter Bezugnahme auf die Zeichnung erläutert. In der Zeichnung zeigt:

Figur 1 schematisch ein Blockdiagramm einer Ausführungsform eines

erfindungsgemäßen Steuergeräts, Figur 2 schematisch ein vereinfachtes Flussdiagramm einer Ausführungsform eines erfindungsgemäßen Betriebsverfahrens für ein Steuergerät,

Figur 3 schematisch ein vereinfachtes Flussdiagramm einer weiteren

Ausführungsform des erfindungsgemäßen Betriebsverfahrens, und

Figur 4 schematisch ein Betriebsszenario gemäß einer Ausführungsform.

Figur 1 zeigt schematisch ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen Steuergeräts 100. Beispielsweise kann es sich bei dem

Steuergerät 100 um ein Steuergerät für ein Kraftfahrzeug (nicht gezeigt) handeln, zum Beispiel zur Steuerung einer Brennkraftmaschine des Kraftfahrzeugs. Das Steuergerät weist eine Recheneinheit 1 10 auf, bei der es sich beispielsweise um wenigstens einen Mikrocontroller und/oder Mikroprozessor und/oder digitalen Signalprozessor (DSP) und/oder einen anwendungsspezifischen integrierten

Schaltkreis (ASIC) und/oder einen programmierbaren Logikbaustein (FPGA) oder dergleichen handeln kann.

Der Recheneinheit 1 10 ist eine Speichereinheit 120 zugeordnet, die wenigstens einen Arbeitsspeicher (Direktzugriffsspeicher, RAM, Random Access Memory), insbesondere vom SRAM-Typ und/oder vom DRAM-Typ, und/oder wenigstens einen nichtflüchtigen Speicher (non-volatile RAM (NVRAM)), aufweisen kann, z.B. einen Flash-EPROM. In der Speichereinheit 120 ist eine erste Software 131 gespeichert, die zur zumindest zeitweisen Sammlung von Informationen über einen Betrieb des Steuergeräts 100 vorgesehen ist. Alternativ oder ergänzend kann die erste Software 131 bei weiteren Ausführungsformen auch dazu vorgesehen sein, zumindest zeitweise Informationen über einen Betrieb einer mit dem Steuergerät 100 verbundenen Komponente 200 zu sammeln. Bei der Komponente 200 kann es sich beispielsweise um ein anderes Steuergerät oder eine sonstige

Vorrichtung handeln, die mit dem Steuergerät 100 in Datenverbindung steht. Beispielsweise können beide Vorrichtungen 100, 200 an einen gemeinsamen Datenbus, beispielsweise einen CAN-Bus, angeschlossen sein. Ein

entsprechender Datenbus ist in Figur 1 beispielhaft durch den Blockpfeil P1 angedeutet. Das Steuergerät 100 weist ferner eine Datenschnittstelle 140 zum Austausch von Daten mit wenigstens einer externen Einheit 300 auf. Bei der externen Einheit 300 kann es sich beispielsweise um ein entfernt angeordnetes Serversystem handeln, das zum Austausch von Daten mit dem Steuergerät 100 ausgebildet ist. Besonders bevorzugt handelt es sich bei manchen Ausführungsformen bei der

Datenschnittstelle 140 um eine zumindest abschnittsweise drahtlose bzw.

funkbasierte Datenschnittstelle. Hierzu können an sich bekannte Technologien zur drahtlosen Kommunikation wie beispielsweise zelluläre Mobilfunknetze, drahtlose Netzwerke (WLAN) und dergleichen oder Kombinationen hieraus verwendet werden.

Erfindungsgemäß ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, wenigstens eine zweite Software 132, die von der ersten Software 131 verschieden ist, über die Datenschnittstelle 140 von der externen Einheit 300 zu laden und mittels der Recheneinheit 1 10 auszuführen. Dadurch ist vorteilhaft die

Möglichkeit gegeben, beispielsweise bedarfsweise das Steuergerät 100 mit einer gegenüber der ersten Software 131 andersartigen, insbesondere

spezialisierteren, zweiten Software 132 zu versorgen, die beispielsweise eine spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 ermöglicht. Besonders vorteilhaft kann durch das erfindungsgemäße Laden dieser zweiten Software 132 im Bedarfsfalle die Ausstattung von Steuergeräten 100, beispielsweise bei deren Herstellung, bereits mit einer gegebenenfalls vergleichsweise umfangreichen zweiten Software entfallen, sodass entsprechende Ressourcen (Speicher, Rechenzeit) in dem Steuergerät 100 nur dann für die Vorhaltung bzw.

Ausführung der zweiten Software belegt werden, wenn diese tatsächlich benötigt wird und z.B. momentan geladen ist bzw. ausgeführt wird.

Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die erste Software 131 bei der Ausführung durch die Recheneinheit 1 10 eine Diagnose wenigstens einer Funktion des Steuergeräts 100 selbst und/oder eine Diagnose wenigstens einer weiteren mit dem Steuergerät 100 verbundenen Komponente 200 ermöglicht, wodurch ein erstes Diagnoseergebnis erhalten wird. Mithin kann es sich bei der ersten Software 131 um eine Diagnosesoftware handeln, welche ein oder mehrere Diagnosefunktionen ausführt. Beispielsweise kann die erste

Software 131 einen vorgebbaren Satz von minimal-Diagnosefunktionen enthalten, welche zum Beispiel erforderlich sind, um Systemauswirkungen von möglichen Fehlern zu erkennen. Mit dieser ersten Software 131 kann das erfindungsgemäße Steuergerät 100 beispielsweise zum Zeitpunkt seiner Produktion versehen werden, beispielsweise durch einen an sich bekannten Programmiervorgang.

Generell können die vorstehend genannten Informationen über den Betrieb des Steuergeräts bzw. die Informationen über den Betrieb von mit dem Steuergerät verbundenen Komponenten alle durch das Steuergerät 100 erfassbaren Größen des Steuergeräts oder der genannten Komponenten oder beliebige

Kombinationen hieraus umfassen, insbesondere auch Sensormesswerte, Daten von mit dem Steuergerät assoziierten Kommunikationsschnittstellen, und dergleichen. Beispielsweise kann das Steuergerät 100 bei manchen

Ausführungsformen die Informationen über den Betrieb von mit dem Steuergerät 100 verbundenen Komponenten 200 über eine entsprechende

Kommunikationsschnittstelle P1 (CAN-Bus, LIN-Bus, FlexRay-Bus, andere Kommunikationsschnittstellentypen) erhalten, über die das Steuergerät 100 mit den betreffenden Komponenten 200 verbunden ist. Beispielsweise können solche Informationen auch Teile von mittels des Steuergeräts 100 empfangenen CAN-Botschaften enthalten und dergleichen.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, mittels der ersten Software 131

gesammelte Informationen, insbesondere das mittels der ersten Software 131 erhaltene erste Diagnoseergebnis, an die wenigstens eine externe Einheit 300 zu senden. Dadurch kann die Auswertung des Diagnoseergebnisses vorteilhaft außerhalb des Steuergeräts 100 erfolgen und beispielsweise mittels einer leistungsfähigen Vorrichtung zur Datenverarbeitung ausgeführt werden, beispielsweise unter Verwendung eines zentralen Serversystems, eines verteilten Rechnersystems („cloud"), oder dergleichen. Insbesondere können die Diagnoseergebnisse bei manchen Ausführungsformen auch vorteilhaft einem System zur Verfügung gestellt werden, welches ein sogenanntes virtuelles Fahrzeug repräsentiert, also eine digitale Repräsentation einer Mehrheit oder Gesamtheit von in einem tatsächlich vorhandenen Fahrzeug angeordneten Steuergeräten bzw. deren Betriebsparameter. Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software 132 dazu ausgebildet ist, eine gegenüber der ersten Software 131 spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 auszuführen. Damit kann die Diagnosefunktionalität über die von der ersten Software 131 gegebenen

Möglichkeiten sinnvoll erweitert werden, insbesondere individuell angepasst an gegebenenfalls vorhandene Fehlerbilder bzw. Probleme, was durch die

Auswertung der Informationen über den Betrieb des Steuergeräts 100 bzw. der betreffenden Komponenten 200 ermöglicht ist.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software eine oder mehrere, insbesondere direkt durch die Recheneinheit 1 10 ausführbare, Diagnosefunktionen umfasst, die in Abhängigkeit des ersten Diagnoseergebnisses erhalten bzw. programmiert worden sind. Dadurch kann die Recheneinheit 1 10 direkt die beispielsweise spezifischeren

Diagnosefunktionen der zweiten Software nutzen. Besonders bevorzugt wird die zweite Software 132 der Recheneinheit 1 10 direkt in Form eines ausführbaren Computerprogramms (z.B. Binärcode) zur Verfügung gestellt, welches beispielsweise zumindest zeitweise in dem Steuergerät 100 zwischengespeichert werden kann, insbesondere in einem Flash-Speicher oder auch einem

Arbeitsspeicher des Steuergeräts, wo es zur Ausführung durch die

Recheneinheit 1 10 zur Verfügung steht.

Bei einer weiteren bevorzugten Ausführungsform kann der Schritt des Ladens der zweiten Software 132 und/oder der Schritt des Ausführens der zweiten Software 132 während des Betriebs des Steuergeräts 100 bzw. der

Recheneinheit 1 10 erfolgen. Insbesondere kann vorgesehen sein, dass die Recheneinheit 1 10 zur Ausführung der erfindungsgemäßen Schritte des Ladens und Ausführens vorteilhaft nicht in einen speziellen Programmierzustand versetzt werden muss, wie er beispielsweise bei Firmware-Upgrades erforderlich ist, die eine komplette Neuprogrammierung des gesamten Speichers des Steuergeräts erfordern. Dadurch kann die zweite Software 132 bedarfsweise dynamisch in dem Steuergerät 100 zum Einsatz kommen und z.B. zur Erkennung bzw.

Klassifizierung von Fehlern beitragen. Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, die zweite Software 132 in Abhängigkeit von wenigstens einem Ereignis zu laden, wobei das wenigstens eine Ereignis von der zumindest zeitweisen Sammlung von Informationen (ausgeführt z.B. mittels der ersten Software 131 ) abhängt und/oder von wenigstens einer externen Anfrage an das Steuergerät 100. Mit anderen Worten kann bei manchen Ausführungsformen vorgesehen sein, dass in Abhängigkeit der Sammlung von Informationen durch die erste Software 131 das Laden der zweiten Software 132 ausgelöst wird. Bei anderen Ausführungsformen kann alternativ oder ergänzend vorgesehen sein, dass das Laden der zweiten

Software 132 durch die externe Anfrage an das Steuergerät 100 ausgelöst wird. Dies kann beispielsweise dann zweckmäßig sein, wenn sich geänderte

Betriebsbedingungen für das Steuergerät 100 ergeben, die gegebenenfalls eine Veränderung der Ausführung der ersten Software bzw. eine Ergänzung durch die zweite Software erforderlich machen.

Einer weiteren vorteilhaften Ausführungsform zufolge ist vorgesehen, dass externe Ereignisse das Laden bzw. Nachladen der zweiten Software 132 wie beispielsweise einer zusätzlichen Diagnosefunktion anstoßen bzw. auslösen. Mögliche Ereignisse sind beispielsweise: neu auftretende Fehler anderer gleichartiger oder verschiedenartiger Steuergeräte, insbesondere eine neu auftretende Security-Problematik, die Verbringung des Steuergeräts 100 bzw. eines das Steuergerät 100 enthaltenden Zielsystems (zum Beispiel

Kraftfahrzeug) in einen regional anderen Markt mit gegebenenfalls anderen gesetzlich geforderten Diagnosefunktionen, ein geänderter gesellschaftlich geforderter Stand der Technik insbesondere bezüglich der Funktionalität der ersten und/oder zweiten Software, ein externer Anlass zur Untersuchung eines Abnutzungsbildes bzw. Korrosionsbildes bzw. sonstiger Zustände des

Steuergeräts 100 bzw. hiermit verbundener Komponenten, beispielsweise veranlasst durch Maßnahmen zur Qualitätssicherung, eine, insbesondere gesellschaftlich gewünschte, Veränderung, insbesondere Einengung, von Toleranzen in Diagnosefunktionen (beispielsweise Abgas, Objekterkennung), das Testen von Bauteilhypothesen im Feld für Entwicklungs- bzw.

Weiterentwicklungsprozesse betreffend das Steuergerät 100, eine Validierung von Funktionen im Feld mit Bestimmung einer sogenannten„threshold consumption". Figur 2 zeigt schematisch ein vereinfachtes Flussdiagramm einer

Ausführungsform eines erfindungsgemäßen Betriebsverfahrens für das

Steuergerät 100. In einem ersten Schritt 400 wird wenigstens eine zweite Software 132 (Fig. 1 ), die verschieden ist von der ersten Software 131 , über die Datenschnittstelle 140 von der externen Einheit 300 geladen. Beispielsweise kann es sich hierbei um eine spezifische Diagnosesoftware handeln, die zuvor nicht bereits in dem Steuergerät enthalten war, sondern z.B. extern zu dem Steuergerät 100 erstellt worden ist, beispielsweise in Abhängigkeit von mittels der ersten Software 131 erhaltenen Diagnoseergebnissen, die das Steuergerät 100 zuvor an die externe Einheit 300 gesandt hat.

In Schritt 410 wird die zweite Software 132 mittels der Recheneinheit 1 10 ausgeführt, und es wird hierbei z.B. ein zweites Diagnoseergebnis erhalten, das in einem optionalen weiteren Schritt 420 auch von dem Steuergerät 100 an die externe Einheit 300 gesandt werden kann. Alternativ oder ergänzend kann das Steuergerät 100 eine lokale Fehlerreaktion bzw. eine Signalisierung an einen Benutzer in Abhängigkeit des zweiten Diagnoseergebnisses ausführen.

Sofern die zweite Software 132 nicht mehr von dem Steuergerät 100 benötigt wird, kann sie bei bevorzugten Ausführungsformen wieder aus dem Speicher des Steuergeräts 100 gelöscht werden.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft eine Vorrichtung zur Verarbeitung von Daten, vgl. die externe Einheit 300 aus Figur 1 . Die Vorrichtung 300 ist dazu ausgebildet, von einem Steuergerät, insbesondere von dem erfindungsgemäßen Steuergerät 100, Informationen über einen Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 zu empfangen und in Abhängigkeit von diesen Informationen eine spezifische Diagnosesoftware für das Steuergerät 100 zu erstellen und an das Steuergerät 100 zu übertragen. Die erfindungsgemäße Vorrichtung 300 ermöglicht vorteilhaft die effiziente Ausstattung von Steuergeräten 100, insbesondere für Kraftfahrzeuge, mit einer spezifischen Diagnosefunktionalität im Rahmen der vorstehend bereits beschriebenen erfindungsgemäßen zweiten Software 132.

Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die Vorrichtung 300 dazu ausgebildet ist, die Informationen über den Betrieb des Steuergeräts 100 auszuwerten, um wenigstens ein Fehlerbild hieraus abzuleiten, und die spezifische Diagnosesoftware auf das wenigstens eine Fehlerbild hin zu optimieren. Diese spezifische Diagnosesoftware kann dann als die vorstehend bereits beschriebene zweite Software 132 an das erfindungsgemäße Steuergerät 100 gesendet bzw. von dem Steuergerät 100 geladen (vgl. Schritt 400 aus Figur

2) und sodann bei Bedarf ausgeführt werden.

Figur 3 zeigt schematisch ein vereinfachtes Flussdiagramm einer

Ausführungsform eines Betriebsverfahrens für die externe Einheit 300, vgl. Fig. 1 . In einem ersten Schritt 500 empfängt die externe Einheit 300 Informationen von dem Steuergerät 100, z.B. die ersten Diagnoseinformationen. In einem zweiten Schritt 510 erstellt die externe Einheit 300 eine spezifische

Diagnosesoftware als zweite Software 132 für das Steuergerät 100 und überträgt sodann diese zweite Software 132 an das Steuergerät 100.

Figur 4 zeigt schematisch ein Betriebsszenario gemäß einer Ausführungsform. Es wird beispielhaft als Zielsystem für das Steuergerät 100 ein Kraftfahrzeug betrachtet, bzw. eine Vielzahl von Kraftfahrzeugen, die jeweils mit dem

Steuergerät 100 ausgestattet sind. Das Bezugszeichen M1 in Figur 4 beschreibt eine Menge der im Feld befindlichen Kraftfahrzeuge mit dem Steuergerät 100.

Das Bezugszeichen M2 beschreibt eine erste Teilmenge dieser im Feld befindlichen Kraftfahrzeuge mit dem Steuergerät 100, und zwar diejenige Teilmenge, bei der durch Ausführung der ersten (z.B. vorinstallierten)

Diagnosesoftware 131 ein Verdacht auf eine Fehlfunktion des Steuergeräts 100 oder einer hiervon wenigstens mittelbar überwachbaren Komponente 200 festgestellt worden ist. Die Steuergeräte 100 dieser ersten Teilmenge M2 können unter Anwendung des erfindungsgemäßen Prinzips vorteilhaft eine spezifische zweite Diagnosesoftware 132 laden, z.B. von der externen Einheit 300, die insbesondere in Abhängigkeit der zuvor erkannten Fehlfunktion erstellt bzw. angepasst worden ist, um eine spezifischere Diagnose als die erste

Diagnosesoftware 131 zu ermöglichen. Das Ausführen der zweiten

Diagnosesoftware 132 führt beispielsweise nur noch bei einer zweiten Teilmenge M3 der ersten Teilmenge M2 zu einer Bestätigung einer Fehlfunktion, nicht aber bei allen Fahrzeugen der ersten Teilmenge M2. Die Fahrzeuge der zweiten Teilmenge M3 können sodann vorteilhaft im Feld untersucht bzw. in die

Werkstatt zurückgerufen werden, um eine noch gründlichere Fehlerdiagnose auszuführen, was auf die dritte Teilmenge M3 von Fahrzeugen führt, bei denen hierbei tatsächlich z.B. ein Komponentenfehler erkannt werden kann.

Wie aus Fig. 4 ersichtlich ist, ermöglicht das erfindungsgemäße Prinzip vorteilhaft die Eingrenzung von (fehler-)verdächtigen Fahrzeugen, um effizient nur eine gewisse Teilmenge M3 der Gesamtmenge M1 näher untersuchen zu müssen, wodurch Kosten gespart werden können und die möglicherweise tatsächlich durch einen Fehler betroffenen Steuergeräte 100 schneller und effizienter identifiziert werden können.

Das erfindungsgemäße Prinzip ermöglicht vorteilhaft das dynamische

Bereitstellen und Nutzen von zweiter Software 132 in einem Steuergerät 100. Dadurch ist es vorteilhaft möglich, die zweite Software erst dann in dem

Steuergerät 100 bereitzustellen, wenn sie tatsächlich benötigt wird. Dies spart Speicherressourcen des Steuergeräts 100 und ermöglicht vorteilhaft die

Erstellung bzw. Veränderung der zweiten Software 132 kurz bevor sie tatsächlich in dem Steuergerät 100 zum Einsatz kommt. Dadurch eignet sich das

erfindungsgemäße Prinzip besonders gut zur Vorhaltung von Diagnosesoftware, welche insbesondere direkt auf ein beispielsweise mittels einer ersten

Diagnosesoftware 131 erkanntes Fehlerbild bzw. einen Fehlerverdacht zugeschnitten werden kann.

Nachstehend sind weitere vorteilhafte Aspekte von weiteren Ausführungsformen genannt.

Bei einer Ausführungsform kann bei ersten Verdachtsmomenten auf

Feldprobleme, die beispielsweise während der Ausführung der ersten

Diagnosesoftware 131 erhalten werden, das Fehlerbild, beispielsweise in

Abhängigkeit des ersten Diagnoseergebnisses, genau eingegrenzt werden, und eine darauf zugeschnittene zweite Diagnosesoftware kann zur verbesserten Fehlerdetektion nachentwickelt bzw. erstellt werden und zur Ausführung in das Steuergerät 100 geladen werden.

Bei einer weiteren Ausführungsform kann das Nachladen der Diagnosefunktion bzw. generell der zweiten Software 132 beispielsweise mittels eines

sogenannten Flash over the air („FOTA") - Mechanismus erfolgen. Besonders bevorzugt wird hierbei jedoch nicht ein gesamter Flash-Speicher bzw.

Speicherbereich des Steuergeräts 100 überschrieben, sondern nur ein der zweiten Software 132 zugeordneter Bereich. Dadurch wird verhindert, dass ein Betrieb des Steuergeräts 100 für die Übertragung der zweiten Software 132 unterbrochen werden muss.

Die Anwendung des erfindungsgemäßen Prinzips ermöglicht vorteilhaft eine Eingrenzung einer Menge von Verdachtsfahrzeugen, vergleiche die Menge M1 aus Figur 4, auf die tatsächlich real betroffenen Fahrzeuge, was vorteilhaft einer Minimierung der sogenannten„defective subgroup" entspricht. Dadurch wird insbesondere auch eine sehr präzise Festlegung möglicherweise von einem Rückruf betroffener Fahrzeuge, vergleiche die Teilmenge M3, ermöglicht. Dies bedingt vorteilhaft eine Kostenreduktion einer Feldaktion, da die Anzahl der betroffenen Fahrzeuge ganz direkt in diese Kosten eingeht.

Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, in dem Steuergerät 100 eine solche zweite Software 132 nachzuladen bzw.

auszuführen, welche nicht zur Diagnose des Steuergeräts 100 selbst bzw. eines hiermit direkt verbundenen Systems (beispielsweise ein an das Steuergerät 100 angeschlossener Sensor bzw. Aktor) vorgesehen ist, sondern vielmehr zur Diagnose einer weiteren Komponente 200. Bei der weiteren Komponente kann es sich beispielsweise um eine Lambdasonde handeln, welche an einem Motorsteuergerät angeschlossen ist. Das Steuergerät 100 kann über mit dem Motorsteuergerät gemeinsame Kommunikationsverbindungen beispielsweise Informationen erhalten, welche Ausgangsdaten der Lambdasonde

charakterisieren. Die zweite Software 132 kann beispielsweise dazu vorgesehen sein, solche Ausgangsdaten der Lambdasonde spezifisch auf Fehler hin zu überprüfen. Mit anderen Worten ermöglicht das erfindungsgemäße Prinzip also auch eine spezifische Diagnose von Komponenten bzw. Systemen, die nicht einmal direkt mit dem erfindungsgemäßen Steuergerät 100 verbunden sind, sondern beispielsweise über eine Kommunikationsverbindung P1 bzw. über ein anderes Steuergerät.

Ein weiterer Vorteil des erfindungsgemäßen Prinzips besteht in einer

Verkleinerung des Entwicklungsaufwands für die erste Software 131.

Beispielsweise ist es möglich, für einen Serienstart des Steuergeräts 100 nur eine Entwicklung und Installation von wenigen, zentralen Diagnosefunktionen, beispielsweise zur Erkennung von Systemauswirkungen, vorzusehen. Weitere Diagnosefunktionen mit beispielsweise höherer Trennschärfe bezüglich einer Komponentendiagnose werden in Form der zweiten Software, beispielsweise nur bei Auftreten von entsprechenden Komponentenfehlern, nachentwickelt, und können dem Steuergerät 100 unter Anwendung des erfindungsgemäßen Prinzips später zur Verfügung gestellt werden.

Dies bedingt vorteilhaft eine Aufwandsreduktion in der Entwicklung und ermöglicht einen beschleunigten Markteintritt.

Ein weiterer besonderer Vorteil des erfindungsgemäßen Prinzips ist die

Verkleinerung des Steuergeräte-Ressourcenbedarfs. Insbesondere trennscharfe und aufwendige Diagnosefunktionen, die vergleichsweise viel Laufzeit und/oder Speicher erfordern, werden nur bei Auftreten von entsprechenden Fehlern, beispielsweise erkannt durch die ersten Diagnosesoftware 131 ,„aktiviert" (beispielsweise Nachladen und Ausführen der zweiten Diagnosesoftware 132).