DE102019214162A1

DE102019214162A1 - Verfahren und Vorrichtung zum Simulieren eines Steuergerätes

Info

Publication number: DE102019214162A1
Application number: DE102019214162.5A
Authority: DE
Inventors: Rainer Baumgaertner
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2019-09-17
Filing date: 2019-09-17
Publication date: 2021-03-18
Also published as: CN112528350A; US20210081584A1; US11494535B2

Abstract

Verfahren (10) zum Simulieren eines Steuergerätes, gekennzeichnet durch folgende Merkmale:- für mindestens eine Softwarekomponente (20) des Steuergerätes werden Beziehungen zwischen Eingängen (21) und Ausgängen (22) der Softwarekomponente (20) modelliert (11) und- anhand der Beziehungen wird ein Laufzeitverhalten des Steuergerätes simuliert (12).

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Simulieren eines Steuergerätes. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
Stand der Technik
Der Begriff des hochautomatisierten Fahrens (highly automated driving, HAD) bezeichnet gemeinhin eine Entwicklungsstufe zwischen dem assistierten Fahren, bei welchem der Fahrer durch zahlreiche (oft getrennte) Fahrerassistenzsysteme bei der Fahraufgabe unterstützt wird, und dem autonomen Fahren, bei welchem das Fahrzeug gänzlich selbsttätig und ohne Einwirkung des Fahrers fährt. Beim hochautomatisierten Fahren verfügt das Fahrzeug gewissermaßen über eine eigene Intelligenz, die vorausplant und die Fahraufgabe zumindest in den meisten Situationen übernehmen könnte. Fahrer und Steuergeräte (electronic control units, ECUs) führen zusammen das Fahrzeug, wobei der menschliche Fahrer jederzeit bestimmt, wie stark er in das Fahrverhalten des Fahrzeuges eingreift.
WO2018146000A1 offenbart ein Steuergerät für ein Kraftfahrzeug, das eingerichtet ist, mehrere Anwendungen und Zwischenanwendungen (middleware) zu betreiben und einen durch die Anwendungen und Zwischenanwendungen gemeinsam nutzbaren Speicher (shared memory) umfasst. Die Zwischenanwendungen sind eingerichtet, eine Interprozesskommunikation zwischen den Anwendungen über den Speicher abzuwickeln.
DE102018207172A1 beschreibt ein Verfahren zum Simulieren eines cyberphysischen Systems (CPS) in einer realen Betriebssituation, bei dem Messdaten und interne Zustände von Softwarekomponenten des Systems in der Betriebssituation abgespeichert und ein Simulator mit den Messdaten und Zuständen parametriert wird.
Offenbarung der Erfindung
Die Erfindung stellt ein Verfahren zum Simulieren eines Steuergerätes, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
Der erfindungsgemäße Ansatz fußt hierbei auf der Erkenntnis, dass zahlreiche Fahrerassistenzsysteme für hochautomatisiertes Fahren aktuell in der Entstehungsphase sind. Es ist damit zu rechnen, dass die Komplexität entsprechender Software jene herkömmlicher fahrzeugtechnischer (automotive) Anwendungen um Größenordnungen übersteigt.
Der vorgeschlagenen Lösung liegt ferner die Einsicht zugrunde, dass Systeme für hochautomatisiertes Fahren technisch aufwändig sind. Dies gilt ebenso für zukünftige Robotik-Systeme. Sie benötigen eine hohe Rechenleistung und einen großen Speicher und haben deutlich erhöhte Sicherheitsanforderungen. Das Berücksichtigen der funktionalen Sicherheitsanforderungen erhöht zusätzlich die Systemkomplexität.
Das nachfolgend beschriebene Verfahren trägt schließlich dem Umstand Rechnung, dass heutige Systeme im automobilen Umfeld oft als direkt kommunizierende Applikationen oder Komponenten ausgelegt sind. Daten werden, sobald sie verfügbar sind, sofort anderen Applikationen zur Verfügung gestellt. Der exakte zeitliche Zusammenhang der einzelnen Applikationen kann dabei aus technischen Gründen oftmals nicht exakt vorgegeben werden, z. B. da die Anzahl unabhängiger Rechenkerne weit hinter der Anzahl der darauf ausführbaren (executable) Applikationen zurückbleibt. Der exakte Sendezeitpunkt spezifischer Daten ist daher mitunter schwer zu bestimmen. Das Alter der Daten, die von einer bestimmten Applikation empfangen werden, ist entsprechend unvorhersagbar und hängt in hohem Maße von Laufzeitbedingungen ab.
Eine frühzeitig im Entwicklungsprozess ansetzende modellbasierte Simulation von Zeitsteuerung und -abstimmung (timing) ist daher wünschenswert, um bereits in der Entwurfsphase (design) zeitliche „Engpässe“ erkennen und die Erfüllbarkeit nichtfunktionaler Anforderungen prüfen zu können. Während der Entwicklung kann auf diese Weise zudem regelmäßig das Design mit der Implementierung abgestimmt werden. Am Markt verfügbare Werkzeuge für diese Aufgaben sind z. B. die TA Tool Suite der Vector Informatik GmbH oder chronSIM der INCHRON GmbH.
In einem zahlreiche Softwarekomponenten umfassenden Steuergerät stellt vor allem die Simulation der Weitergabe von Informationen ein typisches Problem dar. Timing-Simulationen liegt im Allgemeinen kein äquivalentes funktionales Modell zugrunde. Nach dem Stand der Technik ist daher in der Regel eine manuelle Implementierung oder eine starke Vereinfachung der Annahmen erforderlich.
Gerade angesichts der im Hinblick auf hochautomatisierte Fahrfunktionen geschaffenen Option, Aktivierungsbedingungen zu modellieren, ist diese Herangehensweise mit Einschränkungen und hohem Aufwand verbunden.
Ein Vorzug der erfindungsgemäßen Lösung liegt vor diesem Hintergrund in der eröffneten Möglichkeit, durch eine abstrakte Modellierung der Weitergabe von Informationen Timing-Modelle automatisch zu erstellen und die Güte der Timing-Simulation deutlich zu verbessern. Zudem wird das Single-Source-Prinzip unterstützt.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich.
Figurenliste
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
2 auszugsweise das Komponentendiagramm eines zu simulierenden Steuergerätes.
3 schematisch einen Arbeitsplatzrechner gemäß einer zweiten Ausführungsform.

Ausführungsformen der Erfindung
1 illustriert den grundlegenden Ablauf eines erfindungsgemäßen Verfahrens (10).
Dessen Anwendung sei nunmehr anhand der in 2 abgebildeten Softwarekomponente (20) eines Steuergerätes erläutert. Mittels einer domänenspezifischen Beschreibungssprache werden die Beziehungen zwischen den Eingängen (21) und Ausgängen (22) der Softwarekomponente (20) modelliert (Prozess 11 - 1). Dazu wird die Funktion „lnput-output-relation()‟ eingeführt, welche es erlaubt, die Weitergabe von Informationen wie Sequenznummern und Zeitstempeln von den Eingängen (21) an die Ausgänge (22) zu beschreiben. Im vorliegenden Beispiel gibt etwa „lnput-output-relation(disparity, Stereo image (seq())“ an, dass die Softwarekomponente (20) die Sequenznummer am Ausgang „disparity“ vom Eingang „Stereo image“ bezieht.
In entsprechender Weise spezifiziert der Ausdruck „lnput-output-relation(disparity, Stereo image (timestamp)“, dass die Softwarekomponente (20) den Zeitstempel am Ausgang „disparity“ vom Eingang „Stereo image“ bezieht.
Vorzugsweise modelliert „lnput-output-relation(disparity, activation_timestamp)“, dass die Softwarekomponente (20) den Zeitstempel am Ausgang „disparity“ vom Zeitpunkt ihrer eigenen Aktivierung ableitet.
Damit sind diese Beziehungen in Aktivierungsbedingung, Simulation und vorzugsweise Implementierung vergleichbar und verwendbar.
Vorzugsweise wird zusätzlich die Funktion „output-expectation()“ eingeführt, welche angibt, wie viele Abtastwerte (samples) am Ausgang der Softwarekomponente (20) abhängig von ihrer Aktivierung und ihren Eingängen (21) generiert werden. Damit lassen sich in der anschließenden Timing-Simulation (Prozess 12 - 1) die statistischen Eingangsverteilungen auf die Ausgangsverteilungen der Softwarekomponente (20) abbilden.
Dieses „Produktivitätsmaß“ ist zudem wichtig, um die statistische Verteilung der durch die Aktivierungsbedingung modellierten Aktivierung abhängiger Komponenten zu simulieren. Letzteres wiederum ist notwendig, da in deren Aktivierungsbedingung die an den Ausgängen (22) produzierten Abtastwerte als Stimuli einfließen.
Schließlich modelliert „output-expectation(disparity, Stereo image , 1)“, dass die Softwarekomponente (20) bei Aktivierung pro Abtastwert am Eingang „Stereo image“ einen Wert am Ausgang „disparity“ produziert. Entsprechend modelliert „output-expectation(disparity, 1)“, dass die Softwarekomponente (20) pro Aktivierung einen Abtastwert am Ausgang „disparity“ produziert.
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einer Arbeitsstation (30) implementiert sein, wie die schematische Darstellung der 3 verdeutlicht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 2018146000 A1 [0003]
DE 102018207172 A1 [0004]

Claims

Verfahren (10) zum Simulieren eines Steuergerätes, gekennzeichnet durch folgende Merkmale: - für mindestens eine Softwarekomponente (20) des Steuergerätes werden Beziehungen zwischen Eingängen (21) und Ausgängen (22) der Softwarekomponente (20) modelliert (11) und - anhand der Beziehungen wird ein Laufzeitverhalten des Steuergerätes simuliert (12).
Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgendes Merkmal: - die Beziehungen umfassen eine Weitergabe von Informationen von den Eingängen (21) an die Ausgänge (22).
Verfahren (10) nach Anspruch 2, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Informationen umfassen Sequenznummern oder - die Informationen umfassen Zeitstempel.
Verfahren (10) nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgende Merkmale: - das Modellieren (11) erfolgt mittels einer formalen Sprache.
Verfahren (10) nach Anspruch 4, gekennzeichnet durch folgendes Merkmal: - die Sprache ist eine domänenspezifische Beschreibungssprache.
Verfahren (10) nach einem der Ansprüche 1 bis 5, gekennzeichnet durch folgende Merkmale: - für die Softwarekomponente (20) werden ferner Erwartungen hinsichtlich einer Produktivität der Ausgänge (22) modelliert (11) und - das Simulieren (12) erfolgt ferner anhand der Erwartungen.
Verfahren (10) nach Anspruch 6, gekennzeichnet durch folgendes Merkmal: - die Erwartungen hinsichtlich der Produktivität werden abhängig von einer Aktivität an den Eingängen (21) angegeben.
Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
Vorrichtung (30), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.