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?
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten