-
Die
Erfindung betrifft ein Verfahren gemäß Oberbegriff von Anspruch
1, ein Verfahren zum Beschreiben eines elektronischen Speichers,
einen elektronischen Regler gemäß Oberbegriff
von Anspruch 11 sowie die Verwendung des Reglers in Kraftfahrzeugen.
-
Gemäß dem Stand
der Technik werden derzeit üblicherweise
zwei Verfahren zur Team-Softwareintegration im Bereich eingebetteter
Systeme angewendet:
- A) Austausch von Quell-Files
bzw. Quelldateien (z. B. ASCII-Dateien
in Form von *.c oder *.h- Dateien) zwischen den Entwicklungsteams.
- B) Austausch von kompilierten Versionen bzw. Objektbibliotheken
(z. B. *. obj Dateien) zwischen den Entwicklungsteams.
-
Nachteilhafterweise
erfolgt durch den Austausch von Quelldateien zwischen unterschiedlichen Entwicklerteams
beim üblichen
Entwickeln einer gemeinsamen Produktsoftware nach einem Verfahren gemäß dem Stand
der Technik zwangsläufig
auch ein Austausch von Informationen, welche dem jeweiligen Entwicklungsteam,
das die Informationen empfängt, oftmals
aus Grün den
der Geheimhaltung nicht zur Verfügung
gestellt werden sollte. Auch der Austausch von kompilierten Source-Dateien
bzw. von Objektbibliotheken ermöglicht
mit Hilfe der Symboltabellen eine Dekompilierung, welche die Variablennamen
und Funktionsaufrufnamen der Originaldateien enthält.
-
Die
Aufgabe der vorliegenden Erfindung besteht nun darin, obigen unerwünschten
Informationsaustausch im Rahmen der Entwicklung einer gemeinsamen
Produktsoftware vermeidbar zu machen oder sogar gänzlich unterbindbar
zu machen.
-
Diese
Aufgabe wird erfindungsgemäß gelöst durch
das Verfahren gemäß Anspruch
1, das Verfahren gemäß Anspruch
10, sowie durch den elektronischen Regler gemäß Anspruch 11.
-
Das
Verfahren ist dabei vorzugsweise als Verfahren zur Integration von
Softwaremodulen in eingebettete Systeme (Embedded Systems) definiert.
-
Bei
dem Verfahren werden bevorzugt entwickelte oder angepasste Softwaremodule
zwischen Entwicklungsteams zum Zwecke der Bildung einer einheitlichen
Produktsoftware ausgetauscht. Dabei ist bereits während der
Entwicklung bekannt, in welcher Produkthardware (Plattform) die
Produktsoftware ausgeführt
werden wird. Die Produkthardware kann dabei auch eine Gruppe von
Hardwareprodukten sein, die sich in den hierfür wesentlichen Eigenschaften
gleichen.
-
Die
Entwicklungsteams, welche die Module austauschen, sind in bezüglich der
Vertraulichkeit getrennten Organisationen tätig. Darunter können prinzipiell
auch Gruppen von Entwicklern innerhalb einer einzigen Organisation
verstanden wer den, die relativ strikt unabhängig voneinander ohne Wissensaustausch
entwickeln sollen, wobei dies sicher kaum üblich sein wird. In der Regel
wird es sich bei den Entwicklungsteams alternativ um in Konkurrenz
zueinander stehende Zulieferfirmen mit oder ohne Beteiligung eines
sogenannten OEMs (zum Beispiel ein Kraftfahrzeughersteller für Endverbraucher)
handeln.
-
Die
Speicherorganisation enthält
vorzugsweise feste bzw. definierte physikalische Adressen oder Adressbereiche
für definierte
Datentypen.
-
Es
ist bevorzugt, dass die ausführbaren
Softwareprogramme als Funktionssoftwareprogramme zum Betrieb eines
elektronischen Reglers ausgebildet sind und insbesondere jeweils
wenigstens eine Kraftfahrzeugregelungs- oder -steuerungsfunktion umfassen.
-
Zumindest
bezüglich
der ausführbaren
Softwareprogramme werden vorzugsweise keine Objektbibliotheken und/oder
Quelldateien zwischen den Entwicklungsteams ausgetauscht.
-
Unter
einem Austausch zwischen den Entwicklungsteams wird zweckmäßigerweise
ein beidseitiger Austausch als auch alternativ vorzugsweise ein
einseitiger Informationsfluss verstanden.
-
Die
Speicherorganisation wird bevorzugt in Form einer Header-Datei eines
Compilers zwischen den Entwicklungsteams ausgetauscht. Dabei umfasst
die Header-Datei insbesondere die Definition der Variablen der Programme.
-
Es
ist bevorzugt, dass in Abhängigkeit
der Speicherorganisation dem Rahmensoftwareprogramm und dem mindestens
einen Funktionssoftwareprogramm vor der jeweiligen Erzeugung der Programme
definierte Lese-Schreibe-Speicher-Adressbereiche und/oder -Adressen
und definierte Festwertspeicher-Adressbereiche
und/oder -Adressen als definierte Speicherschnittstellen zugewiesen
werden. Diese Zuweisung erfolgt insbesondere durch zumindest ein „hake-File".
-
Die
Produktsoftware wird zweckmäßigerweise
zumindest teilweise im Betrieb des elektronischen Reglers abgearbeitet.
-
Es
ist bevorzugt, dass wenigstens die ausgetauschten Softwaremodule
zu der einheitlichen Produktsoftware fusioniert werden.
-
Das
Rahmensoftwareprogramm umfasst vorzugsweise ein Überwachungsprogramm, welches die
Abarbeitung wenigstens eines der Funktionssoftwareprogramme, insbesondere
zur Laufzeit der Produktsoftware, überwacht. Dabei wird besonders
bevorzugt die Antwortzeit bzw. Ausführungsdauer eines definierten
Funktionssoftwareprogramms oder eines entsprechenden Teilprogramms
geprüft
bzw. überwacht.
Dies geschieht ganz besonders bevorzugt, indem bei Aufruf eines
Funktionssoftwareprogramms ein Zähler
erhöht
inkrementiert oder dekrementiert wird und anhand dieses Zählers nach
Abarbeitung dieses Funktionssoftwareprogramms die Ausgabe bzw. das
Vorhandensein von Übergabevariablen bzw.
Antwortdaten des abgearbeiteten Funktionssoftwareprogramms überprüft wird.
-
Unter
einem Beschreiben von Speicher wird bevorzugt ein „Flashen" bzw. ein Flashvorgang
eines Speichers, insbesonde re des Festwertspeichers des Mikroprozessorsystemmoduls,
verstanden.
-
Es
ist bevorzugt, dass die Abarbeitung des Rahmensoftwareprogramms
und des mindestens einen Funktionssoftwareprogramms in dem Mikroprozessorsystemmodul
des Reglers seriell oder alternativ vorzugsweise parallel bzw. „quasiparallel" durchgeführt wird.
-
Der
elektronische Regler wird vorzugsweise weitergebildet, indem das
Rahmensoftwareprogramm ein Überwachungsprogramm
umfasst, welches die Abarbeitung wenigstens eines der definierten
Funktionssoftwareprogramme überwacht.
-
Der
Regler umfasst bevorzugt zumindest ein Motor- und/oder Ventilansteuerungsschaltungsmodul,
wobei der Regler insbesondere als elektronisches Bremsensteuergerät ausgebildet
ist.
-
Es
ist zweckmäßig, dass
das Mikroprozessorsystemmodul zumindest einen Prozessorkern, mindestens
einen Lese-Schreibe-Speicher
und wenigstens einen Festwertspeicher (ROM) aufweist, wobei dem
Rahmensoftwareprogramm und dem mindestens einen Funktionssoftwareprogramm
gemäß der Speicherorganisation
definierte Lese-Schreibe-Speicher-Adressbereiche und/oder -Adressen
und definierte Festwertspeicher-Adressbereiche
und/oder -Adressen als definierte Speicherschnittstelle/n zuwiesen
sind.
-
Die
ausgetauschten Softwaremodule bzw. Funktionssoftwareprogramme sind
oder enthalten vorzugsweise sogenannte "*.exe-Dateien". Selbstverständlich fallen unter den Begriff "aus fährbare Softwareprogramme" auch solche ausführbaren
Programme, die eine andere Dateibezeichnung aufweisen. Die Quelldateien
werden hierzu insbesondere kompiliert und gelinkt. Es liegt somit
keine Symboltabelle vor, welche eine einfache Interpretation eines dekompilierten
Codes ermöglicht.
-
Die
ausführbaren
Softwareprogramme werden zweckmäßigerweise
vor dem Austausch zwischen den Entwicklungsteams zu einer gemeinsamen
Einheit bzw. zu der Produktsoftware zusammengefasst bzw. fusioniert.
Diese gemeinsame Einheit wird insbesondere gemeinsam „geflasht".
-
Neben
den ausführbaren
Softwareprogrammen wird vorzugsweise gleichzeitig oder zeitlich
getrennt zwischen den Entwicklungsteams zusätzlich zumindest eine Speicherorganisation
ausgetauscht. Mit der Speicherorganisation ist zumindest festgelegt an
welcher festen physikalischen Adresse das oder die ausgetauschten
ausführbaren
Softwareprogramme auf der Hardware der Produktsoftware ausgeführt werden.
Dies bietet den Vorteil, dass keine Symboltabellen für den Linker
ausgetauscht werden müssen.
Symboltabellen enthalten oftmals Variablennamen und Konstanten,
die in Klartext geschrieben sind und somit Rückschlüsse auf Programmeigenschaften
oder Programmroutinen enthalten können, die nicht an andere Entwicklungsteams
weitergegeben werden sollen.
-
Die
ausgetauschten Softwaremodule werden bevorzugt zu einer gemeinsamen
Software fusioniert. Man kann die Module daher auch als zu integrierende
Funktionen bezeichnen. Insbesondere wird die zu integrierende Funktion
jeweils in ein Rahmensoftwareprogramm eingebettet. Die „make-Files" für beide Funktionen
definieren besonders bevorzugt einen gemeinsam genutzten RAM-Bereich,
sowie ganz besonders bevorzugt auch die ROM-Adressen der gegenseitig
benutzten Funktionsaufrufe. Dabei definieren und ermöglichen
die „hake-Files" ein gemeinsames
Kompilieren und Linken mehrerer Programme und/oder Funktionssoftwareprogramme.
-
Vorzugsweise
wird die zu integrierende Funktion von einem Betriebssystem aufgerufen
und bezüglich
Laufzeit und Speicherzugriffen auf RAM-Variablen von dem Überwachungsprogramm überwacht.
-
Gleichzeitig
werden nach einer bevorzugten Ausführungsform des Verfahrens sowohl
das Rahmensoftwareprogramm als auch die Softwaremodule bzw. die
Funktionssoftwareprogramme zwischen den Entwicklungsteams ausgetauscht,
um Informationen der verwendeten RAM-Daten-Struktur auszutauschen,
weshalb das Rahmensoftwareprogramm und die Softwaremodule insbesondere
entsprechende Austauschmittel umfassen. Auf diese Weise ist es möglich, die
notwendige Datenkonsistenz sicherzustellen. Beispielsweise wird
hierzu eine Überwachung
der Länge
des insgesamt ausgetauschten Speicherbereichs des RAMs vorgesehen.
Nach einem anderen Beispiel wird der RAM-Definitionsdatei (z. B. *.h in der Programmiersprache
C) ein eindeutiges Indentifiziermittel (Identifier) zugewiesen,
welches auf Gleichheit der Verwendung in Funktions- und Rahmensoftwareprogramm überprüft wird.
Hiermit wird eine größtmögliche Sicherheit
für das
Gesamtsystem bzw. für
die gesamte Produktsoftware bzw. für den elektronischen Regler
mit der Produktsoftware gewährleistet.
Abhängig
vom Fehlerfall kann dann nur die integrierte Teilfunktion oder das Gesamtsystem
abgeschaltet werden. Dieser Zustand kann insbesondere besonders
einfach über
eine Statusinformation zur späteren
Fehleranalyse bereitgestellt werden.
-
Eine
Softwarefunktion bzw. ein Softwaremodul wird bevorzugt in einem "Embedded System" wird als Teilfunktion
integriert. Bei der Teilfunktion handelt es sich insbesondere um
zumindest eine sogenannte "Executables-Datei".
-
Es
wird vorzugsweise eine Überprüfung der Schnittstellendokumente
durchgeführt.
-
Ein
Mapping von RAM und/oder ROM wird bevorzugt beim Linkvorgang fest
vorgegeben.
-
Es
ist zweckmäßig, dass
eine Speicherüberwachung
(Memory Protection) durchgeführt
wird bzw. dass das Mikroprozessorsystemmodul des elektronischen
Reglers eine Speicherschutzeinheit bzw. ein „Memory Protection Modul" aufweist.
-
Die
Laufzeit (Runtime Monitoring) wird vorzugsweise überwacht.
-
In
einem Fehlerfall, welcher insbesondere von dem Überwachungsprogramm identifiziert
wird, werden bevorzugt Bereiche eines Softwaremoduls „stillgelegt" bzw. deren Abarbeitung
wird gestoppt und ein neuerlicher Aufruf wird bis auf weiteres blockiert,
zum Beispiel bis zu einer neuen Initialisierung der entsprechenden
Softwarefunktion.
-
Unter "Flashen" wird ganz vorzugsweise
die Produktion von verkaufsfertiger Software in jeder denkbaren
Ausprägung
verstanden werden (z. B. Flash-ROM, ROM, Download etc.).
-
Durch
das Verfahren zum Beschreiben von Speicher wird eine separate Flashbarkeit
und somit unabhängige
Entwicklungstätigkeit
ermöglicht.
-
Die
Erfindung bezieht sich außerdem
auf die Verwendung des elektronischen Reglers in Kraftfahrzeugen.
-
Der
elektronische Regler ist vorzugsweise zur Verwendung im Bereich
der Kraftfahrzeugelektronik, insbesondere der Bremsenregelung, Fahrwerkregelung,
aktiven Fahrzeugsicherheitsregelung und/oder in passiven Fahrzeugsicherheitssystemen, vorgesehen.
-
Weitere
bevorzugte Ausführungsformen
ergeben sich aus den Unteransprüchen
und der nachfolgenden Beschreibung von Ausführungsbeispielen an Hand von
Figuren.
-
Es
zeigen in schematischer Darstellung
-
1 eine
Darstellung unterschiedlicher, beispielhafter Möglichkeiten der Integration
von Softwaremodulen in eine einheitliche Produktsoftware und
-
2 eine
Prinzipdarstellung eines Beispiels der Integration eines von einem
anderen Entwicklungsteam bereitgestellten Softwaremoduls in eine
einheitliche bzw. gemeinsame Produktsoftware.
-
Der
beispielhafte elektronische Regler 4 in 1 umfasst
ein Mikroprozessorsystemmodul (μC), das
einen Speicher aufweist, in dem eine Vielzahl von Regel- und Steuerfunktions softwareprogrammen und Überwachungsfunktionen
gespeichert sind. Beispielgemäß als Regler
bzw. Steuergerät
für ein
elektronisches Kraftfahrzeugbremssystem ausgebildet, sind dies zum
Beispiel die Kern-Funktionssoftwareprogramme 5 „Core Functions", wie zum Beispiel
ein Antiblockierregelungs-Funktionssoftwareprogramm ABS
oder ein Fahrdynamikregelungs-Funktionssoftwareprogramm.
Weiterhin sind häufig
sogenannte Zusatz-Funktionssoftwareprogramme 6 "Add-On Functions" im Speicher des
Reglers enthalten, die nicht unmittelbar zu den Hauptfunktionen
des Reglers gehören.
So ist beispielgemäß im Regler
bzw. Bremsensteuergerät 4 auch
ein Verfahren zur Erkennung eines Reifendruckverlusts als DDS-Funktionssoftwareprogramm 7 enthalten.
Symbolisch sind weitere Zusatz-Funktionssoftwareprogramme 8, 9 mit den
Buchstaben "A" und "B" gekennzeichnet. Neben den Kern-Funktionssoftwareprogrammen 5 und
den Zusatz-Funktionssoftwareprogramme 6 umfasst
die Software in Bremsensteuergerät 4 in
der Regel noch Systemprogramme 10, welche für den Betrieb
des Steuergeräts
unmittelbar notwendig sind. „Core Functions" 5 und "Add-On Functions" 6 werden
auch als Softwarekomponenten bezeichnet.
-
Auf
dem Wege bis zur Fertigstellung eines gebrauchsfähigen Bremsensteuergeräts 4 mit
entsprechender, gebrauchsfähiger
Produktsoftware werden in manchen Fällen, wie auch beispielgemäß, ein weiteres
Zusatz-Funktionssoftwareprogramm 11 importiert Pfeil 1,
das nicht vom Hersteller des Bremsensteuergeräts 4 stammt bzw. nicht
von diesem entwickelt wurde. So kann es beispielsweise sein, dass der
OEM oder ein Fremdhersteller, beispielsweise ein weiterer Zulieferer,
Funktionssoftwareprogramme für
die Produktsoftware des elektronischen Reglers bereitstellen soll
bzw. im Bremsensteuergerät 4 un terbringen
möchte.
Ein Import von systemspezifischer Software 12 bzw. von
entsprechenden Funktionssoftwareprogrammen, wie beispielsweise Low Level-Treiber,
Kommunikationssoftware, ist ebenfalls denkbar, beispielgemäß symbolisiert
durch Pfeil 3. Es kann aber auch umgekehrt sein, dass Funktionen bzw.
Funktionssoftwareprogramme des besagten Steuergeräteherstellers
in Steuergeräten
anderer Zulieferer oder in Steuergeräten des OEMs, ausgeführt werden
sollen, also ein sogenannter Export von Funktionssoftwareprogrammen 7,
symbolisiert durch Pfeil 2.
-
In 2 wird
am Beispiel des DDS-Funktionssoftwareprogramms 7 veranschaulicht,
wie dieses in die Produkthardware eines Fremdherstellers integriert
wird. Zunächst
wird eine Software-Entwicklungsumgebung vom Fremdhersteller bereitgestellt. Diese
liefert ein Rahmensoftwareprogramm 18, welches Schnittstellen
definiert. Diese Definition erfolgt üblicherweise in einer Header-Datei.
Die Definition enthält
beispielsweise die Versionsnummer der Schnittstellendefinition und
eine Definition der von diesem Programm benötigten Schreibe-Lese-Speicher-Adressebereich 16 im
Teilbereich des Schreibe-Lese-Speichers RAM, 15 der Produkthardware bzw.
des Mikroprozessorsystemmoduls 14 dieser Produkthardware,
wobei diese Definition beispielgemäß in einem „hake-File" hinterlegt ist. Die Definition der
Schnittstellen wird an den Fremdhersteller vorab übergeben.
Das Entwicklungsteam, welches DDS-Funktionssoftwareprogramm 7 entwickelt,
erzeugt im Rahmen der Entwicklung ein ausführbares Softwareprogramm, das
beispielgemäß die Informationen
Startadresse der Init-Routine 19,
Startadresse der Main-Routine 20 und Startadresse der Messroutine 21 im
Festwertspeicher 13 des Mikroprozessorsystemmoduls 14 enthält. Nach Übergabe
des DDS- Funktionssoft-wareprogramms 7 (Pfeil 2 in 1)
an den Fremdhersteller der Ziel-ECU bzw. der Produkthardware bzw.
des entsprechenden elektronischen Regler, integriert der Fremdhersteller
unter Verwendung der obigen Definitionen DDS-Funktions-softwareprogramm 7 als
ausführbares
Softwareprogramm in dessen Software, welche im verbrauchsfähige, einheitliche
Produktsoftware in den Festwertspeicher 13 geschrieben
wird. Neben DDS-Funktionssoftwareprogramm 7 umfasst Festwertspeicher 13 noch
andere Funktionssoftwareprogramme 17. In dem Festwertspeicher-Adressbereich der
anderen Funktionssoftwareprogramme 17 sind beispielgemäß auch Programme
für die
CAN-Ansteuerung, für
Diagnoseroutinen und EEPROM-Schnittstellenprogramme hinterlegt.