Hallo ihr, kann mir jemand etwas erzählen, wie es für einen Elektro-/Informationstechniker (B. Eng. FH) in der SW-Entwicklung aussieht? Ich kann mir im Moment nur auf Dauer langweiliges C(++) programmieren darunter vorstellen. Kann man in diesen Job auch z.B. Systemtheorie, Numerik mit einbeziehen? Ich habe das Gefühl, jeder halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester reines Informatik studiert hat. MfG
got2b schrieb: > Ich habe das Gefühl, jeder > halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester > reines Informatik studiert hat. Pfft! Sobald es Hardwarenahe Programmierung ist, kannst du mindestens 9 von 10 Informatiker in der Pfeife rauchen. => Embedded, Steuergeräte ect.. das ist der Bereich, wo EIT zum tragen kommt. Mach dir keinen Kopf! Wenn es jedoch um reine klassische Softwareentwicklung geht, bist du im falschen Studiengang.
got2b schrieb: > kann mir jemand etwas erzählen, wie es für einen > Elektro-/Informationstechniker (B. Eng. FH) in der SW-Entwicklung > aussieht? Sonnig, mal heiter bis wolkig. Scherz beiseite. Gewöhnlich macht man die Hardware im Labor und die Software am PC. Wobei man sich das nicht so klinisch vorstellen muss. Entscheidend sind die Aufgaben und welche Werkzeuge man bereitgestellt bekommt. Meist kann man da ja mit reden. > Ich kann mir im Moment nur auf Dauer langweiliges C(++) > programmieren darunter vorstellen. Bei Anlagen wird das wohl auch so verwandt werden, aber bei Geräten (embedded Systems) wird man mit C arbeiten können. > Kann man in diesen Job auch z.B. > Systemtheorie, Numerik mit einbeziehen? Ich vermute mal, bei Anlagen ja, bei Embedded eher weniger. Hängt eben von der App ab. > Ich habe das Gefühl, jeder > halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester > reines Informatik studiert hat. In Software vielleicht, aber nicht in Hardware. Kommt halt drauf an ob du mit Hardware im Projekt konfrontiert wirst.
In meiner Firma würde ich die Programmieraufgaben in drei Gebiete einteilen (welche jeweils von unterschiedlichen Kollen mit Abschluss B.Eng./M.Eng./Dipl.-Ing. bedient werden). 1) uC-Kleinkram Analoge Schaltungsteile entwerfen, welche mithilfe von Mikrocontrollern eine digitale Schnittstelle erhalten. Programmierung hauptsächlich in C, sehr hardwarenah, Herausforderungen liegen darin unterschiedliche Schnittstellen möglichst resourcenarm zu implementieren, Steuerungs- und Reglungsaufgaben entsprechend effektiv zu gestalten und möglichst robusten und fehlerunanfälligen Code zu produzieren. Beispiel: Strom- und Spannungsüberwachung von einem Netzteil mit Schaltfunktionen, Kurzschluss-/Überlasterkennung, Lüftersteuerung, seriellem Interface etc. 2) uC-Großkram Programmierung von ARM-Controllern und/oder FPGAs in C++ resp. VHDL, je nach Projekt hardwarenah oder mit RTOSsen bzw. selbst(zu)entwickelten Betriebssystemen. Kernpunkte sind Kommunikation mit 1) und 3), ergo Schnittstellen, Speichermanagement und Implementierung von Reglern, Motorsteuerungen, etc. Dabei ist ein Großteil der Zeit Reglerentwurf und -verifizierung. Das Programmieren ist mehr Mittel zum Zweck. Beipiel: Algorithmus zum Gleichgewicht halten bei einem dreibeinigen Roboter, welcher auf einem Gummiball steht, seine aktuelle Positionen von Modulen aus Kategorie 1) erhält, diese verarbeitet und wieder an Module aus Kategorie 1) weitergibt sowie einen Kamerastream an 3) weitergibt. 3) UI Als drittes Gebiet sind die Kollegen, welche die Benutzerschnittstellen programmieren. Das geschieht hauptsächlich mit C++ und Perl auf *nix-Systemen (bei uns). Dabei steht Anwenderfreundlichkeit und Implementation von Protokollen, Diagnosesystemen, Datenloggern und Ähnliches im Vordergrund. Beispiel: Treiber schreiben, welcher von 2) einen Videostream über z.B. USB von 2) erhält und diesen an einen Apache Webserver weiterreicht, welcher das Videosignal auf einer Website als Live-Bild verfügbar macht. Wie du siehst wäre für Teil 1) und 2) ein (reiner) Informatiker eher ungeeignet, da Hardwareentwicklung und ein tiefes Verständnis von analoger und digitaler Schaltungstechnik extrem wichtig ist. Zudem sind Kenntnisse in Systemtheorie und Regelungstechnik absolut wichtig um funktionierende Regelschleifen implementieren zu können, Modelle zu erstellen und Fehler zu erkennen. Punkt 3) ist wahrscheinlich eher, was du dir als "Programmierer" vorstellst, was jedoch in Firmen mit Entwicklungs- und Forschungsarbeit nur ein kleiner Teil ist/sein kann.
Die Tatsache, dass sowohl Informatiker als auch Ingenieure Software entwickeln wird für immer und ewig Identitätskrisen auf beiden Seiten hervorrufen. Eine Lösung wäre es, die Lizenz zum Programmieren an ein/e Studium/Ausbildung mit "Informatik" im Namen zu koppeln. So wie nur ein Mediziner den Beruf des Arztes ausüben darf. duckundweg
>jeder halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester
reines Informatik studiert hat.
Tatsachlich ? Allenfalls von einer Datenbank einen Drucker ansteuern.
Eine Excel Liste ausdrucken.
Sich von C++ demotivieren zu lassen ist unnoetig. Es ist leider eine der
Eigenschaften dieser Spreche, die Leute zu demotivieren.
Nein. Es gibt beliebig viele Moeglichkeiten. Auch ohne C++, oder nur
wenig.
Der effektive Code ist das Kleinste am ganzen Projekt. Die Applikation,
das System soll sicher und zuverlaessig sein. Bevor man eine Zeile Code
geschrieben hat, hat man sich mit einer Seite an Anforderungen dazu
auseinandergesetzt. Sehr spannend, und einer muss es ja machen.
zB Wie schaff ich es, dass mir ein Tesla nicht in einen Lastwagen
reinfaehrt. Dabei ist der Code das absolut Kleinste. Hier ist nicht der
der Groesste, der am meisten Zeilen schreibt.
got2b schrieb: > Kann man in diesen Job auch z.B. > Systemtheorie, Numerik mit einbeziehen? Eher selten bis gar nicht, meiner Erfahrung nach. Wichtig an Systemtheorie ist eher die Fähigkeit, in Systemen denken zu können, besonders mit Rückkopplung. > Ich habe das Gefühl, jeder > halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester > reines Informatik studiert hat. Der wird aber überfordert sein, wenn er mal ein Oszi rausholen soll, um Timings nachzumessen. Oder auch sonst immer, wenn es hardwarenah wird. Mal ein Beispiel, man möchte predictive maintenance für ein Kraftwerk aufbauen. Wartung bedingt Ausfallzeiten, die kosten Geld. Man will also nicht mehr warten als nötig. Andererseits bewirkt zu späte Wartung größere Schäden als nötig, also möchte man soviel warten wie nötig. Die Ingenieure setzt man daran, die Sensorik zu konzipieren, mit allerhand Kleingeräten und Microcontrollern Daten zu erfassen, aufzubereiten und an ein Zentralsystem zu schicken. Dann wissen sie aber weder, was sie mit den Unmengen an Daten tun sollen, noch, wie sie sie organisieren sollen. Die Informatiker haben zwar keine Ahnung, wie sie die Daten rankriegen sollen, aber wenn sie sie erstmal haben, können sie sich Gedanken machen, wie man sie formt und was man damit nun anfangen soll. Beide können Software machen, aber die Ingenieure eher konkret, die Informatiker eher abstrakt. Es sind unterschiedliche Aufgaben, die sich erst im Team ergänzen. Oder wenn man ein größeres Mikrocontroller-Projekt hat. Einen Informatiker würde ich daran setzen, die Struktur auszuarbeiten, aber die Ingenieure für den Inhalt. Setzt Du nur Ingenieure ran, wird das Ergebnis meistens ziemlich chaotisches Spaghettizeug sein, was zwar funktioniert, sich aber besch..eiden warten läßt. BTDT.
Nop schrieb: > Beide können Software machen, aber die Ingenieure eher konkret, die > Informatiker eher abstrakt. Das kann man durchaus am zeitlichen Verhalten von Routinen feststellen: Bei den Ingenieuren dauert die gleiche Funktion 1 mS bei den Informatikern 1000 mS. (gefühlt noch länger ;-)
il Conte schrieb: > Bei den Ingenieuren dauert die gleiche Funktion 1 mS > bei den Informatikern 1000 mS. (gefühlt noch länger ;-) Bei einzelnen Routinen vielleicht, aber im Gesamtpaket sieht es anders aus. Etwa bei einem Suchbaum würden Ingenieure zwar die Hardware effizienter nutzen, aber die Informatiker kämen mit Ideen, wie man den ganzen Suchbaum beschneidet. Die Expertise für die Effizienz liegt einfach auf unterschiedlichenen Ebenen.
жтампф ден троль schrieb: > zB Wie schaff ich es, dass mir ein Tesla nicht in einen Lastwagen > reinfaehrt. Da muss ich mal den Spieß umdrehen... Wie schafft man es dass ein LKW nicht in einen Tesla (oder besser gesagt PKW allgemein) reinfährt? Z.B. bei einem Stauende
il Conte schrieb: > Bei den Ingenieuren dauert die gleiche Funktion 1 mS > bei den Informatikern 1000 mS. (gefühlt noch länger ;-) Seit wann haben denn Funktionen einen elektrischen Leitwert?
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.