Hallo Forum, mir hat jemand erzählt dass für Automotive-Steuergeräte heute ausschließlich grafische Programmiersprachen wie Simulink oder LabVIEW verwendet werden, da die einfacher & besser für große Systeme geeignet sind als C oder C++. Stimmt das? Wenn man bereits gut C und C++ kann, lohnt es sich den Umgang mit solchen Systemen zu lernen, wenn es sonst keinen Grund dazu gibt (wie zB bestehende Projekte oder Mit-Programmierer die nur solche Systeme beherrschen)?
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.