Guten Tag,
an die Profis, die momentan in der Fahrzeugindustrie arbeiten oder
kürzlich gearbeitet haben: Welche Programmiersprachen werden zu welchem
Zweck in der aktuellen Fahrzeugentwicklung eingesetzt? Nach Durchsicht
einiger Stellenanzeigen bei den üblichen Herstellern, konnte ich bisher
Folgendes rausfiltern:
- Die Hersteller bauen sich ihre eigene Linux Distribution mit Yocto.
- Das Linux wird für das Multimediasystem verwendet.
- Es wird sehr häufig C und C++ nachgefragt.
1. Der Linux Kernel ist komplett in C geschrieben. Wird C oder
mittlerweile C++ für die Treiberentwicklung eingesetzt?
2. Wird die Software der ganzen Controller für die Assistenzsysteme in C
oder mittlerweile in C++ entwickelt?
3. Das MMI ist vermutlich eine in QT entwickelte GUI, die auf Linux
läuft und in C++ entwickelt ist?
Ich freue mich über euer Feedback.
Chris R. schrieb:> µC Ebene C oder C++, µP Ebene gerne mal Java auf Applikationsebene> mit irgend nem Linux/Android drunter.
Wird für die Microcontroller mittlerweile überwiegend C++ bzw. ein
Embedded C++ verwendet bzw. oder doch eher reines C? Ich habe kürzlich
in einer Meldung gelesen, dass BMW nur noch auf C++ / Embedded C++
einsetzt.
Für C++ gibt es ja auch die entsprechenden MISRA C++ und Autosar
Richtlinien. Wie sieht denn die Verteilung von C und C++ in der
moderenen Fahrzeugsoftwareentwicklung aus? Gibt es die Tendenz, dass für
Neuentwicklungen nur noch C++ eingesetzt wird?
BobDerBaumeister schrieb:> Ich habe kürzlich in einer Meldung gelesen, dass BMW nur noch auf C++ /> Embedded C++ einsetzt.
Embedded C++ ist tot, wenn schon wird das richtige C++ benutzt:
https://de.wikipedia.org/wiki/Embedded_C%2B%2B?wprov=sfla1
Ansonsten ist natürlich fast alles C. Embedded Entwickler sind meist
Ingenieure/Quereinsteiger, deren Programmierkenntnisse sich auf den
"Einführung in die Programmierung"-Kurs aus dem 1. Semester beschränken,
und dort wurde anno 1995 halt C gelehrt, daher ist C ergo der Weisheit
letzter Schluss und wird als einziges zugelassen. Wenn man als dummer
Informatiker dazu kommt und vorschlägt man könnte ja mal C++ probieren,
kommen Fackeln und Mistgabeln. Daher ist C in der Industrie so sicher
wie das Amen in der Kirche.
Softwerker schrieb:> ...deren Programmierkenntnisse sich auf den> "Einführung in die Programmierung"-Kurs aus dem 1. Semester beschränken,> und dort wurde anno 1995 halt C gelehrt...
Na, das wäre dann ja schon richtig fortschrittlich gewesen. Habe zu der
Zeit Elektrotechnik studiert; im ersten Semester Einführung in Pascal,
und im vierten Semester ging es mit Fortran77(!) weiter. Lag vermutlich
daran, daß im Rechenzentrum nur eine MicroVax verfügbar war, auf der
kein C-Compiler lizenziert war. Na ja, im Studiengang Technische
Informatik kamen meine Kommilitonen dem Hörensagen nach irgendwann im
Hauptstudium auch mal mit C in Berührung.
BobDerBaumeister schrieb:> 1. Der Linux Kernel ist komplett in C geschrieben. Wird C oder> mittlerweile C++ für die Treiberentwicklung eingesetzt?
Kein C++.
Es gibt derzeit Bestrebungen für Rust und letztens kam Hare auf.
Das ist aber alles Zukunftsmusik.
Ich arbeite auch in der Autoindustrie und kann meinen Vorrednern nur
zustimmen: C, wohin das Auge blickt... (Oder eben Matlab, wobei da auch
wieder C-Code rausfällt.)
Softwerker schrieb:> daher ist C ergo der Weisheit letzter Schluss und wird als einziges> zugelassen. Wenn man als dummer Informatiker dazu kommt und vorschlägt> man könnte ja mal C++ probieren,
Kein Autokonzern kann es sich leisten, einen ganzen Pentium zu
verschleissen bloss um den Blinker blinken zu lassen.
Obwohl theoretisch in C++ so effizient programmiert werden kann wie in
C, strandet der Überblick sich verzettelnder Informatiker so früh, dass
hinterher der Softwarehaufen doch 100 (oder gar 1000) mal langsamer ist,
und entsprechend mehr Hardwareresourcen verschleisst.
Das ist halt die Realität, da hilft kein theoretisches Gesülze.
Und dann neigen C++ Compiler zu mehr Compilerfehlern als C, deren Suche
(und nachfolgende Umgehung, denn gefixt werden kann der Compiler nicht
vom Anwender) kostet in der kommerziellen Softwareentwicklung einfach zu
viel Geld.
Daher: keep it simple.
Zur Umsetzung von autonomen Fahren ist dann weder C noch C++ high level
genug.
ziege schrieb:> (Oder eben Matlab, wobei da auch> wieder C-Code rausfällt.)
Das finde ich auch soo seltsam. Es wird immer für C argumentiert weil
man dann "alles unter Kontrolle hat". Aber wenn Matlab einen
BlackBox-mäßigen C-Code fragwürdiger Qualität erzeugt ist es ok? Dieser
klassische C-Code ist ja meistens stark prozedural strukturiert,
Patterns werden verabscheut, aber dieses Flussmodell-Pattern von Matlab
ist plötzlich auch ok. Es ist also nur super low-level (C prozedural)
und super high-level erlaubt (modellbasiert Matlab), alles andere ist
böse. Versteh einer die Ingenieure.
Ich hab gerade meinen Job gewechselt, aber zuvor noch ein relativ
kompliziertes Projekt in C++ fertig gestellt (funktioniert!). Ich wüsste
zu gerne ob die C-Apologeten das jetzt in C neu machen, wenn sie merken
dass ich es in C++ gemacht habe, obwohl das Projekt "standalone" ist und
nicht in anderen Code integriert wird. Der Code ist natürlich sehr
effizient, das habe ich teilweise gegen den Willen der Ingenieure
durchsetzen können. Leider nur teilweise, denn einen wichtigen
Algorithmus durfte ich nicht parallelisieren, wodurch die Laufzeit jetzt
um den Faktor 10 zu hoch ist, weil den Ingenieuren das sonst "zu
kompliziert" sei.
MaWin schrieb:> Das ist halt die Realität, da hilft kein theoretisches Gesülze.
Das ist alles totaler Blödsinn. Informatiker wissen oft sehr viel besser
was effizient ist und was nicht, und können in C++ wunderbar effizienten
Code produzieren. Aber hier sehen wir die Mistgabeln, schön!
MaWin schrieb:> Und dann neigen C++ Compiler zu mehr Compilerfehlern als C
Alte Mythen. C++ ist 40 Jahre alt, und C 50, deswegen soll C so viel
stabiler sein? In C++ kann man Code viel sicherer schreiben sodass
Fehler viel früher gefunden werden. In C darf man fleißig debuggen.
MaWin schrieb:> Daher: keep it simple.
Auch wieder typische Ingenieurs-Denke: Ingenieurs-Zeug darf beliebig
komplex sein, aber das wovon sie keine Ahnung haben (Programmieren) muss
dann möglichst stupide sein damit sie noch mitkommen. "Keep it simple"
kann auch heißen dass der Code kurz und übersichtlich ist, und keine
Wüste an aussageschwachem C-Code.
Softwerker schrieb:> Das ist alles totaler Blödsinn.
Parallelwelt ? Du musst Programmierhansel sein. Es fällt 100% aller
Anwender auf, dass trotz massiv gestiegener Hardwareperformance die dem
Benutzer relevante Performance nicht besser geworden ist, dafür die
Programme grösser und nun mit C++ statt C geschrieben wurden. Schön z.B.
das Remake von PaintShopPro als Paint.Net, weitgehend dieselbe Funktion
aber einfach viel schlechter.
Softwerker schrieb:> Alte Mythen. C++ ist 40 Jahre alt,
Doch ein Softwerker verwendet tunlichst jetzt schon C++23, er glaubt
doch damit der schärfte Hansel von allen zu sein.
Nein, ich habe ich oft genug mit Compilerfehlern rumplagen dürfen, sie
isolieren, umgehen, als BugReport an den Hersteller wie Borland, IBM,
Keil, Intel geben dürfen, bestätigt bekommen, und als sie gefixt waren,
war es mir eigentlich egal da mein Code ihn umgeht, der bleibt dann eben
so (bzw. statt Borland dann eben Microsoft-C).
Aber du musst noch Anfänger sein mit einfachsten Schulbuch-Algorithmen,
wenn dich in deiner Arbeit noch keine Compiler-Fehler behindert haben.
Softwerker schrieb:> Auch wieder typische Ingenieurs-Denke:
Ja, nun, Erfahrung. Mit Kindergartendenke kommt man nicht weit.
Hier sehen wir auch die sozialen Fähigkeiten von Ingenieuren in Aktion.
Noch ein Grund, nicht in der Ingenieurs-Welt zu arbeiten und unter
zivilisierten Menschen zu bleiben. Leider sagt einem das keiner wenn man
sich auf Embedded Systems spezialisiert.
Softwerker schrieb:> as finde ich auch soo seltsam. Es wird immer für C argumentiert weil> man dann "alles unter Kontrolle hat". Aber wenn Matlab einen> BlackBox-mäßigen C-Code fragwürdiger Qualität erzeugt ist es ok?
Naja, das hat verschiedene Gründe:
1.)Ich kann einen Regelungstechniker ohne Programmiererfahrung
hinsetzen, um um eine Motorregelung in Matlab/Simulink zu entwerfen.
2.)Der Matlab-Codegenerator ist zertifiziert, also ist auch der Code,
der herauskommt zertifiziert. Da hat die Automobilindustrie einen
ziemlich schrägen Fetisch dafür. Außerdem kann man damit super
Verantwortung abgeben, sich Tests ersparen,... (Das ist jetzt nicht
meine persönliche Meinung, aber das was die Erfahrung zeigt.)
Softwerker schrieb:> Hier sehen wir auch die sozialen Fähigkeiten von Ingenieuren in Aktion.
Ärger' dich nicht, dieses Forum ist völlig verwahrlost und hat eine
legendär schlechte Kultur. Manchmal gibt es sinnvolle Diskussionen, aber
leider driftet das hier oft in geflame/getrolle durch die immer selben
Personen ab.
Softwerker schrieb:> Das finde ich auch soo seltsam. Es wird immer für C argumentiert weil> man dann "alles unter Kontrolle hat". Aber wenn Matlab einen> BlackBox-mäßigen C-Code fragwürdiger Qualität erzeugt ist es ok? Dieser> klassische C-Code ist ja meistens stark prozedural strukturiert,> Patterns werden verabscheut, aber dieses Flussmodell-Pattern von Matlab> ist plötzlich auch ok. Es ist also nur super low-level (C prozedural)> und super high-level erlaubt (modellbasiert Matlab), alles andere ist> böse. Versteh einer die Ingenieure.
Früher hat man wegen Zertifizierung und weil besserer Code rauskam da
Targetlink genommen, inzwischen hat der Embedded Coder da aber massiv
aufgeholt. Und was soll da blackbox sein? Mann kann genau nachverfolgen
welcher Teil vom Modell was ist wenn man will. Von Hand im Autocode
rumbasteln sollte man eh nicht weil dass immer wieder Modell nicht mehr
zum Code passt und man irgendwo bei MIL/SIL/PIL rausfliegt weil es nicht
das tut was es soll.
ziege schrieb:> 2.)Der Matlab-Codegenerator ist zertifiziert, also ist auch der Code,> der herauskommt zertifiziert. Da hat die Automobilindustrie einen> ziemlich schrägen Fetisch dafür.
ISO26262 ist kein schräger Fetisch sondern Lessons Learned aus vielen
Idiotenfehlern und Schlampereien in der Vergangenheit die Menschenleben
gekostet haben.
MISRA ähnlich.
Anja schrieb:> Die ganz harten nehmen SCADE von Esterel.
Weshalb gehören die zu den ganz harten? Frage nur aus Neugier, selber
hab ich das nie gemacht aber ich kenne Leute, die damit arbeiten. Habe
mich aber nie erkundigt wie "hart" die sind ;)
Chris R. schrieb:> ISO26262 ist kein schräger Fetisch sondern Lessons Learned aus vielen> Idiotenfehlern und Schlampereien in der Vergangenheit die Menschenleben> gekostet haben.
Ist mir schon klar, meine Spitze hat sich auch nicht gegen die ISO26262
oder MISRA gerichtet. Mir gings da mehr um Diskussionen, ob MS Word
zertifizierbar ist und die Mentalität die sich (meiner Erfahrung nach)
immer wieder einschleicht, bei der Hirn und Verantwortung an die/eine
Norm abgegeben werden.
Es kommt auf die Steurgerätegröße an, was da für ein OS drin ist und
welche Programmiersprache zum Einsatz kommt.
Auf kleineren Steuergeräten findet man Autosar mit C und/oder C++. Die
beiden sind oft kombiniert. Als Compiler kommen oft die größeren
Hersteller zum einsatz (Greenhills, Windriver, Lauterbach etc.) , weil
die die entsprechende Qualifizierung haben. Oft werden Teile der SW mit
Simulink Modeliert, wodurch aber dann eh C oder C++ generiert wird,
wobei der Embedded Coder inzwischen ziemlich brauchbare Ergebnisse
liefert.
Als Coding-Rules können MISRA oder auch andere Sachen verwendet werden,
jedes Unternehmen hat da eine eigene Strategie bzw. eigenen Ruleset.
ISO26262 ist durch Zulassungsbehörden vorgeschrieben, sonst kriegt man
keine Serienzulassung. Der OEM schreibt es dann einfach bei der
Projektausschreibung dem Zulieferer vor, ob ASIL A oder B, C, D erfüllt
werden müssen. Ohne Erfüllung bekommt man das Projekt einfach nicht.
Bei Mittelgroßen ECUs kommt QNX, Integrity und neuerdings Yocto zum
Einsatz. Hier ist ebenfalls die Kombination aus C u. C++ am Häufigsten.
Im Infotainmentbereich ist sehr oft Linux als Basis und darauf sitzt
entweder auf einem Hypervisor oder in Containern ein oder mehrere
Android-Systeme. Manchmal ist hier Autosar entweder auf dem Hypervisor
oder im Container oder auf einem separaten Mikro vorhanden.
Die Fancy-Guis werden sehr häufig, aber nicht ausschließlich mit Qt,
Altia, Unreal Engine usw. erstellt. Hier fällt dann ein Generierter Code
raus.
In den Toolchains kommen dann weitere Sprachen hinzu, wie z.B. Python,
Perl ...
Meine Meinung zu den Programmiersprachenverwendung: Wenn man die Syntax
einer Sprache gelernt hat - kann man dann noch lange nicht wirklich
programmieren, es ist die Erfahrung und viele andere Skills notwendig.
Anders herum ein Erfahrener Programmierer hat es ziemlich leicht, sich
eine andere Programmiersprache anzueignen. Am besten man sammelt mit
einer bestimmten Sprache Programmiererfahrung. Ein Guter
Informatiker/Ingenieur/Programmierer sollte doch eh permanent sein
ganzes Berufsleben lernen.
