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.
µC Ebene C oder C++, µP Ebene gerne mal Java auf Applikationsebene mit irgend nem Linux/Android drunter.
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?
Ich sehe kein C++, eher graphische Modell-Entwicklungen mit Matlab/Simulink oder ETAS ASCET. Die ganz harten nehmen SCADE von Esterel. Gruß Anja
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.
Wer kein C kann ist eh ein Noob...
Ich wollte keinen Streit zu C vs. C++ auslösen. Also bleibt bitte nett zueinander ;).
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.
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.