-
Die
Erfindung geht aus von einer Vorrichtung zur Ansteuerung von Personenschutzmitteln
nach der Gattung des unabhängigen
Patentanspruchs.
-
Aus
DE 100 57 917 A1 ist
bereits eine Vorrichtung zur Ansteuerung von Zündkreisen für Rückhaltemittel bekannt.
-
Vorteile der
Erfindung
-
Die
erfindungsgemäße Vorrichtung
zur Ansteuerung von Personenschutzmitteln mit den Merkmalen des
unabhängigen
Patentanspruchs hat demgegenüber
den Vorteil, dass nunmehr ein Softwaremodul zur Steuerung des Ansteuerungsverhaltens der
Personenschutzmittel zur Verfügung
steht und dabei einen Parametersatz aus einem Speicher lädt, wobei
anhand des Parametersatzes es bestimmbar ist, welche Personenschutzmittel
und zu welcher Zeit, angesteuert werden. Für diese Bestimmung werden nicht
nur die Parameter benötigt,
sondern auch Ausgabedaten aus einem Ansteuerungsalgorithmus und
Fahrzeugzustandsdaten. Die Fahrzeugszustandsdaten zeigen an, welche
Peripherie im Fahrzeug vorhanden ist. Sie zeigen beispielsweise
an, wie weit ein Sitz von dem Armaturenbrett entfernt ist. Dies
kann beispielsweise zur Folge haben, dass ein Airbag nicht ausgelöst wird,
wenn sich die Person auf dem Sitz zu nahe am Airbag befindet: Anhand
der Ausgabedaten des Auslösealgorithmus kann
bestimmt werden, wie schwer der Unfall ist und damit, welche Personenschutzmittel
wie Airbags; Gurtstraffer oder Überrollbügel ausgelöst werden müssen und
in welcher Stärke,
wenn die Stärke
einstellbar ist. Auch die Zeit, wann die Personenschutzmittel angesteuert
werden, hängt
von der Unfallschwere ab. Durch das Laden der Parameter aus einem
Speicher ist es möglich,
dass das Softwaremodul für
verschiedene Plattformen gleich bleibt und nur die Parameter geändert werden
müssen.
Dies ermöglicht
einen hohen Grad an Flexibilität,
spart Kosten und vereinfacht die Applikation von solchen Steuergeräten für bestimmte
Plattformen. Damit ist es dann auch leicht möglich, Parametersätze auszutauschen,
um ein anderes Austauschverhalten zu erzielen. Der lauffähige Code,
den das Softwaremodul darstellt, muss dafür nicht verändert werden. Damit ist es
auch möglich,
schnelle Änderungen
des Auslöseverhaltens
zu erreichen, auch im Betrieb des Fahrzeugs.
-
Durch
die in den abhängigen
Ansprüchen aufgeführten Maßnahmen
und Weiterbildungen sind vorteilhafte Verbesserungen der im unabhängigen Patentanspruch
angegebenen Vorrichtung zur Ansteuerung von Personenschutzmitteln
möglich.
-
Besonders
vorteilhaft ist, dass der Speicher, aus dem der wenigstens eine
Parametersatz geladen wird, wiederbeschreibbar ist. Damit ist es
in einfachster Weise möglich,
den Parametersatz zu erneuern und damit das Auslöseverhalten bzw. Ansteuerungsverhalten
neu zu definieren. Vorteilhafter Weise ist der Speicher dabei als
EEPROM ausgebildet. Diese Art des Speichers ermöglicht die Wiederbeschreibbarkeit.
Aber auch andere wiederbeschreibbare Speicher, wie beispielsweise
auch eine Festplatte, können
dafür verwendet
werden.
-
Vorteilhafter
Weise sind die Ausgabedaten des Ansteuerungsalgorithmus so dargestellt,
dass sie übertroffene
Schwellen aufweisen. Dabei werden die Schwellen durch ein Mess-Signal oder ein davon abgeleitetes
Signal, beispielsweise ein integriertes oder zweifach integriertes
Mess-Signal übertroffen. Als
Mess-Signal dient üblicherweise
das Beschleunigungssignal. Es können
jedoch auch Drucksignale oder Temperatursignale sein. Die Integration
dient zur Glättung.
Beim Insassenschutz legt man im Algorithmus verschiedene Schwellen
für verschiedene Aufprallarten
ab. Beispielsweise können
für den Frontaufprall
drei Schwellen, für
den Seitenaufprall jeweils nur eine Schwelle vorgesehen sein. Auch
für den
Heckaufprall können
zwei bis drei Schwellen vorgesehen sein, wie auch zwei Schwellen
für einen Überrollvorgang,
also für
einen Drehratensensor oder einen Drehbeschleunigungssensor vorgesehen sein
können.
Die Anzahl der Schwellen ist hier nur beispielhaft angedeutet und
kann variiert werden. Die Ausgabedaten zeigen also an, welche Unfallschwere vorliegt.
Dies bestimmt, welche Personenschutzmittel eingesetzt werden und
wie schnell die Personenschutzmittel eingesetzt werden müssen. Bei
einem sehr harten Crash müssen
die Personenschutzmittel unverzüglich
eingesetzt werden.
-
Das
Softwaremodul arbeitet vorteilhafter Weise in Echtzeit, wobei das
Softwaremodul hier in einem festen Takt, der typischer Weise mit
500 μs festgelegt
ist, arbeitet. Die Fahrzeugzustandsdaten werden mit einem langsameren
Takt ermittelt, und zwar beispielsweise in einem Takt von 10 ms.
Dies ist auch ausreichend, da sich diese Fahrzeugzustandsdaten,
wie Sitzabstand, nicht so schnell ändern. Dem Softwaremodul ist
weiterhin ein Submodul zugeordnet, das entweder in dem 10-ms-Takt
oder in einem noch langsameren Takt, beispielsweise 100 ms arbeitet,
und dabei Aufgaben vom Softwaremodul übernimmt, die nicht Echtzeit
benötigen.
-
Zeichnung
-
Ausführungsbeispiele
der Erfindung sind in der Zeichnung dargestellt und werden in der
nachfolgenden Beschreibung näher
erläutert.
-
Es
zeigen
-
1 ein
Blockschaltbild der erfindungsgemäßen Vorrichtung und
-
2 ein
Diagramm.
-
Beschreibung
-
Ein
Softwaremodul, das das Ansteuerungsverhalten von Personenschutzmitteln
steuert, ist nicht frei programmierbar. D.h. es liegt als lauffähiger Code
vor, beispielsweise in C geschrieben, und ist dabei für einen
Kunden, also eine feste Fahrzeugplattform, zugeschnitten. Das Softwaremodul
ist dabei fest in einem ROM einprogrammiert. Daher ist klar, dass
das Softwaremodul für
jede Fahrzeugplattform neu geschrieben und getestet werden muss. Das
bedeutet einen hohen Test- und Pflegeaufwand. Durch das neue Softwaremodul
soll es möglich
sein, über
einen einspielbaren Parametersatz das Ansteuerungsverhalten so zu
beeinflussen, dass es für
alle Kunden frei applizierbar ist.
-
Mit
dem neuen Softwaremodul lässt
sich das Ansteuerungsverhalten eines Steuergeräts durch Parameter, die sich
im EEPROM befinden, für
jeden Kunden anpassen. D.h. es existiert ein zentrales Softwaremodul,
das nur einmal geschrieben und gestestet wird, und zwar für alle Fahrzeugplattformen. Über die
Parameter bzw. Kommandostruktur lässt sich bei der Applikation
ein kundenspezifischer Parameter erstellen. Dieser Parametersatz
kann mit Hilfe eines Tools erstellt werden. Die Ausgabe dieses Tools
ist ein Parameterfile, welches sich problemlos in der Software integrieren
lässt,
um so ein EEPROM-File zu generieren. Jedes neue Ansteuerungsverhalten
hat zur Folge, dass ein neuer Parametersatz für das EEPROM erstellt werden
muss. Durch den Austausch von Parametersätzen ist es möglich, ein
komplett neues Ansteuerungsverhalten zu bekommen. Diese flexible
Funktionalität
des Softwaremoduls ist von besonderem Vorteil.
-
Neben
dem Softwaremodul ist noch ein Submodul und ein Softwareelement
zur Bereitstellung der Fahrzeugzustandsdaten vorgesehen. Diese Module
sind notwendig, um die flexible Funktionalität des Ansteuerungsverhaltens
zu gewährleisten.
Dabei besitzt jedes dieser Modu1e einen eigenen Parametersatz.
-
Das
Softwaremodul ist für
das dynamische und physikalische Zünden der Personenschutzmittel zuständig. Das
dynamische und physikalische Ansteuerungsverhalten ist über die
Parameter einstellbar.
-
Das
Submodul ist ein Hilfsmodul für
das Softwaremodul, das dieses in einer Crashsituation entlasten
soll. Dabei werden dem Submodul Aufgaben übertragen, die nicht die Verarbeitung
in Echtzeit benötigen.
Aber auch dieses Submodul ist ebenfalls über Parameter einstellbar.
-
Das
Softwareelement zur Verarbeitung der Fahrzeugzustandsdaten bewertet
den Peripheriestatus des Fahrzeugs und berechnet die sogenannten Freigabebäume. Diese
sind für
die Zündentscheidung
im Fahrzeug während
einer Crashphase verantwortlich. Wird beispielsweise ein Gurtstraffer
zur Zündung
durch die Crashschwere angefordert, so ist es notwendig, diesen
nur auszulösen,
wenn das Gurtschloss gesteckt ist. Der Freigabebaum wird demnach
gebraucht, um die Freigabe eines Personenschutzmittels zu berechnen.
Die Freigabebäume sind über den
Parametersatz einstellbar.
-
1 zeigt
in einem Blockschaltbild die erfindungsgemäße Vorrichtung. Eine Unfallsensorik 11 ist
mit einem Mikrocontroller μC,
also einem Prozessor, und einem Sicherheitshalbleiter SCON verbunden.
Bei der Unfallsensorik 11 handelt es sich beispielsweise
um eine Beschleunigungssensorik und/oder eine Drueksensorik, aber
auch eine Umfeldsensorik und/oder eine Kontaktsensorik sind allein
oder in Kombination möglich.
-
Sowohl
der Sicherheitshalbleiter SCON, als auch der Mikrocontroller μC verarbeiten
getrennt und unabhängig
voneinander die Sensorwerte um festzustellen, ob ein Unfall vorliegt.
Erkennt der Sicherheitshalbleiter SCON, dass es sich um einen Unfall handelt,
gibt er Zündendstufen
in einer Zündkreisansteuerung
FLIC frei. Der Mikrocontroller μC
berechnet aus den Sensordaten, ob die Auslösung von Personenschutzmitteln
notwendig ist. Dazu stellt der Mikrocontroller μC Schwellwertvergleiche an.
Diese Schwellen können
zeitabhängig
und dynamisch sein. Zusätzlich
berücksichtigt
der Mikrocontroller μC
bei der Ansteuerung der Zündkreisansteuerung
FLIC Signale von einer Innenraumsensorik 13, die beispielsweise
auch den Abstand des Sitzes bzw. der Person zum Armaturenbrett berücksichtigt.
Als Innenraumsensorik können
Kontaktsensoren, Videosensoren, Mikrowellensensoren, Hochfrequenzsensoren,
Sitzkraftsensoren, u.s.w. verwendet werden. Der Mikrocontroller μC verwendet
für seine
Berechnungen einen Speicher 10, der einen flüchtigen
Speicherbereich aufweist und einen Speicher, in dem sich Daten fest
abspeichern lassen, wie beispielsweise ein EEPROM. Die Zündkreisansteuerung
FLIC weist Zündendstufen
und dabei eine Plus- und Minusendstufe auf, um ein jeweiliges Zündelement 14 mit
dem Zündstrom
zu bestromen. Diese Zündendstufen
werden nur durchgeschaltet, wenn der Sicherheitshalbleiter SCON
und der Mikrocontroller μC
beide auf eine Auslösung
entscheiden und entsprechende Signale an die Zündkreisansteuerung FLIC übertragen.
Das Zündelement 14 wird
dann bei einer entsprechenden Bestromung explodieren und zu einer
Aufblähung, beispielsweise
eines Airbags, führen.
Der Einfachheit halber ist hier nur ein Zündelement dargestellt, üblicher
Weise werden jedoch eine Vielzahl von Zündelementen angesteuert. Auch
andere Sensoriken, wie eine Precrashsensorik, sind hier der Einfachheit
halber nicht dargestellt.
-
Das
erfindungsgemäße Softwaremodul
läuft auf
dem Mikrocontroller μC.
Dort läuft
auch das Submodul und das Softwareelement zur Verarbeitung der Fahrzeugzustandsdaten.
Wie oben dargestellt jedoch in unterschiedlichen Zeitebenen.
-
2 erläütert in
einem Diagramm die Funktionsweise dieser Module. Hierbei ist im
Block 200 die Zeitebene dargestellt bzw. der Zeittakt,
der mit 10 ins abläuft,
im Block 201 sind die Daten im EEPROM dargestellt und im
Block 202 die Prozesse, die in Echtzeit ablaufen. Im Block 203 werden
die Fahrzeugzustandsdaten vom Fahrzeug durch das Modul SIV 204 eingelesen.
Dieses Modul 204 sammelt die Umgebungsparameter ein und
formt daraus einen Vektor 205, der dem Softwareelement 206 übertragen
wird. Dieses Softwareelement 206 bewertet den Peripheriestatus
des Fahrzeugs und berechnet die sogenannten Freigabebäume, wie
oben dargestellt. Die Freigabebäume
werden im Block 207 bereitgestellt, wobei damit dann im
Block 208 die Zündkreise ausgewählt werden,
die angesteuert werden sollen. D.h. im Block 208 wird in
einem langsameren Prozeß oder
Takt wie in der Echtzeit 202 eine Interpretation von Feuersequenzen
durchgeführt.
Das Ergebnis wird dann in den Block 209 geschrieben.
-
Block 213 enthält ebenfalls
FireSequenzen wie auch Block 212. Um Laufzeit in der 500μs Ebene zu
sparen, ist es möglich,
bestimmte Kriterien vorausgesetzt, FireSequenzen vom Block 212 in
den Block 213 zu verlegen, die dann im Block 208 interpretiert
werden. Somit lassen sich Firesequenzen im Background, d.h. mit
einem niedrigeren Takt, vorausberechnen. Das Ergebnis wird in Block 209 geschrieben.
Der Inhalt sagt aus, welche Zündmittel
im Falle eines Crashs auslösen
würden.
Der Trigger für
die tatsächliche
Auslösung
von freigegebenen Zündmitteln
in Block 209 befindet sich im Block 212 und wird über Block 218 angestoßen.
-
Zusammenfassend
gilt:
Fordert Block 218 den Inhalt von Block 209 an
(Anforderung ist ein Parameter und befindet sich im Block 212)
so wird dieser über
Block 218 und die Schnittstelle 220 direkt an
den Block 221 geschoben. Der Inhalt von Block 209 ist
so aufbereitet, das Block 221 direkt diese Daten zum Zünden der
Zümdmittel nutzen
kann. Somit wird kaum Laufzeit in der Echtziet verbraucht.
-
Firesequenzen
im Block 212 müssen
in Echtzeit ausgewertet werden (Block 218) und verbrauchen
Laufzeit in der Echtzeit. Die ausgewerteten Daten von Block 212,
welche im Block 218 ausgewertet werden, werden über die
Schnittstelle 219 an den Block 220 weitergereicht.
-
Daraus
wird dann im Block 209 die Konfiguration für die Plus-
und Minusendstufe für
jede Feuersequenz, die sich aus dem Block 208 ergeben hat, bestimmt.
Dies wird dann an den Block 218, der im Echtzeitblock 202 sich
befindet, übertragen.
Aus den EEPROM-Daten 201 werden
Algorithmusparameter an ein Algorithmusmodul 216, Freigabebäume 211 an
den Block 206 übertragen,
Feuersequenzen 212 an den Block 218. Diesen Parametern
werden diese einzelnen Module entsprechend appliziert. Im Echtzeitblock 202 werden
im Block 215 Sensordaten eingelesen und einem Algorithmusmodul 216 zugeführt. Dieses
Algorithmusmodul 216 verarbeitet die Sensordaten dahingehend,
dass daraus eine Ansteuerungsentscheidung für Personenschutzmittel bestimmt
wird. Dazu werden die Sensordaten integriert einfach und/oder zweifach,
um sie dann einem Schwellwertvergleich zu unterziehen. In Abhängigkeit
von diesem Schwellwertvergleich werden Feuerflaggen 217 gesetzt,
die anzeigen, dass bestimmte Personenschutzmittel zu zünden sind.
Dies wird dann dem erfindungsgemäßen Softwaremodul 218 übertragen,
das mittels der Parametersätze
aus dem Block 212 und dem Block 209 Feuerdaten
in Echtzeit und vom Block 209 bestimmt.
-
Wie
oben bereits beschrieben, werden Daten von Block 209 über Block 218 und
Schnitstelle 220 direkt an den Block 221 durchgeschleust.
Weiter werden Firesequenzen von Block 212 in Block 218 ausgewertet
und über
Schnittstelle 219 an Block 221 weitergereicht.
-
Beschreibung von Schnittstelle 220:
-
Schnittstelle 220 beinhaltet
den sogenannten PowerStageVector von Block 209. Diese Daten sind
so aufbereitet das sie direkt von Block 221 zum Zünden verwendet
werden können.
-
Beschreibung von Schnittstelle 219:
-
Schnittstelle 219 enthält logische
Züdkreise, welche
zum Zünden
von Modul 218 angefordert werden. Der Inhalt von Schnittstelle 219 muß vom Block 221 interpretiert
werden (Logische Zündmittel
-> Phyisikalische
Züdmittel),
bevor vom Block 221 aus ein Zündmittel gezünden werden
kann.