Hallo, ich bin noch im Studium und habe gesehen, dass ziemlich viele Leute für die Kfz-Steuergeräteentwicklung mit Matlab/Simulink gesucht werden. Ich habe noch nie mit Matlab/Simulink gearbeitet, habe aber natürlich Vorlesungen zu C später zu C++. Wenn man später mit Matlab/Simulink arbeitet, programmiert man dann eher wie in C oder objektorientiert wie in C++? Vielen Dank, Philipp
Komm doch zu uns und schaue es dir an. ;)
Auto, Autosar, physikalische Anbindungen und Matlab/Simulink sind noch Domäne von C. Entgegen vieler OOP-Beispiele mit Autos bringt OOP relativ wenig für konkrete Objekte der realen Welt sondern spielt ihr Potential mehr bei virtuellen digitalen Objekten und Daten aus. Also solche, die man digital speichert und bearbeitet. Ein Rad hinten links hat nit dem vorne rechts oder mit dem Reserverad wenig gemein. Und die Möglichkeit, ein 6tes, 7tes oder achtes zu Instanziieren und zu überladen ist in einem Auto weder Killerfeature noch Produktivitätsvorteil. Da C++ aber grob gesagt eine Obermenge von C ist, und C nach Ansicht vieler "Experten" veraltet und primitiv ist, wird zum Ende Deines Studiums vielleicht C++ dominieren.
Was ist das für ein Studium bei dem man ohne Matlab/Simulink arbeitet? Bei mir war das schon vor über 20 Jahren Teil des Studiums (technische Informatik) und es ist mir seither auch immer im beruflichen Alltag begegnet. Seit Autosar in den breiteren Einsatz geht wird es im Automotive stärker verwendet. Aber es ist nicht neu. Wichtig ist das man die symbolische Darstellung der Funktionen versteht. mit C oder C++ hat das weniger zu tun. Eher mit UML Aber vor allem mit Physik und Mathematik.
Volle schrieb: > Was ist das für ein Studium bei dem man ohne Matlab/Simulink arbeitet? Informatik zB. Dort arbeitet man mit richtigen Programmiersprachen ;-) die Matlab Sprache hat ja kein Typsystem und keine klare Syntax usw... Achim S. schrieb: > Entgegen vieler OOP-Beispiele mit Autos bringt OOP relativ wenig für > konkrete Objekte der realen Welt sondern spielt ihr Potential mehr bei > virtuellen digitalen Objekten und Daten aus Die Diskussion schon wieder... man muss bei OOP nicht notwendigerweise Räder modellieren. Wie wäre es mit Pins vom Controller, Threads, Listen, Automatischen Locks, Patterns wie Observer, Strategy und State? Die sind bei komplexen Systemen sehr hilfreich, und gerüchteweise sind Auto-Steuerungen genau das. Außerdem ist OOP nur eines von vielen durch C++ unterstützten Paradigmen. Einige davon sind auch für Embedded sehr nützlich (wie constexpr und Metaprogrammierung). Das sieht man schon an den Algorithmen - in C++ gibt es min/max Funktionen, in C kann man eine solche nicht sinnvoll inpmemenrieren... Es mag dennoch Gründe für C geben, aber dieses übliche "OOP bringt bei embedded nichts" ist völlig verkehrt. Der Hauptgrund ist vermutlich schlicht Unkenntnis über die Vorteile abstrakter Programmierung.
Philipp M. schrieb: > Wenn man später mit Matlab/Simulink arbeitet, programmiert man dann eher > wie in C oder objektorientiert wie in C++? Am ehesten wie in C. Ich wüsste jetzt nicht, wie man ein MATLAB/Simulink-Modell objektorientiert aufbauen will. Das wird dann nur noch mega-konfus. oO Du klickst deine Modelle in MATLAB zusammen, drückst auf einen Knopf und hinten purzelt C-Code raus, den dann der Entwickler (weil meistens eher Maschbauer und kein gelernter SW-Entwickler) nicht versteht. Dann werden noch prophylaktisch eine oder mehrere statische Code-Analysen drüber laufen gelassen und Modell und Code dem Tester über den Zaun geschmissen. Der hat dann meistens schon eher Ahnung von C (muss aber nicht sein ^^). Und ganz am Ende kriegt's dann der Integrator, das ist dann letztendlich der eine, der noch von C-Programmierung Ahnung hat. Tl;dr: Wenn du mit MATLAB/Simulink entwickelst brauchst du eigentlich gar kein Wissen von Programmiersprachen. Leider.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Volle schrieb: >> Was ist das für ein Studium bei dem man ohne Matlab/Simulink arbeitet? > > Informatik zB. Dort arbeitet man mit richtigen Programmiersprachen ;-) > die Matlab Sprache hat ja kein Typsystem und keine klare Syntax usw... Wenn es bei Informatik nur darum geht irgendwelche Computersprechen zu lernen. Bei uns ging es darum das Problem erst mathematisch zu lösen bevor man eine Software baut. Wir haben auch Schaltungen zuerst in PSpice untersucht bevor wir sie in echt im Labor gemessen haben. In Summe haben wir dutzende Computersprachen gelernt, aber nie als Selbstzweck. Außer bei Compilerbau die selbst erfundenen. Das hilft aber neue Sprechen zu verstehen. C++ wäre für Automotive sehr gut geeignet. aber die Tools sind noch nicht soweit und die Mitarbeiter noch viel Weniger. Und da die Chefs der Meinung sind Code wird generiert (von z.B Matlab) und niemand muss mehr programmieren können, wird sich das in den nächsten Jahrzehnten auch nicht ändern.
Dr. Sommer schrieb: > dieses übliche "OOP bringt bei embedded nichts" Das habe ich auch weder gesagt noch gemeint. C++ oder OOP hat viele Vorteile, auch im Embedded und auch auf kleinsten Rechnern. Aber halt eher für virtuelles, du hast gute Beispiele aufgezählt. Auch die komplette Signalverarbeitung für autonomes fahren z.b., wo Umgebung und Navigation rein virtuell abstrahiert werden muss. Nur bei der Steuerung konkreter Objekte führt OOP regelmäßig zu Spaghetti - Code.. anders ist es kaum zu erklären, warum es C überhaupt noch gibt. C++ ist ja bei Vermeidung weniger Konstrukte (z.b. RTTI) genauso performant, selbst auf 8.bittern
Es liegt eher daran das Automotive sehr konservativ ist und sehr lange Entwicklungszyklen hat. Das sieht man an Autosar. Nach 12 Jahren haben es jetzt ein paar wenige Projekte die Serie erreicht. Dabei ist das technologisch aus den 90ern und kein großer Schritt. Und andere Emebded Bereich sind noch konservativer da gibt es noch Diskussionen ob man auf 32Bit Prozessoren wechseln soll.
Volle schrieb: > Wenn es bei Informatik nur darum geht irgendwelche Computersprechen zu > lernen. > > Bei uns ging es darum das Problem erst mathematisch zu lösen bevor man > eine Software baut. Denkst du du kannst jetzt richtigen Informatikern erzählen wie man ein Problem löst? Weil du wohl einen extrem komischen Tech. Informatik Studiengang erwischt hast der sich zwischen Fachinformatiker und Elektriker ansiedelt? Bei Informatik kommt die SW, wenn überhaupt, auch ganz am Schluß. Also spar dir so einen Quatsch. Dein Matlab/Simulink ist was für Techniker, Hausmeister oder vielleicht noch für E-Ings die mal crazy was "programmieren" wollen. Wer will kann sich das jederzeit beibügeln und ein bisschen Klicki hier und da machen. Nur in einem echten Studium hat für so was niemand Zeit, da lernt man ordentliche Dinge.
:
Bearbeitet durch User
Cyblord -. schrieb: > Nur in einem echten Studium hat für so was niemand Zeit, > da lernt man ordentliche Dinge. Die hinterher nicht für einen Job qualifizieren siehe TO
Volle schrieb: > Cyblord -. schrieb: >> Nur in einem echten Studium hat für so was niemand Zeit, >> da lernt man ordentliche Dinge. > > Die hinterher nicht für einen Job qualifizieren > siehe TO Das liegt viel eher am TO als an sonst was.
MATLAB/Simulink in der Autoindustrie ist was um Maschinenbauer und Thermodynamiker zu Softwerkern umzufunktionieren. Sinn und Zweck davon ist es ja gerade, dass du Leute hast die Software bauen, obwohl sie keine Ahnung haben, wie man Software baut.
:
Bearbeitet durch User
Mal ne Frage an Euch zwei Helden: Womit führt Ihr denn Simulationen oder die Entwicklung von Prototypen durch? Oder gibt es sowas in der Welt der reinen Informatiker nicht?
:
Bearbeitet durch User
Mark B. schrieb: > Mal ne Frage an Euch zwei Helden: > Womit führt Ihr denn Simulationen oder die Entwicklung von Prototypen > durch? Oder gibt es sowas in der Welt der reinen Informatiker nicht? In der reinen Informatik, genau so wie in der reinen Physik oder reinen Mathematik gibt es keine Prototypen oder sonst was. Genauso wenig wie es in der reinen Astronomie Teleskope gibt. In der Realität müssen manche Astronomen aber irgendwie da hoch gucken und sich deshalb auch mit Teleskopen beschäftigen. Also wenn man für den Job Simulationen durchführen muss, kann man sicher zu solchen Mitteln wie Matlab o.ä. greifen. Spricht nichts dagegen. Nur das als unabdingbarer Inhalt eines Informatikstudiums zu deklarieren, ist halt Humbug. Und nichts anderes wurde gesagt.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Informatik zB. Dort arbeitet man mit richtigen Programmiersprachen ;-) > die Matlab Sprache hat ja kein Typsystem und keine klare Syntax usw... Hat man denn in einem Informatikstudium keine digitale Signalverarbeitung? Im Oppenheim/Schafer sind alle Übungen und Diagramme Matlab (bzw. Octave) basierend, und den sollte man schon mal gelesen haben, denn ansonsten bekommt man wohl keine positive Note... Ansonsten kommt man spätestens im Master damit in Berührung, wenn man irgendwas in Richtung mathematischer Modellbildung macht. Übrigens: Ich bin mir ziemlich sicher, dass in deinem Kurs über Einführung in Algorithmen auch "nur" mit Pseudocode programmiert wurde. Kein Typsystem, keine klare Syntax...
n0a schrieb: > Hat man denn in einem Informatikstudium keine digitale > Signalverarbeitung? Nö, das ist ja nur eine kleine Anwendung. Viel wichtiger ist Software Architektur und allgemeinere Algorithmen. Nur wenn man sich auf Embedded oder Robotik spezialisiert lernt man so etwas. n0a schrieb: > Übrigens: Ich bin mir ziemlich sicher, dass in deinem Kurs über > Einführung in Algorithmen auch "nur" mit Pseudocode programmiert wurde. > Kein Typsystem, keine klare Syntax... Also wir hatten Java, das hat beides. Und Matlab ist kein Pseudocode, das soll real benutzbar sein...
n0a schrieb: > Hat man denn in einem Informatikstudium keine digitale > Signalverarbeitung? In einem Informatikstudium ist das in der Regel nicht enthalten. Dr. Sommer schrieb: > Nö, das ist ja nur eine kleine Anwendung. Naja, "klein" ist da mal gar nix :-) Wenn man es richtig macht, lernt man zunächst die mathematischen Grundlagen wie Fourier, Laplace, Z-Transformation. Dazu eine Einführung in die Systemtheorie mit den LZI-Systemen. Dann die grundlegendsten Anwendungen wie z.B. den Tiefpassfilter, und dann erst kommen spezifischere Dinge wie etwa Algorithmen aus der Bildverarbeitung. All das kann man seriöserweise nicht mal eben in einer Vorlesung erschlagen. Elektrotechniker haben viele dieser Inhalte in ihrem Studium, weil man diese auch für die Regelungstechnik braucht. Bei den Informatikern sieht's da eher mau aus. Dafür haben die natürlich andere Schwerpunkte.
Cyblord -. schrieb: > Dein Matlab/Simulink ist was für Techniker, Hausmeister oder vielleicht > noch für E-Ings die mal crazy was "programmieren" wollen. Erklärt mal den Unterschied zwischen einen fixed step solver und einen variable step solver, wenn das alles so easy peasy ist...
Philipp M. schrieb: > Hallo, > ich bin noch im Studium und habe gesehen, dass ziemlich viele Leute für > die Kfz-Steuergeräteentwicklung mit Matlab/Simulink gesucht werden. Ähhh??????????? Von den Ing.-Dienstleistern!!!!!!!!! Und wozu brauchen die dann die "Matlab/Simulink" Steuergeräteentwickler? ...... > Ich > habe noch nie mit Matlab/Simulink gearbeitet, habe aber natürlich > Vorlesungen zu C später zu C++. Wer heute noch Vorleseungen besucht, der wird auch am Ende seines Studiums denken wie die Profs`s. Die sind auch noch geistig in den 80`er stehen geblieben.
Hallo, zur eigentlichen Frage: Also ich arbeite täglich mit Matlab und C als Support-Ing für einen Automobil OEM im Bereich HiL und bastel quasi die Gegenstücke zu den zu testenden SG zusammen. Es ist richtig, dass aktuell(!) nahezu nur C programmiert wird. Da wir z.T. die Funktionalität von Steuergeräten immitieren müssen, wird ein solcher Code je nach Anspruch entweder in Simulink(einfaches Verhalten komplexe Physik) umgesetzt oder als Level 2 S-Function (C: kompliziertes Verhalten - einfache Physik (hat aber einige Nachteile, was die usability angeht)). Dabei sind die Übergänge fließend. Warum hier immer eine Grundsatz Diskussion über Kompetenzen ausbricht ist mir schleierhaft. Für uns Ingenieure geht es zumindest in meinem Tätigkeitsfeld darum das Problem in einer gescheiten Weise zu lösen. Da ist aus Kostengründen eher schnell und einfach gefragt als besonders elegant. Ich kenne fast niemanden der erstmal anfängt irgendwelche Klassen zu designen, da man auch immer dem Kunden sagen muss wie weit man ist und dass es ja auch gerantiert in 5 Minuten was zum testen gibt. Langfristig gesehen mag ein objektorientiertes Vorgehen aber Vorteile haben - interessiert den Kunden aber nicht, bezahlt er auch nicht. Stichwort OEMs. Prinzipiell arbeiten wir jedoch viel mit Libraries = Standard Komponenten, die nur neu bedatet werden und je nach Variante auch mehr oder weniger Features haben. zB Motor mit und ohne Zylinderabschaltung, AGR, versch. Anzahlen Saugrohren, Ventilen usw..... Zu den Entwicklern des SG Codes ist es genau so wie Lu Ru schrieb. Ein Thermodynamiker kümmert sich halt um Thermodynamik. Die physikalische Beschreibung davon erfolgt in physikalisch mathematischen Formeln und meistens in Blockschaltbildern. Was spricht dagegen Matlab zu nutzen? Wenn Matlab dann noch eine recht performante Übersetzung in C liefert ist das doch Top. Frage mich was daran negativ sein soll... Dieser Code wird aber nicht 1 zu 1 ins SG gekloppt, sondern geht durch die Hände des Integrators und der versteht sein Handwerk was Software angeht. Objektorientierung hingegen macht man viel im Bereich von ADAS. Ich gehe mal davon aus, dass, je mehr sich damit beschäftigen, um so mehr auch andere Bereiche da aktiv werden.
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.