Programmiersprache in Automotive-Systemen

Modellbasierte Entwicklung mit Matlab/Simulink oder Ascet wird gerne 
verwendet, aber nicht nur. Viel wird auch direkt in C oder bei 
Multimedia-Zeugs auch in Java gemacht. Kommt hald drauf an welches Tool 
für welches Projekt am besten taugt und ob die Software 
sicherheitskritisch ist oder nicht. Bei Matlab/Simulink kommt übrigens 
auch erstmal automatisch generierter C-Code raus...

Leider wird im Automotive-Bereich so ziemlich alles verwendet. 
Hauptsache, das Tool hat eine Zertifizierung und ist somit teuer.
(Aber nicht unbedingt besser, da viel weniger Nutzer da sind um Bugs zu 
finden)

Über Sinn und Unsinn automatischer Toolketten wie Programmierung mit 
Matlab lässt sich auch streiten. Meine Meinung: Je komplexer desto mehr 
mögliche Fehlerstellen.

Was macht den dieser automatisch generierte C-Code?

Ist das mehr als die Parameter für die PID Regler zu setzen oder States 
einer State-machine zu konfigurieren?

Kann man sich da auch einen Treiber zusammen klicken? (so richtig schön 
low-leveliges register/bit schubsen)

Welche Steuergeräte?

Motorsteuergerät?
Steuergerät für ein Getriebe?
Steuergerät für den Fensterhebermotor?
Steuergerät für den Schalter für den Fensterheber?
Steuergerät an der Droselklapenenheit?
Radio / Multimedia?

Autocode hin oder her.
Man braucht aber auch ein Framework aus Betriebssystem mit 
Peripherietreibern, Kommunikations-Stacks, ect. in das der generierte 
Code eingebettet wird.
Dieses 'Framework' ist fast immer in 'C', wenn nicht sogar in Assembler 
codiert.
Wie schon vorher gesagt, erzeugen die Codegeneratoren aus den 
(graphischen) Modellen auch erst einmal Java- oder C-Code, der dann ins 
Framework integriert wird und mit entsprechenden Compilern in ein 
ausführbares File übersetzt wird.

P.S.: Bei sicherheitskritischen Systemen geht nichts über C wenn nicht 
sogar ADA.

123 schrieb:
> Steuergerät an der Droselklapenenheit?

Was bitteschön soll das denn sein?

Bei sicherheitsrelevanten System ist es wohl zu 99,9 % C.
Da für C automatisierte Test Tools wie zb für MISRA verfügbar sind und 
auch angewendet werden (müssen).
Das restliche 0,1 % ist dann Assembler. Der wird aber nur da eingesetzt 
wo es nicht anders machbar ist. Zb der Teil des OS Scheduler der dann 
die eigentliche Taskumschaltung macht. Also die Register, Stackaddresen, 
Programmcounter,.... umschaltet.
Das Problem beim Assembler ist dann die Prüfung des Codes auf 
Funktion,Logikfehler, Überläufe,... das geht nur Per Hand und nicht 
automatisiert. ==> Große Aufwand und damit Teuer

Ob dieser C-Code jetzt Manuell oder per Codegenerierung erzeugt wird ist 
wieder ein anderes Ding.

Codegeneratoren sind zb Matlab/Simulink, oder auch AUTOSAR Toolsets.
Wobei hier Matlab/Simulink auf der Ebene der Regelkreise vertreten ist.
Die AUTOSAR tools sind dann mehr auf IO und OS Bereichen unterwegs.

Allerdings wird auch noch sehr viel in den sicherheitskritischen 
Bereichen per Hand codiert.
Das liegt ganz einfach daran das jedes Tool zertifiziert und freigegeben 
sein muss. Und dieser Aufwand ist gewaltig, damit wieder Teuer.


Also wenn du dich mit Codegenerierung beschäftigst kann das nicht 
Schaden
, allerdings solltest du C nicht außen vor lassen.

Ohne Auto schrieb:
> Was macht den dieser automatisch generierte C-Code?
>
> Ist das mehr als die Parameter für die PID Regler zu setzen oder States
> einer State-machine zu konfigurieren?

Der automatisch aus einem Modell generierte Code kann prinzipiell alles 
machen, Peripherietreiber, Kommunikations-Stacks, Task-Managemnt usw. 
überläßt man aber normalerweise der Basis-Software des Steuergeräts.
Die Regler baut man dann aber z.B. komplett modellbasiert auf, also 
Struktur+Parameter, Fehlerreaktionen usw.

Okay danke für eure Tipps, d.h. mit C, C++ ist man nicht beim alten 
Eisen...
Könnte es evtl. sein dass solche allgemeinen Programmiersprachen den 
Vorteil haben dass man quasi alles machen kann, also beliebige 
"ungewöhnliche" Datenstrukturen & Algorithmen verwenden, an die die 
LabView/Simulink/... -Entwickler nicht gedacht haben?

Floh schrieb:

> Über Sinn und Unsinn automatischer Toolketten wie Programmierung mit
> Matlab lässt sich auch streiten. Meine Meinung: Je komplexer desto mehr
> mögliche Fehlerstellen.

Meinnung? Interessant sind nur Fakten.